[openssl-users] TLS-Session

[Short, Todd]

TCP Nagle + TCP Delayed ACKs can cause what appears to be the ClientHello being 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 at akamai.com<mailto:tshort at 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 at dukhovni.org<mailto:openssl-users at dukhovni.org>> wrote:



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

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.

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.

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 or 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180820/9247ec4d/attachment.html>