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

[Nikos Mavrogiannopoulos]

On Mon, 2016-03-21 at 16:08 +0300, Yuriy M. Kaminskiy wrote:

> > > $ wireshark-gtk -p -f 'tcp && port https' &
> > > Set filter to ssl.handshake, start capture.
> > > $ gnutls-cli --inline-commands www.google.com
> > > ^resume^
> > > ^resume^
> > That seems to be a limitation of gnutls-cli.
> > gnutls_session_get_data2() can only be called on non-resumed 
> > sessions,
> > and gnutls-cli does call it on resumed as well causing the issue 
> > that
> > you notice. Fixing gnutls-cli to conform to the documented behavior
> > fixes the issue. Could that be the same happening in curl?
> 
> Hmm? Yes, this is documented, however it is only *recently* 
> documented 
> (at 2015-02-24, after gnutls-3.3.12).
> (However, it looks like only documented pre-existing [for long time?] 
> 
> behavior)
> 
> And it looks like it will break another rfc5077-conforming server 
> behavior:
> === cut rfc5077 ===
>      If the server successfully verifies the client's ticket, then it 
> may
>      renew the ticket by including a NewSessionTicket handshake 
> message
>      after the ServerHello.
> === cut ===
> 
> That is, session resumed, however server also issued *new* ticket. If 
> 
> client won't not save this *new* ticket, next resume will (probably) 
> fail.

Then the proper fix would be to make gnutls_session_get_data2() to work
irrespective of the status of the session (resumed or not). This was
also be backwards compatible and would not affect any programs relying
the previous semantics. Would you be interested in making a patch
towards that path?

I've opened a ticket for it at:
https://gitlab.com/gnutls/gnutls/issues/79

regards,
Nikos