You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brad Warren <bm...@eff.org> on 2019/08/13 21:50:17 UTC
Disabling TLS session tickets causes handshake failures
Hi,
I work at the Electronic Frontier Foundation on Certbot where we’re having a problem with httpd’s TLS support and it was recommended to me to post the issue to this mailing list. Any additional information about this problem such as whether or not this a known issue, versions of Apache (or its dependencies) that are affected, workarounds, etc. would be greatly appreciated.
Last week, we did a release of Certbot which had it configure httpd to include a configuration file setting “SSLSessionTickets off” in each HTTPS virtual host managed by Certbot. Unfortunately, the addition of this directive caused errors during the TLS handshake in some clients (including Chrome and Firefox) for some of our users. Some of the users affected by this problem were running:
* httpd 2.4.18 (from Ubuntu 16.04)
* httpd 2.4.25 (from Debian 9)
* httpd 2.4.39 (from Amazon Linux 2)
They were presumably using the version of OpenSSL available in those distributions as well although I haven’t been able to verify that yet.
The affected clients and their error messages were:
* Chrome: ERR_SSL_PROTOCOL_ERROR
* Firefox: SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET
* Wget: OpenSSL: error:1408E0F4:SSL routines:ssl3_get_message:unexpected message
Clients that were reported to be unaffected were:
* OpenSSL s_client
* Safari
Curl was affected for some users, but not others. One report of a failure with curl provided the output below from which I removed their domain and IP:
$ curl -v https://example.com
* Rebuilt URL to: https://example.com/
* Trying 1.2.3.4...
* TCP_NODELAY set
* Connected to example.com (1.2.3.4) port 443 (#0)
* schannel: SSL/TLS connection with example.com port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 172 bytes...
* schannel: sent initial handshake data: sent 172 bytes
* schannel: SSL/TLS connection with example.com port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with example.com port 443 (step 2/3)
* schannel: encrypted data got 2960
* schannel: encrypted data buffer: offset 2960 length 4096
* schannel: sending next handshake data: sending 126 bytes...
* schannel: SSL/TLS connection with example.com port 443 (step 2/3)
* schannel: encrypted data got 258
* schannel: encrypted data buffer: offset 258 length 4096
* schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.
* Closing connection 0
* schannel: shutting down SSL/TLS connection with example.com port 443
* schannel: clear security context handle
curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.
Any ideas about what is going on here? So far we have been unable to even reproduce the problem.
Thanks for any help,
Brad Warren
Senior Staff Technologist
Electronic Frontier Foundation
Re: Disabling TLS session tickets causes handshake failures
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 14.08.2019 um 03:03 schrieb Chris Punches <pu...@gmail.com>:
>
> Wouldnt this be a certbot issue?
It is a certbot issue. They are asking us for help in understanding why the server behaves this way.
- Stefan
> On Tue, Aug 13, 2019, 17:50 Brad Warren <bm...@eff.org> wrote:
> Hi,
>
> I work at the Electronic Frontier Foundation on Certbot where we’re having a problem with httpd’s TLS support and it was recommended to me to post the issue to this mailing list. Any additional information about this problem such as whether or not this a known issue, versions of Apache (or its dependencies) that are affected, workarounds, etc. would be greatly appreciated.
>
> Last week, we did a release of Certbot which had it configure httpd to include a configuration file setting “SSLSessionTickets off” in each HTTPS virtual host managed by Certbot. Unfortunately, the addition of this directive caused errors during the TLS handshake in some clients (including Chrome and Firefox) for some of our users. Some of the users affected by this problem were running:
>
> * httpd 2.4.18 (from Ubuntu 16.04)
> * httpd 2.4.25 (from Debian 9)
> * httpd 2.4.39 (from Amazon Linux 2)
>
> They were presumably using the version of OpenSSL available in those distributions as well although I haven’t been able to verify that yet.
>
> The affected clients and their error messages were:
>
> * Chrome: ERR_SSL_PROTOCOL_ERROR
> * Firefox: SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET
> * Wget: OpenSSL: error:1408E0F4:SSL routines:ssl3_get_message:unexpected message
>
> Clients that were reported to be unaffected were:
>
> * OpenSSL s_client
> * Safari
>
> Curl was affected for some users, but not others. One report of a failure with curl provided the output below from which I removed their domain and IP:
>
> $ curl -v https://example.com
> * Rebuilt URL to: https://example.com/
> * Trying 1.2.3.4...
> * TCP_NODELAY set
> * Connected to example.com (1.2.3.4) port 443 (#0)
> * schannel: SSL/TLS connection with example.com port 443 (step 1/3)
> * schannel: checking server certificate revocation
> * schannel: sending initial handshake data: sending 172 bytes...
> * schannel: sent initial handshake data: sent 172 bytes
> * schannel: SSL/TLS connection with example.com port 443 (step 2/3)
> * schannel: failed to receive handshake, need more data
> * schannel: SSL/TLS connection with example.com port 443 (step 2/3)
> * schannel: encrypted data got 2960
> * schannel: encrypted data buffer: offset 2960 length 4096
> * schannel: sending next handshake data: sending 126 bytes...
> * schannel: SSL/TLS connection with example.com port 443 (step 2/3)
> * schannel: encrypted data got 258
> * schannel: encrypted data buffer: offset 258 length 4096
> * schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.
> * Closing connection 0
> * schannel: shutting down SSL/TLS connection with example.com port 443
> * schannel: clear security context handle
> curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.
>
> Any ideas about what is going on here? So far we have been unable to even reproduce the problem.
>
> Thanks for any help,
> Brad Warren
> Senior Staff Technologist
> Electronic Frontier Foundation
Re: Disabling TLS session tickets causes handshake failures
Posted by Chris Punches <pu...@gmail.com>.
Wouldnt this be a certbot issue?
On Tue, Aug 13, 2019, 17:50 Brad Warren <bm...@eff.org> wrote:
> Hi,
>
> I work at the Electronic Frontier Foundation on Certbot where we’re having
> a problem with httpd’s TLS support and it was recommended to me to post the
> issue to this mailing list. Any additional information about this problem
> such as whether or not this a known issue, versions of Apache (or its
> dependencies) that are affected, workarounds, etc. would be greatly
> appreciated.
>
> Last week, we did a release of Certbot which had it configure httpd to
> include a configuration file setting “SSLSessionTickets off” in each HTTPS
> virtual host managed by Certbot. Unfortunately, the addition of this
> directive caused errors during the TLS handshake in some clients (including
> Chrome and Firefox) for some of our users. Some of the users affected by
> this problem were running:
>
> * httpd 2.4.18 (from Ubuntu 16.04)
> * httpd 2.4.25 (from Debian 9)
> * httpd 2.4.39 (from Amazon Linux 2)
>
> They were presumably using the version of OpenSSL available in those
> distributions as well although I haven’t been able to verify that yet.
>
> The affected clients and their error messages were:
>
> * Chrome: ERR_SSL_PROTOCOL_ERROR
> * Firefox: SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET
> * Wget: OpenSSL: error:1408E0F4:SSL routines:ssl3_get_message:unexpected
> message
>
> Clients that were reported to be unaffected were:
>
> * OpenSSL s_client
> * Safari
>
> Curl was affected for some users, but not others. One report of a failure
> with curl provided the output below from which I removed their domain and
> IP:
>
> $ curl -v https://example.com
> * Rebuilt URL to: https://example.com/
> * Trying 1.2.3.4...
> * TCP_NODELAY set
> * Connected to example.com (1.2.3.4) port 443 (#0)
> * schannel: SSL/TLS connection with example.com port 443 (step 1/3)
> * schannel: checking server certificate revocation
> * schannel: sending initial handshake data: sending 172 bytes...
> * schannel: sent initial handshake data: sent 172 bytes
> * schannel: SSL/TLS connection with example.com port 443 (step 2/3)
> * schannel: failed to receive handshake, need more data
> * schannel: SSL/TLS connection with example.com port 443 (step 2/3)
> * schannel: encrypted data got 2960
> * schannel: encrypted data buffer: offset 2960 length 4096
> * schannel: sending next handshake data: sending 126 bytes...
> * schannel: SSL/TLS connection with example.com port 443 (step 2/3)
> * schannel: encrypted data got 258
> * schannel: encrypted data buffer: offset 258 length 4096
> * schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE
> (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is
> received (e.g. handshake failed). More detail may be available in the
> Windows System event log.
> * Closing connection 0
> * schannel: shutting down SSL/TLS connection with example.com port 443
> * schannel: clear security context handle
> curl: (35) schannel: next InitializeSecurityContext failed:
> SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal
> SSL/TLS alert is received (e.g. handshake failed). More detail may be
> available in the Windows System event log.
>
> Any ideas about what is going on here? So far we have been unable to even
> reproduce the problem.
>
> Thanks for any help,
> Brad Warren
> Senior Staff Technologist
> Electronic Frontier Foundation
Re: Disabling TLS session tickets causes handshake failures
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Aug 13, 2019 at 02:50:17PM -0700, Brad Warren wrote:
> * httpd 2.4.18 (from Ubuntu 16.04)
> * httpd 2.4.25 (from Debian 9)
> * httpd 2.4.39 (from Amazon Linux 2)
>
> They were presumably using the version of OpenSSL available in those distributions as well although I haven’t been able to verify that yet.
>
> The affected clients and their error messages were:
>
> * Chrome: ERR_SSL_PROTOCOL_ERROR
> * Firefox: SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET
> * Wget: OpenSSL: error:1408E0F4:SSL routines:ssl3_get_message:unexpected message
I'm not aware of an issue like this, it might be a config which does not
get widely tested.
Trying "SSLSessionTickets off" on Fedora 30 (httpd 2.4.39 + openssl
1.1.1c) seems to work fine with TLSv1.1 thru v1.3 selected client side
(w/same OpenSSL).
Can we get full mod_ssl configuration info, OpenSSL version and ideally
the associated ssl_error_log output?
Regards, Joe
>
> Clients that were reported to be unaffected were:
>
> * OpenSSL s_client
> * Safari
>
> Curl was affected for some users, but not others. One report of a failure with curl provided the output below from which I removed their domain and IP:
>
> $ curl -v https://example.com
> * Rebuilt URL to: https://example.com/
> * Trying 1.2.3.4...
> * TCP_NODELAY set
> * Connected to example.com (1.2.3.4) port 443 (#0)
> * schannel: SSL/TLS connection with example.com port 443 (step 1/3)
> * schannel: checking server certificate revocation
> * schannel: sending initial handshake data: sending 172 bytes...
> * schannel: sent initial handshake data: sent 172 bytes
> * schannel: SSL/TLS connection with example.com port 443 (step 2/3)
> * schannel: failed to receive handshake, need more data
> * schannel: SSL/TLS connection with example.com port 443 (step 2/3)
> * schannel: encrypted data got 2960
> * schannel: encrypted data buffer: offset 2960 length 4096
> * schannel: sending next handshake data: sending 126 bytes...
> * schannel: SSL/TLS connection with example.com port 443 (step 2/3)
> * schannel: encrypted data got 258
> * schannel: encrypted data buffer: offset 258 length 4096
> * schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.
> * Closing connection 0
> * schannel: shutting down SSL/TLS connection with example.com port 443
> * schannel: clear security context handle
> curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.
>
> Any ideas about what is going on here? So far we have been unable to even reproduce the problem.
>
> Thanks for any help,
> Brad Warren
> Senior Staff Technologist
> Electronic Frontier Foundation