Bug 1651623

Summary: problem with client authentication
Product: [Fedora] Fedora Reporter: Fabrice Bellet <fabrice>
Component: firefoxAssignee: Gecko Maintainer <gecko-bugs-nobody>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 29CC: 0xalen+redhat, anon.amish, anto.trande, candrews, gecko-bugs-nobody, jhorak, jkaluza, john.j5live, jorton, kengert, lauterba, luhliari, nmavrogi, pahan, pjasicek, rhughes, rstrode, sandmann, stransky
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-02-19 11:13:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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