Thanks Ben for your reply
On Tue, Jul 25, 2017 at 6:11 AM, Benjamin Kaduk <bkaduk@xxxxxxxxxx> wrote:
[Matt's reply is likely to be high latency]Maybe I misunderstand the question, but isn't this is just a natural consequence of the server (mis)behavior in (2)?
On 07/24/2017 08:53 PM, Neetish Pathak wrote:
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 MattTo 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_readssl_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
Yes, this is right, the server misbehavior is causing this.
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.
From a quick look through the state machine code, this is supposed to work. But someone would probably have to instrument the code (e.g., with printf) to tell why the delay is being introduced. I don't think I have the availability to do so in the near future, myself.
I see that the application data is not being sent from server to an unauthenticated client. The server is sending data only after receiving some encrypted message which I believe is the EndOfEarlyData and Finished messages. Following is a dump of wireshark logs for the communication with early data enabled. I also tried with some logs in Openssl libraries, I see early data gets written from server side when write_early_data is called. Internally SSL_write_ex is called which completes write and handshake. But I am not sure why application data is not actually pushed from the server side. It is waiting for the Client finished message.
I have disabled Nagle's algo during this operation.
Client port is 56806 and server port is 12345
No. Time Source Destination Protocol Length Info
207 18.380298 ::1 ::1 TLSv1.3 956 Client Hello ----------------- Client Hello
No. Time Source Destination Protocol Length Info
208 18.380335 ::1 ::1 TLSv1.3 2849 Application Data ------------------Early Data from the client side (Intended Application Data)
Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq: 881, Ack: 1, Len: 2773
No. Time Source Destination Protocol Length Info
211 18.380624 ::1 ::1 TLSv1.3 219 Server Hello, Application Data, Application Data . ------------Server Hello and (encrypted handshake message/extensions)
Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 1, Ack: 3654, Len: 143
No. Time Source Destination Protocol Length Info
213 18.380819 ::1 ::1 TLSv1.3 160 Application Data, Application Data ------Encrypted handshake msg from client (I believe they are end early data and finished)
Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq: 3654, Ack: 144, Len: 84
No. Time Source Destination Protocol Length Info
215 18.381122 ::1 ::1 TLSv1.3 762 Application Data
Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 144, Ack: 3738, Len: 686 -----I don't know why this application data is sent from server. My guess is this is session info
No. Time Source Destination Protocol Length Info
217 18.381210 ::1 ::1 TLSv1.3 9917 Application Data ----------Intended Application Data that was intended to be early data
Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 830, Ack: 3738, Len: 9841
No. Time Source Destination Protocol Length Info
219 18.381308 ::1 ::1 TLSv1.3 100 Application Data . ---------Application Data from client (I also see this application data sent everytime, not sure why)
Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq: 3738, Ack: 10671, Len: 24
No. Time Source Destination Protocol Length Info
220 18.381309 ::1 ::1 TLSv1.3 100 Application Data . ---------Application Data from server (I also see this application data sent everytime, not sure why)
Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 10671, Ack: 3738, Len: 24
Please provide any comments if you have or how I should go about debugging it. Correct me if I am doing it wrong
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.
It seems like it hasn't really sunk in for you that TLS 1.3 is a seriously different protocol than TLS 1.2, and it provides stronger security properties, remediating weaknesses of TLS 1.2. So no, we should not recommend TLS 1.2 resumption on the LAN -- we should recommend the more secure option! If you continue to believe that latency trumps everything else, you could experiment with SSL_OP_ALLOW_NO_DHE_KEX to cut out some of the heavier-weight asymmetric crypto, though it looks like you'd want to patch ssl/statem/extensions_clnt.c to not send TLSEXT_KEX_MODE_KE_DHE, as I don't see a way to configure the server to prefer the non-DHE PSK key exchange.
OK, I understand that, Thanks Ben. I think I got a small improvement on latency by removing TLSEXT_KEX_MODE_KE_DHE. But I also reckon that security comes first and hence it requires deliberation.
Thanks
BR,
Neetish
-Ben
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
