New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Renegotiation is broken with specific changes in cipher suite #443

Closed
Sp1l opened this Issue Sep 3, 2018 · 6 comments

Comments

Projects
None yet
4 participants
@Sp1l
Contributor

Sp1l commented Sep 3, 2018

I received a request to verify if renegotiation was working with LibreSSL from one of the Apache httpd devs.
With a bit of checking, I found out that it neither worked client- nor server-side.

  • cURL 7.61.0
    • libcurl/7.61.0 LibreSSL/2.7.4 zlib/1.2.11 brotli/1.0.5 nghttp2/1.32.1
    • libcurl/7.61.0 OpenSSL/1.0.2o zlib/1.2.11 nghttp2/1.32.1
  • Apache httpd
    • 2.4.34 LibreSSL 2.7.4
    • 2.5.1 (20180710 snapshot) OpenSSL 1.1.1pre9
cURL Apache Result
OpenSSL LibreSSL SSL_read: error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac, errno 0
LibreSSL LibreSSL SSL_read: error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac, errno 0
LibreSSL OpenSSL SSL_read: error:1401E3FC:SSL routines:CONNECT_CR_FINISHED:sslv3 alert bad record mac, errno 0
OpenSSL OpenSSL HTTP/1.1 200 OK

In all cases, the initial connection is OK, SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384, the errors appear in the renegotiation when the /renegotiate/cipher/ is requested.

Tested with curl -ks --connect-timeout 5 -v --http1.1 https://test.brnrd.eu:42002/renegotiate/cipher
Config in Apache httpd:

LoadModule ssl_module libexec/apache24/mod_ssl.so
LoadModule socache_shmcb_module   libexec/apache24/mod_socache_shmcb.so

Listen 42002 https

SSLHonorCipherOrder on
#SSLPolicy modern
# TLSv1.2 config
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA"

SSLSessionCache         "shmcb:/var/run/apache24/ssl_scache(512000)"
SSLSessionCacheTimeout  300

SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache        "shmcb:/var/run/apache24/ocsp(128000)"

SSLCACertificateFile    "share/certs/ca-root-nss.crt"

<VirtualHost _default_:42002>
DocumentRoot www/apache24/data

SSLEngine On
SSLCertificateFile    /etc/ssl/certs/brnrd.eu.pem
SSLCertificateKeyFile /etc/ssl/priv/brnrd.eu.key

<Location /renegotiate/cipher>
   SSLCipherSuite ECDHE-RSA-AES128-SHA256
</Location>
</VirtualHost>
@icing

This comment has been minimized.

Show comment
Hide comment
@icing

icing Sep 3, 2018

Thanks, @Sp1l. If there is any clarification needed from httpd, please let me know.

icing commented Sep 3, 2018

Thanks, @Sp1l. If there is any clarification needed from httpd, please let me know.

@kinichiro

This comment has been minimized.

Show comment
Hide comment
@kinichiro

kinichiro Sep 3, 2018

Member

With openssl(1) s_server and s_client, it seems that renegotiation succeeds.
I had confirmed that after s_client connecting to s_server, type "r" on s_server terminal.
I tested this with LibreSSL 2.7 and OpenSSL 1.0.2 on OpenBSD 6.3.

Member

kinichiro commented Sep 3, 2018

With openssl(1) s_server and s_client, it seems that renegotiation succeeds.
I had confirmed that after s_client connecting to s_server, type "r" on s_server terminal.
I tested this with LibreSSL 2.7 and OpenSSL 1.0.2 on OpenBSD 6.3.

@icing

This comment has been minimized.

Show comment
Hide comment
@icing

icing Sep 3, 2018

@kinichiro thanks, however it is curious that this combination fails when curl talks to httpd. What can we do to track this down? A wireshark session?

icing commented Sep 3, 2018

@kinichiro thanks, however it is curious that this combination fails when curl talks to httpd. What can we do to track this down? A wireshark session?

@4a6f656c

This comment has been minimized.

Show comment
Hide comment
@4a6f656c

4a6f656c Sep 4, 2018

Member

@Sp1l - thanks for the detailed report.

This is readily reproducible with Apache httpd and openssl s_client - on the Apache side the following minimal configuration (using the OpenBSD port) is sufficient:

LoadModule authz_core_module /usr/local/lib/apache2/mod_authz_core.so
LoadModule mpm_prefork_module /usr/local/lib/apache2/mod_mpm_prefork.so
LoadModule ssl_module /usr/local/lib/apache2/mod_ssl.so
LoadModule unixd_module /usr/local/lib/apache2/mod_unixd.so

