Hello
Thanks
I tried reading some content from the server side and I observed the new_session_cb getting invoked in that case on the client side. I understand that may be due to delayed NewSession info transfer from server side to client side. But it is helpful for saving the session info on the client side. (Thanks Matt for your input)
However, now I have two concerns
1) I see that latency for handshake with session resumption in TLS 1.3 has not improved as much as it improves for TLS 1.2
With TLS 1.3, I observed that resumption brings down the connection time from 2.5 ms to 1.2-1.3 ms
while with TLS 1.2 (using either session IDs or tickets), the connection time reduces from 2.5 ms to 0.5-0.6 ms.
The whole code is similar for running the two experiments with only max TLS version changed. Can someone comment on the latency measurements for the two cases.
TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please comment.
2) PSK (Pre-shared keys) for resumption are highly emphasized in TLS 1.3 RFC. How do we generate pre-shared keys in advance even without making the first connection. Can someone guide me in the right direction.
Thanks
Best Regards,
Neetish
On Thu, Jun 15, 2017 at 2:30 AM, Matt Caswell <matt@xxxxxxxxxxx> wrote:
On 14/06/17 18:36, Neetish Pathak wrote:
>
> My calling sequence is :
>
> client.connectToServer();
>
> client.sslTcpConnect();
>
> client.sslTcpClosure();
Does your client at any point attempt to read application data (i.e.
through a call to SSL_read()/SSL_read_ex()?). It is not sufficient to
just connect to a server via SSL_connect(). Because the session
information is established *post* handshake in TLSv1.3, OpenSSL won't
see it unless you actually try and read information from the connection.
Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
