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

[Yuriy M. Kaminskiy]

On 21.03.2016 13:25, Nikos Mavrogiannopoulos wrote:
> On Fri, Mar 18, 2016 at 2:32 PM, Yuriy M. Kaminskiy <yumkam at gmail.com> wrote:
>>>> 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.
>>>    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?
>> You need to resume session 2 or more times, with server that opt for *not*
>> renewing ticket (e.g. https://www.google.com show this behavior for me).
>> Run
>> $ 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.

(Disclaimer: untested, I don't know which servers exhibit this behavior)

> I'm thinking if that's a commonly used pattern maybe we can fix the
> API to store any value provided by gnutls_session_set_data() and
> return the same value by gnutls_session_get_data*() if it is not a
> resumed value. This however would increase memory usage in such a
> session.
Well, let's look 
https://codesearch.debian.net/search?perpkg=1&q=gnutls_session_get_data

wget: does something strange
wpa, filezilla, curl, lftp, bitlbee, reaver: does not check is_resumed 
before get_data (a number of projects embeds curl code)
glib-networking, neon27: only saves new data if session is not resumed 
(a number of projects embeds neon code)