Listen 42002 https

User www
Group www

ServerRoot "/var/www"

SSLHonorCipherOrder on
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384

<VirtualHost _default_:42002>
DocumentRoot /var/www/htdocs

SSLEngine On
SSLCertificateFile    /etc/ssl/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key

<Location /renegotiate/cipher>
    SSLCipherSuite ECDHE-RSA-AES128-SHA
</Location>
</VirtualHost>

With openssl s_client being invoked as:

printf "GET /renegotiate/cipher HTTP/1.1\r\nHost: 127.0.0.1:42002\r\n\r\n" |
    openssl s_client -connect 127.0.0.1:42002 -ign_eof

Hitting /renegotiate/cipher is forcing renegotiation with a change of cipher suite (which is pretty uncommon these days) - this is tickling a long standing bug in LibreSSL, which results in the renegotiation failing in this configuration. It will work if you change between AEAD cipher suites (e.g. ECDHE-RSA-AES256-GCM-SHA384 and ECDHE-RSA-CHACHA20-POLY1305) or between non-AEAD cipher suites (e.g. ECDHE-RSA-AES256-SHA and ECDHE-RSA-AES128-SHA), however trying to change from AEAD to non-AEAD or vice versa will fail.

I'll have a diff out to fix this shortly.

Member

4a6f656c commented Sep 4, 2018

@Sp1l - thanks for the detailed report.

This is readily reproducible with Apache httpd and openssl s_client - on the Apache side the following minimal configuration (using the OpenBSD port) is sufficient:

LoadModule authz_core_module /usr/local/lib/apache2/mod_authz_core.so
LoadModule mpm_prefork_module /usr/local/lib/apache2/mod_mpm_prefork.so
LoadModule ssl_module /usr/local/lib/apache2/mod_ssl.so
LoadModule unixd_module /usr/local/lib/apache2/mod_unixd.so

Listen 42002 https

User www
Group www

ServerRoot "/var/www"

SSLHonorCipherOrder on
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384

<VirtualHost _default_:42002>
DocumentRoot /var/www/htdocs

SSLEngine On
SSLCertificateFile    /etc/ssl/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key

<Location /renegotiate/cipher>
    SSLCipherSuite ECDHE-RSA-AES128-SHA
</Location>
</VirtualHost>

With openssl s_client being invoked as:

printf "GET /renegotiate/cipher HTTP/1.1\r\nHost: 127.0.0.1:42002\r\n\r\n" |
    openssl s_client -connect 127.0.0.1:42002 -ign_eof

Hitting /renegotiate/cipher is forcing renegotiation with a change of cipher suite (which is pretty uncommon these days) - this is tickling a long standing bug in LibreSSL, which results in the renegotiation failing in this configuration. It will work if you change between AEAD cipher suites (e.g. ECDHE-RSA-AES256-GCM-SHA384 and ECDHE-RSA-CHACHA20-POLY1305) or between non-AEAD cipher suites (e.g. ECDHE-RSA-AES256-SHA and ECDHE-RSA-AES128-SHA), however trying to change from AEAD to non-AEAD or vice versa will fail.

I'll have a diff out to fix this shortly.

@4a6f656c 4a6f656c changed the title from Renegotiation broken w/ Apache httpd & cURL to Renegotiation is broken with specific changes in cipher suite Sep 4, 2018

@Sp1l

This comment has been minimized.

Show comment
Hide comment
@Sp1l

Sp1l Sep 5, 2018

Contributor

@4a6f656c So I actually created this issue in the wrong repo... Since there's a non-published patch for this already, I'd think I just leave this here and link the commit in libressl-portable/openbsd when it lands there. Thanks!

Contributor

Sp1l commented Sep 5, 2018

@4a6f656c So I actually created this issue in the wrong repo... Since there's a non-published patch for this already, I'd think I just leave this here and link the commit in libressl-portable/openbsd when it lands there. Thanks!

@4a6f656c

This comment has been minimized.

Show comment
Hide comment
@4a6f656c

4a6f656c Sep 5, 2018

Member

This has been fixed via openbsd/src@f1abf68.

Member

4a6f656c commented Sep 5, 2018

This has been fixed via openbsd/src@f1abf68.

@4a6f656c 4a6f656c closed this Sep 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment