Summary: | OpenSSL 1.1.1 and client-certificate renegotiation causes 1 minute delay | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | William Perry <wmperry> |
Component: | mod_ssl | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 2.4.34 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Attachments: | Trace5 logs of the renegotiation |
Description
William Perry
2018-09-07 13:13:11 UTC
We are currently adding support for TLSv1.3 for the next 2.4.x release. If you like, you can test your setup against https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x to see if this delay has been eliminated by the recent changes in renegotiation/client cert handling. Would be good to know. Thanks! Created attachment 36161 [details]
Trace5 logs of the renegotiation
I downloaded the latest on that branch as of a few days ago (, and the behaviour is still the same. Full renegotiation is done, certificate is verified, and then a timeout of 1 minute while the SSL_peek() fails. Attaching logs @ trace5
Status back to 'new' - please let me know if you need any additional info. Thanks for the logs. I can't currently promise to work on it myself, but some info: - the branch tlsv1.3-for-2.4.x has been merged just 3 days ago into the normal 2.4.x branch. So any further tests can be done against the normal branch, unless something needs to get tested which might only exist in trunk, in which case that would b the right source. The tlsv1.3-for-2.4.x should probably considered stale starting now. - what was the client you tested with? - just to make sure: the hang only happens when "RE"negotation occurs due to the VHost having different TLS config than the URI on that VHost that you are trying to access (eg. the access to the VHost is not protected by client certs, but some URLs are). To phrase it differently: when all of the vhost uses the same ssl config including client certs, ciphers etc., then no hang occurs? - As far as I understand this situation, previously handled by renegotiation, gets handled in OpenSSL 1.1.1 by a post-handshake-authentication (PHA) extension and support for PHA is not yet clear for all clients. Especially clients using OpenSSL as their client TLS stack need to explicitly turn on PHA when using OpenSSL 1.1.1. But that's only what I think I understood from other discussions. Thanks and regards, Rainer Moving "SSLVerifyClient require" outside of the <Location> block instantly returns the document. So it does appear to be ONLY the renegotiation case. Note this is testing with TLSv1.2 not 1.3 - I will try to reproduce as well. Can you stick "#warning foo" on a line directly before: SSL_CTX_clear_mode(ctx, SSL_MODE_AUTO_RETRY); in ssl_engine_init.c to make sure that is being enabled when you build? Preferable to test against the 2.4.x branch now. I can't reproduce with 2.4.34+the TLS v1.3 patch from the branch, linked against Fedora 29's OpenSSL 1.1.1. Can you also test with the OpenSSL 1.1.1 final release - the original post was dated before 1.1.1 was tagged - so I guess you were you testing with a -pre release? Using the released OpenSSL 1.1.1 and the latest from 2.4.x seems to work without any noticeable delay. Guess this one can go to resolved. I was using 1.1.1-pre9. thanks. |