[openssl-users] session resumption tls1.2/tls1.3
Neetish Pathak
npathak2 at ncsu.edu
Tue Aug 1 23:14:38 UTC 2017
On Tue, Aug 1, 2017 at 10:46 AM, Neetish Pathak <npathak2 at ncsu.edu> wrote:
>
>
> 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.
> Also, this point is not very clear from the man page on when the write
> early data be sent from the server side (after SUCCESS or FINISH). Can it
> be included?
>
>>
>>
>>
>> > > 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/4224e7ce/attachment-0001.html>
More information about the openssl-users
mailing list