Thanks Ben for your reply On Tue, Jul 25, 2017 at 6:11 AM, Benjamin Kaduk <bka...@akamai.com> wrote:
> [Matt's reply is likely to be high latency] > > > On 07/24/2017 08:53 PM, Neetish Pathak wrote: > > > > On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell <m...@openssl.org> 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 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_manmaster_man3_SSL-5Fwrite-5Fearly-5Fdata.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=MfCOjAV83u4xGuIMb7VquiUt64_HFf9UC8LY4eIP_oc&s=ZAcBNcJWKTExKYdPPPOxcSr51esghiaZM82tPTLtbHM&e=> > > > > 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 > > > Maybe I misunderstand the question, but isn't this is just a natural > consequence of the server (mis)behavior in (2)? > 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