#800517 curl does not support NPN extension

Package:
curl
Source:
curl
Description:
command line tool for transferring data with URL syntax
Submitter:
Tomasz Buchert
Date:
2015-10-19 19:48:08 UTC
Severity:
normal
#800517#5
Date:
2015-09-30 11:00:55 UTC
From:
To:
Hi,
curl --http2 <address> does not work for me. I have nghttpx
proxy serving content over HTTP2 and when I do:

    curl --http2 https://ADDRESS

I get in my syslog on the server:

    Sep 30 12:56:43 server nghttpx[20363]: <IP hidden> - -
[30/Sep/2015:12:56:43 +0200] "GET / HTTP/1.1" 200 2253 "-" "curl/7.44.0"

Notice HTTP/1.1 there. On the other hand, if I access with Firefox/Iceweasel, I
get:

    Sep 30 12:58:23 hilbert nghttpx[20363]: <IP hidden> - -
[30/Sep/2015:12:58:23 +0200] "GET / HTTP/2" 200 2253 "-" "Mozilla/5.0 (X11;
Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.1"

I also launched curl with ltrace(1) and I couldn't see a single symbol from
libnghttp there.

Cheers,
Tomasz
#800517#10
Date:
2015-09-30 19:31:55 UTC
From:
To:
Works fine here with e.g. https://www.google.com, https://http2.golang.org and
https://http2.cloudflare.com.

Can you please post the output with the '-v' flag? Also, how do I configure
nghttpx to reproduce this?

Cheers
#800517#15
Date:
2015-09-30 20:05:09 UTC
From:
To:
Hi Alessandro,

Indeed, -v shows quite well that it works.

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
......

My nghttpx config is:

frontend=*,3000
backend=127.0.0.1,9080
private-key-file=/etc/nginx/ssl/server.key
certificate-file=/etc/nginx/ssl/server.crt
errorlog-syslog=yes
accesslog-syslog=yes
workers=1

Maybe it is a problem with nghttpx, actually.

Cheers,
Tomasz
#800517#20
Date:
2015-09-30 20:10:53 UTC
From:
To:
Let me also add that it works with the nghttp experimental client.

Tomasz
#800517#25
Date:
2015-09-30 20:46:33 UTC
From:
To:
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
#800517#30
Date:
2015-09-30 21:24:58 UTC
From:
To:
retitle -1 curl does not support NPN extension
thanks

Thank you for this analysis. TBH, I'm not very interested in using
curl that way, I simply noticed that it doesn't work. It's simply an
unfortunate mix of TLS extensions that causes problems.

I think that it is not worth taking care of unless more people
complain.

Cheers,
Tomasz
#800517#37
Date:
2015-10-19 19:44:44 UTC
From:
To:
found 695 certificates in /etc/ssl/certs
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
*        server certificate verification OK
*        server certificate status verification SKIPPED
*        common name: www.example.com (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: C=DE,CN=www.example.com,EMAIL=webmaster@example.com
*        start date: Fri, 07 Aug 2015 10:56:44 GMT
*        expire date: Sun, 07 Aug 2016 02:03:43 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
Status: install ok installed
Priority: optional
Section: web
Installed-Size: 307
Maintainer: Alessandro Ghedini <ghedo@debian.org>
Architecture: amd64
Multi-Arch: foreign
Version: 7.44.0-2
Depends: libc6 (>= 2.17), libcurl3-gnutls (= 7.44.0-2), zlib1g (>= 1:1.1.4)
Description: command line tool for transferring data with URL syntax
 curl is a command line tool for transferring data with URL syntax,
supporting
 DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3,
 POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, TELNET and TFTP.
 .
 curl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP
form
 based upload, proxies, cookies, user+password authentication (Basic,
Digest,
 NTLM, Negotiate, kerberos...), file transfer resume, proxy tunneling and a
 busload of other useful tricks.
Homepage: http://curl.haxx.se


Grüße,
Antonio