[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openssl-users
Subject:    Re: [openssl-users] TLS-Session
From:       "Short, Todd via openssl-users" <openssl-users () openssl ! org>
Date:       2018-08-20 17:45:53
Message-ID: 6560E1EB-9B74-4F83-85AE-EE3CE8637039 () akamai ! com
[Download RAW message or body]

TCP Nagle + TCP Delayed ACKs can cause what appears to be the ClientHello b=
eing retransmitted.

Tweaking these TCP options will give you better initialization performance.

TCP_NODELAY
TCP_QUICKACK

This may not help the "end session" issue.
--
-Todd Short
// tshort@akamai.com<mailto:tshort@akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Aug 20, 2018, at 9:39 AM, Viktor Dukhovni <openssl-users@dukhovni.org<ma=
ilto:openssl-users@dukhovni.org>> wrote:



On Aug 17, 2018, at 6:43 AM, Konstantinos Schoinas <ece8537@upnet.gr<mailto=
:ece8537@upnet.gr>> wrote:

So my dpdk application is responding with the correct TLS alert and it actu=
ally block the TLS session.I have seen the correct packet in wireshark as w=
ell.I am also putting a picture with this mail in order to see the process.

The problem is that VM1 using openssl takes 2 to 3 seconds to end the TLS s=
ession.Also i am getting some retransmits of client hello in wireshark.

Re-transmission is a feature of the kernel TCP stack, and OpenSSL
has no control over this behaviour.

So my question is if anyone can confirm that this is a problem of openssl o=
r if not maybe something else.
In addition if anyone know how much time does TLS session takes to actually=
 end?

This *cannot* be an OpenSSL issue.  Your DPI firewall must not be
sending an ACK for the client HELLO payload.  Or is otherwise
failing to conform to TCP in a way that triggers re-transmission.

--
Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


[Attachment #3 (text/html)]

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: \
after-white-space;" class=""> TCP Nagle &#43; TCP Delayed ACKs can cause what appears \
to be the ClientHello being retransmitted. <div class=""><br class="">
</div>
<div class="">Tweaking these TCP options will give you better initialization \
performance.&nbsp;</div> <div class=""><br class="">
</div>
<div class="">TCP_NODELAY</div>
<div class="">TCP_QUICKACK</div>
<div class=""><br class="">
</div>
<div class="">This may not help the &quot;end session&quot; issue.</div>
<div class="">
<div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: \
start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; \
word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; \
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""> <div \
style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; \
text-indent: 0px; text-transform: none; white-space: normal; widows: auto; \
word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; \
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""> <div \
class="">--</div> <div class="">-Todd Short</div>
<div class="">// <a href="mailto:tshort@akamai.com" \
class="">tshort@akamai.com</a></div> <div class="">// &quot;One if by land, two if by \
sea, three if by the Internet.&quot;</div> </div>
</div>
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Aug 20, 2018, at 9:39 AM, Viktor Dukhovni &lt;<a \
href="mailto:openssl-users@dukhovni.org" class="">openssl-users@dukhovni.org</a>&gt; \
wrote:</div> <br class="Apple-interchange-newline">
<div class="">
<div class=""><br class="">
<br class="">
<blockquote type="cite" class="">On Aug 17, 2018, at 6:43 AM, Konstantinos Schoinas \
&lt;<a href="mailto:ece8537@upnet.gr" class="">ece8537@upnet.gr</a>&gt; wrote:<br \
class=""> <br class="">
So my dpdk application is responding with the correct TLS alert and it actually block \
the TLS session.I have seen the correct packet in wireshark as well.I am also putting \
a picture with this mail in order to see the process.<br class=""> <br class="">
The problem is that VM1 using openssl takes 2 to 3 seconds to end the TLS \
session.Also i am getting some retransmits of client hello in wireshark.<br class=""> \
</blockquote> <br class="">
Re-transmission is a feature of the kernel TCP stack, and OpenSSL<br class="">
has no control over this behaviour.<br class="">
<br class="">
<blockquote type="cite" class="">So my question is if anyone can confirm that this is \
a problem of openssl or if not maybe something else.<br class=""> In addition if \
anyone know how much time does TLS session takes to actually end?<br class=""> \
</blockquote> <br class="">
This *cannot* be an OpenSSL issue. &nbsp;Your DPI firewall must not be<br class="">
sending an ACK for the client HELLO payload. &nbsp;Or is otherwise<br class="">
failing to conform to TCP in a way that triggers re-transmission.<br class="">
<br class="">
-- <br class="">
<span class="Apple-tab-span" style="white-space:pre"></span>Viktor.<br class="">
<br class="">
-- <br class="">
openssl-users mailing list<br class="">
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" \
class=""> https://mta.openssl.org/mailman/listinfo/openssl-users</a><br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--===============4792266564253859142==--

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic