[openssl-users] session resumption tls1.2/tls1.3
Neetish Pathak
npathak2 at ncsu.edu
Tue Jul 25 23:05:47 UTC 2017
Thanks Ben for your reply
On Tue, Jul 25, 2017 at 6:11 AM, Benjamin Kaduk <bkaduk at 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 <matt at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170725/5207b992/attachment-0001.html>
More information about the openssl-users
mailing list