tshort at akamai.com
Mon Aug 20 17:45:53 UTC 2018
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.
This may not help the "end session" issue.
// 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.
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users