TLS 1.3: cannot perform post-handshake authentication
Reported by
candrews...@gmail.com,
Dec 4
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0 Example URL: https://www.integralblue.com/testhandshake/ Steps to reproduce the problem: Go to a URL that requires TLS 1.3 post-handshake authentication. This can be tested by using Apache 2.4.37 (or later) ensuring that TLS 1.3 is enabled (which it is by default if OpenSSL 1.1 is used to build Apache), and using "SSLVerifyClient require" inside of a Location or Directory section. For example: --- SSLCACertificateFile /etc/ssl/DoD_CAs.pem SSLOCSPEnable on <Directory /var/www/localhost/htdocs/cac> SSLOptions +StrictRequire SSLRequireSSL SSLVerifyClient require SSLVerifyDepth 10 SSLOptions +FakeBasicAuth </Directory> --- Please feel free to test this behavior at https://www.integralblue.com/testhandshake/ What is the expected behavior? Chrome should have performed client certificate authentication (such as asking for the PIN for my smartcard). What went wrong? An Apache error page is generated with this text: --- You don't have permission to access /testhandshake/ on this server. Reason: Cannot perform Post-Handshake Authentication. --- Did this work before? No Chrome version: 72.0.3622.0 Channel: dev OS Version: Fedora 29 Flash Version: See https://bz.apache.org/bugzilla/show_bug.cgi?id=62975 for this issue being reported in Apache (which is invalid; the problem is in Chrome). See https://bugzilla.mozilla.org/show_bug.cgi?id=1511989 for the same issue reported in Firefox.
,
Dec 4
,
Dec 5
Thanks for filing the issue... As per comment#0, it seems like the issue should be tested by using Apache 2.4.37 (or later) and TLS 1.3 which out of scope for TE. Hence adding TE-NeedsTriageHelp label and requesting respective team to have a look into this and help in further triaging it.
,
Dec 5
Post-handshake authentication has a mess of security, semantics, and DoS issues. We have no plans to implement it at this time. I do not believe Firefox implements it either. Some spec work is needed to make it defined in HTTP/1.1 at all and, more importantly, explicitly undefined in HTTP/2 in favor of a multiplexing-friendly solution, before we can safely implement it. I'll see if I can at least get the necessary text into draft-ietf-httpbis-http2-secondary-certs before it's published. For now, clients advertise whether they implement this feature. Your server can use the lack of the post_handshake_auth extension in Chrome's (and Firefox's) ClientHellos to decide how to handle incoming connections. |
||||
►
Sign in to add a comment |
||||
Comment 1 by swarnasree.mukkala@chromium.org
, Dec 4