[gnutls-devel] [resent][PATCH] fix SessionTicket when server opted for not renewing ticket

[Nikos Mavrogiannopoulos]

On Wed, Mar 16, 2016 at 9:34 PM, Yuriy M. Kaminskiy <yumkam at gmail.com> wrote:
> When I played with fixed (wrt ALPN-with-sessions) gnutls library and
> curl, I noticed in wireshark capture for
>
>   `curl -v -c jar --location https://www.google.com/ncr
> https://www.google.com/ncr`,
>
> that SessionTickets are used only *once*:
>
> 1.ClientHello (empty session id, empty SessionTicket)
>   <ServerHello (empty session_id, empty SessionTicket)
>   <Certificate
>   ClientKeyExchange
>   ...
>   <NewSessionTicket [1]
>   <ChangeCipherSpec
>   ChangeCipherSpec
>   ...
> 2.ClientHello (new random session id[2], SessionTicket with data
>   from [1])
>   <ServerHello (same session id[2], *no* SessionTicket)
>   <ChangeCipherSpec
>   ...
>   (=resumed client/ticket-stored session)
> 3.ClientHello (same session id[2], *no* SessionTicket extension)
>   <ServerHello (*new* random session id[3], *no* SessionTicket extension)
>   <Certificate
>   ClientKeyExchange
>   ...
>   <ChangeCipherSpec
>   ...
>   (=non-resumed full handshake, establish new server-stored session)
> 4.ClientHello (same session id[3], *no* SessionTicket extension)
>   <ServerHello (same session id[3], *no* SessionTicket extension)
>   <ChangeCipherSpec
>   (=resumed server-stored session)
>
> I've addede debug print of session data in curl, it looks like session
> data saved after step 2 is 150+ bytes shorter (apparently, it does not
> contain SessionTicket data).
>
> After looking at rfc5077, it looks like server is allowed to resume
> session this way, and client should just keep old SessionTicket data.
> However, gnutls forgets it instead.

Hello Yuriy,
 I am unable to understand which scenario does not work from the
description. Could you describe only the non-working scenario and if
possible provide some reproducer with gnutls-cli or a sample gnutls
application?

regards,
Nikos