Bug 1651623

Summary:	problem with client authentication
Product:	[Fedora] Fedora	Reporter:	Fabrice Bellet <fabrice>
Component:	firefox	Assignee:	Gecko Maintainer <gecko-bugs-nobody>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	29	CC:	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