[gnutls-devel] [resent][PATCH] ALPN and session resumption
Yuriy M. Kaminskiy
yumkam at gmail.com
Fri Mar 18 10:53:05 CET 2016
On 18.03.2016 11:20, Nikos Mavrogiannopoulos wrote:
> On Wed, Mar 16, 2016 at 8:51 PM, Yuriy M. Kaminskiy <yumkam at gmail.com> wrote:
>> I've played a bit with curl with HTTP/2 support and gnutls backend (curl git
>> master [curl-7_47_1-75-g3c2ef2a], [self-compiled] nghttp2 1.8.0, [distro]
>> debian's gnutls 3.3.8), and it looks like ALPN is broken with session
>> curl -v -c jar --location https://www.google.com/ncr >log 2>errlog
>> fails; first connection succeed (got redirect), then second connection
>> to same server (resumes session) fails with
>> * ALPN, server did not agree to a protocol
>> If I disable session support:
>> curl -v -c jar --location --no-sessionid https://www.google.com/ncr
>> everything works.
>> I played with gdb, looked at gnutls sources, and found that libgnutls
>> neither parse ALPN extension on resume, nor re-uses session data, as a
>> result after session resumption gnutls_alpn_get_selected_protocol() returns
>> failure (even though server sent ALPN/h2 in ServerHello).
>> I've re-tested with (self-compiled) gnutls 3.3.22, it behaves same.
>> I cannot test with 3.4.* atm (missing build-req), but quick look at sources
>> suggests bug is still present.
> Thank you for reporting that. It may make sense to move the ALPN
> extension to the mandatory to parse set. I'll check it, and try to
> introduce some checks to detect this issue.
I considered changing it at first, but it would interfere with
sever-side (GNUTLS_EXT_APPLICATION are parsed *before* running
user-defined hook, *MANDATORY - after).
More information about the Gnutls-devel