Bug 1651623 - problem with client authentication
Summary: problem with client authentication
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-20 12:33 UTC by Fabrice Bellet
Modified: 2019-02-19 11:13 UTC (History)
19 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-02-19 11:13:52 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 1471970 0 -- RESOLVED Post handshake authentication is unsupported 2021-02-07 20:44:45 UTC

Description Fabrice Bellet 2018-11-20 12:33:11 UTC
Since my fedora 29 upgrade, my apache servers that require client authentication fail with this error message :

[Tue Nov 20 13:20:57.718509 2018] [ssl:error] [pid 8117] [client x.x.x.x:35692] AH: verify client post handshake
[Tue Nov 20 13:20:57.718565 2018] [ssl:error] [pid 8117] [client x.x.x.x:35692] AH10158: cannot perform post-handshake authentication
[Tue Nov 20 13:20:57.718591 2018] [ssl:error] [pid 8117] SSL Library Error: error:14268117:SSL routines:SSL_verify_client_post_handshake:extension not received

When lowering the tls version in firefox (security.tls.version.max) from 4 to 3 (meaning using tlsv1.2 instead of tlsv1.3 I think), then it works.

Comment 1 Joe Orton 2018-11-20 13:11:14 UTC
This means that Firefox does not enable TLSv1.3 Post-Handshake Authentication, this isn't a mod_ssl problem.

Comment 2 Fabrice Bellet 2018-11-20 16:06:34 UTC
That's right, it works as expected if I put a "SSLVerifyClient require" in the VirtualHost section, but it fails when it's inside a <Location xxx> and not directly at the root of this virtual host.

Comment 3 Jens Lauterbach 2018-11-25 10:46:25 UTC
It is also visible if it's inside a <Directory xxx> block.

The same problem occurs with different browsers, e.g. Firefox, Chrome (Linux/Android). 

It was not visible before the upgrade from Fedora 28 (with openssl 1.1.0i) to Fedora 29 (with openssl 1.1.1)

Comment 4 Craig 2018-12-03 17:53:58 UTC
Reported upstream at https://bz.apache.org/bugzilla/show_bug.cgi?id=62975

Comment 5 Nikos Mavrogiannopoulos 2018-12-07 12:57:35 UTC
It seems that the major browsers have not picked up yet PHA to cope with that use-case.

https://bugs.chromium.org/p/boringssl/issues/detail?id=78
https://bugzilla.mozilla.org/show_bug.cgi?id=1471970

Comment 6 Nikos Mavrogiannopoulos 2018-12-07 13:02:01 UTC
Joe, the last comment in this upstream bug [0] seems to say that PHA is not yet usable for HTTP. Could mod_ssl negotiate TLS1.2 if PHA is not there and the server has per directory access lists with certificates?

[0]. https://bugs.chromium.org/p/chromium/issues/detail?id=911653

Comment 7 Joe Orton 2018-12-13 10:38:40 UTC
The problem is that mod_ssl doesn't know whether PHA is needed at the time of the initial handshake -- precisely the reason POST-handshake auth is used.

I don't see that TLSv1.3+PHA is any more undefined/messy with HTTP/1.1 than renegotiation was under TLSv1.2 and HTTP/1.1.

Comment 8 Martin Stransky 2019-02-19 10:41:14 UTC
Nikos, can we move it upstream or do you want to track it here?

Comment 9 Nikos Mavrogiannopoulos 2019-02-19 11:07:33 UTC
It is up to you

Comment 10 Martin Stransky 2019-02-19 11:13:52 UTC
okay, let's track it upstream then - https://bugzilla.mozilla.org/show_bug.cgi?id=1471970


Note You need to log in before you can comment on or make changes to this bug.