On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell <matt@xxxxxxxxxxx> wrote:
On 18/07/17 22:27, Neetish Pathak wrote:
> Hi ,
> thanks Matt, this is helpful
>
>
> One more query on how I can enable 0.5 RTT data from the server side. It
> is mentioned in TLS 1.3 specification. I thought it can be implemented
> by sending early data from server side after reading the early data.
That is correct, and is as documented on this page:
https://www.openssl.org/docs/manmaster/man3/SSL_write_ early_data.html
Thanks Matt
To send 0.5 RTT data I m sending the early_data from the server side just after the early_read data. But when I see the wire-shark logs, I see that the server data is sent only once the complete handshake has taken place. (which is the same as using SSL_write after SSL_accept).
I am performing following steps on client and server respectively as per understanding developed from previous discussions
Pseudocode for client
tcp_connect
write_early(data)
ssl_connect
if(early_data_write_failed){
ssl_write(data)
}
ssl_read
Pseudocode for server
tcp_accept
read_early{
if(read_early_success){
write_early(data)
}
}
ssl_accept
if(read_early_fail){
ssl_read
ssl_write(data)
}
I am measuring latency on the client side from TCP connection start till it completes the read (ssl_read returns) (analogues to making a request from client and reading response).
Please suggest what may be going wrong basically with these queries
1) Why is there no difference (or negligible) in latencies when i use early write and then later ssl_read compared to when I execute normal write/read on the client side
2) Why does the server not send data (for early write) after the server Hello(and other encrypted message) message even when early_write succeeds on server side. Why does server wait to finish the handshake. I know it waits because I see client sending encrypted messages after server hello message before my intended application data gets sent from server. These encrypted messages from the client side are the usual messages from the client side for handshake completion.
3) Also, the performance of TLS 1.3 using early data or resumption is worse than TLS 1.2 resumption on LAN. I see on wire-shark that encrypted messages get exchanged in TLS 1.3 during handshake which are plaintext in TLS 1.2. I think that causes extra latency. So can we say that TLS 1.3 resumption is not recommended for LAN for performance enhancement when compared with TLS 1.2 resumption. On WAN, I see TLS 1.3 resumption at par with TLS 1.2 resumption and full handshake better for TLS 1.3.
Thanks
Best regards,
Neetish
> But then how can that data be read on the client side since
> read_early_data api is invalid on client side ?
0.5 RTT data is sent from the server to an unauthenticated client. At
this point in the process the server has sent all of its messages
(including its Certificate/CertificateVerify/Finished messages) but it
has not received the Client Finished or any client
Certificate/CertificateVerify if one is going to be sent.
>From the client's perspective 0.5 RTT data is received *after* it has
processed the server's Certificate/CertificateVerify/Finished messages),
and after it has sent its own Finished (and
Certificate/CertificateVerify if appropriate). In other words from the
client's perspective the server is fully authenticated and 0.5 RTT data
is indistinguishable from post-handshake data. Just use SSL_read() as
normal to receive it.
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
