On Wed, Sep 30, 2015 at 10:05:09PM +0200, Tomasz Buchert wrote: > On 30/09/15 21:31, Alessandro Ghedini wrote: > > On Wed, Sep 30, 2015 at 01:00:55pm +0200, Tomasz Buchert wrote: > > > Package: curl > > > Version: 7.44.0-2 > > > Severity: normal > > > > > > Hi, > > > curl --http2 <address> does not work for me. > > > > Hi Alessandro, > > > Works fine here with e.g. https://www.google.com, https://http2.golang.org > > and > > https://http2.cloudflare.com. > > Indeed, -v shows quite well that it works. > > > > > > I have nghttpx proxy serving content over HTTP2 and when I do: > > > > > > curl --http2 https://ADDRESS > > > > Can you please post the output with the '-v' flag? Also, how do I configure > > nghttpx to reproduce this? > > Here is the relevant part: > > ....... > * Connected to tomasz.buchert.pl ([ IP ]) port [ PORT ] (#0) > * found 181 certificates in /etc/ssl/certs/ca-certificates.crt > * found 728 certificates in /etc/ssl/certs > * ALPN, offering h2 > * ALPN, offering http/1.1 > * SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256 > * server certificate verification OK > * server certificate status verification SKIPPED > * common name: [ COMMON-NAME ] (matched) > * server certificate expiration date OK > * server certificate activation date OK > * certificate public key: RSA > * certificate version: #3 > * subject: C=FR,CN=[ COMMON-NAME ],EMAIL=[ MAIL ] > * start date: Wed, 01 Apr 2015 20:47:39 GMT > * expire date: Sat, 02 Apr 2016 06:13:28 GMT > * issuer: C=IL,O=StartCom Ltd.,OU=Secure Digital Certificate > Signing,CN=StartCom Class 1 Primary Intermediate Server CA > * compression: NULL > * ALPN, server did not agree to a protocol > > GET / HTTP/1.1
Here is what's happening: curl tries to negotiate HTTP/2 during the TLS handshake using the ALPN extension, but the server doesn't support ALPN (e.g. OpenSSL in jessie doesn't support it) and instead supports the older NPN extension (which is deprecated, but still in use). The problem being that curl in sid uses GnuTLS which *only* supports ALPN and not NPN, so the client and the server can't negotiate HTTP/2 and fallback to HTTP/1.1. It's not really a curl bug, though if curl used OpenSSL (in sid) instead of GnuTLS this would work. TBH I'm not really inclined to switch back to OpenSSL for this problem alone (mostly because the intention is to, at some point, completely drop curl's non-GnuTLS backends from Debian and because NPN is deprecated), but I can't exclude it completely either. nghttp2 could implement support for ALPN on its own if it detects that the used OpenSSL version doesn't support it, but it's probably overkill... Cheers
signature.asc
Description: PGP signature
