[openssl-users] session resumption tls1.2/tls1.3
Neetish Pathak
npathak2 at ncsu.edu
Tue Aug 1 17:46:38 UTC 2017
On Mon, Jul 31, 2017 at 2:00 PM, Matt Caswell <matt at openssl.org> wrote:
>
>
> On 31/07/17 20:37, Neetish Pathak wrote:
> > 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 )
>
>
> SSL_READ_EARLY_DATA_FINISH is not returned until we have seen the
> EndOfEarlyData message. Often (but not always - dependent on the
> implementation) the client Finished message is also in the same packet
> which OpenSSL will immediately try and process. As soon as it has done
> so the handshake is complete and it is too late for the server to write
> early data. Calls to SSL_write_early_data() by the server at this point
> should fail (do you not see this???).
>
> You should write early data on the server side as soon as
> SSL_READ_EARLY_DATA_SUCCESS is received.
>
Yes, this is what I tried and it worked. Thanks for the clarification
>
>
>
> > > 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?
>
> The OpenSSL implementation *always* sends a NewSessionTicket message
> immediately after the handshake is complete. This is not required, but
> is allowed by the spec. Currently there is no way to disable this
> behaviour. Do you need/want it (if so, why)?
>
No, I do not need to disable it per se. The handshake completion at the
client side is independent of the newsession ticket coming from the server
side if I am correct. So the handshake operation (specifically SSL_connect)
will return even if new session ticket has not arrived from the server. I
was asking why new session ticket is needed during the resumption
handshake. Isn't it just an overhead?
>
> >
> > 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.
>
> Yes, TLSv1.2 session tickets share the same name and have a similar
> purpose, but are otherwise *completely* different to TLSv1.3 session
> tickets.
>
Understood
>
>
> > >
> > > 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.
>
> As soon as you call SSL_shutdown() then a close_notify alert is sent.
> Typically you do that on both the client and the server sides which
> seems to match your wireshark trace.
>
OK Thanks
>
> 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/20170801/e7296869/attachment.html>
More information about the openssl-users
mailing list