[openssl-users] session resumption tls1.2/tls1.3
Neetish Pathak
npathak2 at ncsu.edu
Mon Jul 31 19:37:32 UTC 2017
On Mon, Jul 31, 2017 at 9:43 AM, Matt Caswell <matt at openssl.org> wrote:
> Apologies for the delayed response - I've been away on holiday. Comments
> inserted below.
>
No problem thanks for the replies
>
> Matt
>
>
> On 26/07/17 00:05, Neetish Pathak wrote:
> >> *Pseudocode for server*
> >> *
> >> *
> >> tcp_accept
> >> *
> >> *
> >> read_early{
> >>
> >> if(read_early_success){
> >> write_early(data)
> >> }
> >> }
>
> There is a bit of complexity here (covered in the docs), i.e.
> SSL_read_early_data() may return SSL_READ_EARLY_DATA_SUCCESS or
> SSL_READ_EARLY_DATA_FINISH. In the latter case this is still a success,
> but the server may or may not be able to write early data. I assume that
> you have covered that in your actual code and it's just skimmed over
> here in your pseudo code.
>
So, I consider read_early_sucess when SSL_read_early_data() returns
SSL_READ_EARLY_DATA_FINISH. Also, I check that early data was accepted
before declaring success. Look at the case checks below
*case* SSL_READ_EARLY_DATA_SUCCESS:
totalBytes += readBytes;
* break*;
*case* SSL_READ_EARLY_DATA_FINISH:
totalBytes += readBytes;
* if* (SSL_EARLY_DATA_ACCEPTED == SSL_get_early_data_status(*this*->conn)
&& totalBytes > 0) {
readBuf = string(readBuffer);
* return* SUCCESS;
}
So, are you suggesting that early data may not be written from the server
side if SSL_READ_EARLY_DATA_FINISH is received. Should I try writing before
that (as in when SSL_READ_EARLY_DATA_SUCCESS is received )
>
>
> >> 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.
>
> Can you confirm whether you have disabled Nagle's algo on both the
> client *and* the server?`
>
Nagle's algorithm is disabled on both the client and the server side.
>
>
> >
> > 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
>
> It could be the NewSessionTicket message going from the server to the
> client. But if so that is a little strange. The NST message is only sent
> after the handshake is complete (so no more early data is possible). At
> this point SSL_read_early_data() should have returned
> SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return true,
> and any calls to SSL_write_early_data() will fail.
>
Yes, here the handshake is completed. Will the new session ticket be sent
each time after the handshake? In theTLS 1.3 draft, it is mentioned that
new session tickets may be sent after server receives Finished from the
client and it creates a unique association between the ticket value and a
secret PSK derived from the resumption master secret.
But looks like, I am receiving new session ticket every-time. So, as per
the implementation, new session ticket is a must I guess. Am I right? When
will I not receive new session ticket in TLS 1.3?
Also, I believe it is different than how new session ticket works in TLS
1.2 where it was sent only once to share the encrypted ticket from the
server side when the client indicates support for session tickets.
>
> >
> >
> > 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)
>
> Perhaps these are close_notify alerts? Are you shutting down the
> connection cleanly at this point?
>
I am shutting down the connection from the client side. Server is up all
the time for any new connection.
Thanks
Neetish
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170731/64a3576e/attachment-0001.html>
More information about the openssl-users
mailing list