From osg at free.fr Fri Dec 8 13:01:19 2017 From: osg at free.fr (osg at free.fr) Date: Fri, 8 Dec 2017 13:01:19 +0100 (CET) Subject: [mod_gnutls-devel] mod_gnutls: HTTP2 support ? In-Reply-To: <1914268526.204064259.1512733730011.JavaMail.root@zimbra7-e1> Message-ID: <408891003.204241166.1512734478996.JavaMail.root@zimbra7-e1> Hi All, As talked with dkg in #mod_gnutls I got some problem to configure HTTP2 with mod_gnutls: I have configured a virtualhost like this: Protocols h2 h2c http/1.1 #H2Push On #H2ModernTLSOnly On #H2Direct On GnuTLSPriorities SECURE #GNUTLSExportCertificates On curl -k --http2-prior-knowledge -v https://http2.tst.osgpcq.net * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server did not agree to a protocol . * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x55750c614da . * http2 error: Remote peer returned unexpected data while we expected SETTINGS frame. Perhaps, peer does not support HTTP/2 properly. * Curl_http_done: called premature == 1 * Closing connection 0 * TLSv1.2 (OUT), TLS alert, Client hello (1): curl: (16) Error in the HTTP2 framing layer An another virtualhost configured with modssl works fine: curl -k --http2-prior-knowledge -v https://tstssl.dada-support.com * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server accepted to use h2 . * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x5624c265bda0) . * Curl_http_done: called premature == 0 dkg told me maybe ALPN support was not implemented. Could you tell me if I'm doing something wrong ? If not have you some plan to support HTTP2 ? Best regards Vince PS: version used from GNU/Debian 9, and compiled version: Paquet : apache2 Version : 2.4.25-3+deb9u3 Paquet : libapache2-mod-gnutls Version : 0.8.2-3 Source: mod_gnutls-0.8.3.tar.bz2 From osg at free.fr Fri Dec 8 12:44:31 2017 From: osg at free.fr (osg at free.fr) Date: Fri, 8 Dec 2017 12:44:31 +0100 (CET) Subject: [mod_gnutls-devel] mod-gnutls: Ciphers selection problem ? In-Reply-To: <930921491.203794957.1512732487321.JavaMail.root@zimbra7-e1> Message-ID: <426679137.204003728.1512733471088.JavaMail.root@zimbra7-e1> Hi All, As talked with dkg in #mod_gnutls here some informations about ciphers selection problem I got. I have configured this servername with cipher SECURE, and using curl I have this negotiation: TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 ServerName ssl-secure.tst.osgpcq.net GnuTLSPriorities SECURE curl -k -v https://ssl-secure.tst.osgpcq.net * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 If I'm trying to configure an another servername with only one cypher: TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 ServerName ssl-mono.tst.osgpcq.net GnuTLSPriorities NONE:+VERS-TLS-ALL:+ECDHE-RSA:+AES-256-GCM:+SHA384:+COMP-NULL curl -k -v https://ssl-mono.tst.osgpcq.net * error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure Curl is not able to negotiate... Could you indicate me if I haven't configured correctly the GnuTLSPriorities or if the problem is elsewhere ? Best regards Vince PS: version used from GNU/Debian 9, and compiled version: Paquet?: apache2 Version?: 2.4.25-3+deb9u3 Paquet?: libapache2-mod-gnutls Version?: 0.8.2-3 Source: mod_gnutls-0.8.3.tar.bz2 From thomas2.klute at uni-dortmund.de Fri Dec 8 17:13:44 2017 From: thomas2.klute at uni-dortmund.de (Thomas Klute) Date: Fri, 8 Dec 2017 17:13:44 +0100 Subject: [mod_gnutls-devel] mod-gnutls: Ciphers selection problem ? In-Reply-To: <426679137.204003728.1512733471088.JavaMail.root@zimbra7-e1> References: <426679137.204003728.1512733471088.JavaMail.root@zimbra7-e1> Message-ID: <2760ae6b-dc88-a4e7-f7e9-6a09c7534f60@uni-dortmund.de> Am 08.12.2017 um 12:44 schrieb osg at free.fr: > I have configured this servername with cipher SECURE, and using curl I have this negotiation: TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 > ServerName ssl-secure.tst.osgpcq.net > GnuTLSPriorities SECURE > curl -k -v https://ssl-secure.tst.osgpcq.net > * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 > > > If I'm trying to configure an another servername with only one cypher: TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 > ServerName ssl-mono.tst.osgpcq.net > GnuTLSPriorities NONE:+VERS-TLS-ALL:+ECDHE-RSA:+AES-256-GCM:+SHA384:+COMP-NULL > curl -k -v https://ssl-mono.tst.osgpcq.net > * error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure > Curl is not able to negotiate... > > > Could you indicate me if I haven't configured correctly the GnuTLSPriorities or if the problem is elsewhere ? If I run the 00_basic test of the mod_gnutls test suite with the GnuTLSPriorities changed to your value, the error log reports this: [Fri Dec 08 16:50:57.773880 2017] [gnutls:info] [pid 27056:tid 139957247129344] [client ::1:35478] GnuTLS: Handshake Failed (-326) 'No or insufficient priorities were set.' There are two problems here: 1) The only MAC algorithm you have allowed is SHA384, but you are using an AEAD cipher. You have to allow the AEAD MAC algorithm ("+AEAD"). 2) Your GnuTLSPriorities do not include any signature algorithm and group configuration, both of which are required for the handshake. The GnuTLSPriorities string is passed transparently to the GnuTLS library, so please check the GnuTLS priority documentation [1] for possible values. The catch-all solution would be to add "+SIGN-ALL:+GROUP-ALL". Regards, Thomas [1] https://gnutls.org/manual/html_node/Priority-Strings.html From dkg at fifthhorseman.net Fri Dec 8 17:41:16 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 08 Dec 2017 11:41:16 -0500 Subject: [mod_gnutls-devel] mod-gnutls: Ciphers selection problem ? In-Reply-To: <2760ae6b-dc88-a4e7-f7e9-6a09c7534f60@uni-dortmund.de> References: <426679137.204003728.1512733471088.JavaMail.root@zimbra7-e1> <2760ae6b-dc88-a4e7-f7e9-6a09c7534f60@uni-dortmund.de> Message-ID: <87efo518b7.fsf@fifthhorseman.net> On Fri 2017-12-08 17:13:44 +0100, Thomas Klute wrote: > Am 08.12.2017 um 12:44 schrieb osg at free.fr: >> I have configured this servername with cipher SECURE, and using curl I have this negotiation: TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 >> ServerName ssl-secure.tst.osgpcq.net >> GnuTLSPriorities SECURE >> curl -k -v https://ssl-secure.tst.osgpcq.net >> * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 >> >> >> If I'm trying to configure an another servername with only one cypher: TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 >> ServerName ssl-mono.tst.osgpcq.net >> GnuTLSPriorities NONE:+VERS-TLS-ALL:+ECDHE-RSA:+AES-256-GCM:+SHA384:+COMP-NULL >> curl -k -v https://ssl-mono.tst.osgpcq.net >> * error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure >> Curl is not able to negotiate... >> >> >> Could you indicate me if I haven't configured correctly the GnuTLSPriorities or if the problem is elsewhere ? > > If I run the 00_basic test of the mod_gnutls test suite with the > GnuTLSPriorities changed to your value, the error log reports this: > > [Fri Dec 08 16:50:57.773880 2017] [gnutls:info] [pid 27056:tid > 139957247129344] [client ::1:35478] GnuTLS: Handshake Failed (-326) 'No > or insufficient priorities were set.' > > There are two problems here: > > 1) The only MAC algorithm you have allowed is SHA384, but you are using > an AEAD cipher. You have to allow the AEAD MAC algorithm ("+AEAD"). > > 2) Your GnuTLSPriorities do not include any signature algorithm and > group configuration, both of which are required for the handshake. The > GnuTLSPriorities string is passed transparently to the GnuTLS library, > so please check the GnuTLS priority documentation [1] for possible > values. The catch-all solution would be to add "+SIGN-ALL:+GROUP-ALL". In general, you can also test these sorts of things taking mod_gnutls out of the loop by experimenting with gnutls-serv (this binary ships in the gnutls-bin package in debian). If you can't get the priority string to work with gnutls-serv, you probably won't be able to get it to work with mod_gnutls. otoh, if you *can* get it to work with gnutls-serv, but it doesn't work with mod_gnutls, then that might indicate a bug in mod_gnutls. hth, --dkg From thomas2.klute at uni-dortmund.de Wed Dec 13 08:23:17 2017 From: thomas2.klute at uni-dortmund.de (Thomas Klute) Date: Wed, 13 Dec 2017 08:23:17 +0100 Subject: [mod_gnutls-devel] mod_gnutls: HTTP2 support ? In-Reply-To: <408891003.204241166.1512734478996.JavaMail.root@zimbra7-e1> References: <408891003.204241166.1512734478996.JavaMail.root@zimbra7-e1> Message-ID: Am 08.12.2017 um 13:01 schrieb osg at free.fr: > dkg told me maybe ALPN support was not implemented. That is definitely part of the reason. Adding ALPN is fairly simple, but apparently not sufficient. > Could you tell me if I'm doing something wrong ? > If not have you some plan to support HTTP2 ? Patches are welcome. ;-) The attached WIP patch (on top of master branch on https://github.com/airtower-luna/mod_gnutls) adds ALPN support and implements ssl_var_lookup() (which mod_http2 uses to check for TLS session state). With it protocol negotiation works, but the actual request does not. I don't know when I'll have time to find out what else mod_http2 needs, maybe you can find it. > PS: version used from GNU/Debian 9, and compiled version: > Paquet : apache2 > Version : 2.4.25-3+deb9u3 > > Paquet : libapache2-mod-gnutls > Version : 0.8.2-3 > > Source: mod_gnutls-0.8.3.tar.bz2 Are you using the Debian packet (0.8.2) or did you build 0.8.3 from source? -------------- next part -------------- A non-text attachment was scrubbed... Name: http2_alpn_wip.diff Type: text/x-patch Size: 9983 bytes Desc: not available URL: