<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 06/09/2017 07:54 PM, Neetish Pathak wrote:<br>
<blockquote type="cite"
cite="mid:CANWFjKBvXtoBzm8AiPBk=XnOzGwgB=f043nePCkUXYywaVr=3g@mail.gmail.com"><br>
<div class="gmail_quote">On Thu, Jun 8, 2017 at 3:45 PM, Matt
Caswell <span dir="ltr"><<a href="mailto:matt@openssl.org"
target="_blank" moz-do-not-send="true">matt@openssl.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class=""><br>
<br>
On 08/06/17 23:12, Neetish Pathak wrote:<br>
> Thanks.<br>
> I had one query regarding the TLS 1.3 implementation on
server side. I<br>
> have a simple client server program with session
resumption working with<br>
> TLS 1.2.<br>
> When I use TLS 1.3, I see that server hello message has
a malformed<br>
> packet.<br>
<br>
</span>How do you know it is malformed? The format of the
ServerHello message<br>
has changed in TLSv1.3, so if you expect it to look like a
TLSv1.2<br>
ServerHello then you will be surprised.<br>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div><b>I know the ServerHello is malformed from the WIRESHARK
LOGS. It shows an exception for the ServerHello with
malformed packet message.</b></div>
</div>
</blockquote>
<br>
It is quite likely that your version of wireshark does not know how
to properly decode the TLS 1.3 ServerHello. When interpreted as a
TLS 1.2 ServerHello, it is expected to show as malformed, because
the protocol formats are different between the two protocols. This
is what Matt was trying to say.<br>
<br>
Someone could look at the raw hex dump of the packet and decode it
manually as a TLS 1.3 ServerHello to confirm whether it is actually
malformed or just a wireshark error.<br>
<br>
-Ben<br>
</body>
</html>