apache 2.4.29-1ubuntu4.12 authentication with client certificate broken

Hi Riho,

Thank you for taking the time to report this bug. I've mentioned this on bug LP: #1845263 as a possible regression related to the
2.4.29-1ubuntu4.12 update that backported the TLSv1.3 support to bionic. That update indicated some expectation that certain environments might be adversely affected when the new protocol is added, so it would be helpful to understand in more detail about your particular setup. That may help identify what went wrong precisely in this case.

Please execute the following command, as it will automatically gather debugging information, in a terminal:

  apport-collect 1865900

Alternatively, if you want to manually attach things (e.g. so you can remove any sensitive information), the files this collects includes:

/etc/apache2/apache2.conf
/etc/apache2/sites-enabled/*
/etc/apache2/conf.d
/var/log/apache2/error.log
`/usr/sbin/apachectl -D DUMP_MODULES`

Obviously the piece that'll need more examination is the client certificate configuration, so if there are other config files or logs of relevance to that you're aware of, those details could be useful as well.

This is likely a dupe of bug 1834671...

I can confirm this as well. I have a CI job that uses python-requests to contact Apache with SSL x590 client authentication. This job passed with apache 2.4.29-1ubuntu4.11 and it fails with apache 2.4.29-1ubuntu4.12.

Passing: https://travis-ci.org/ktdreyer/koji-ansible/builds/655568368
Failing: https://travis-ci.org/ktdreyer/koji-ansible/builds/657818117

apport information

apport information

apport information

apport information

Most clients don't support post handshake authentication, hence can't use client side certificates with TLSv1.3.

In environments where client side certificates are used, TLSv1.3 has to be disabled in the Apache configuration until browsers and other clients support post handshake authentication.

Bug #1834671 also has this possible workaround:
"""
Another workaround is to move the SSLVerifyClient config to the vhost level. It it applied to the whole vhost, and there are no exceptions in specific blocks, then a re-negotiation isn't triggered and the problem doesn't happen.
"""

i.e., it's the change in ssl configuration inside a vhost that triggers the PHA, from my understanding.

> I can confirm this as well. I have a CI job that uses python-requests to contact
> Apache with SSL x590 client authentication. This job passed with
> apache 2.4.29-1ubuntu4.11 and it fails with apache 2.4.29-1ubuntu4.12.

Is this a case where python or python-requests could be updated to handle PHA? Just like firefox was updated in bionic to handle PHA.

Firefox in bionic added an option to handle PHA, but it's disabled by default because it conflicts with http2.

I'm not aware if there's an equivalent "fix" for python-requests.

Perhaps this: https://github.com/urllib3/urllib3/issues/1634

From https://bugzilla.redhat.com/show_bug.cgi?id=1761403:
"The fix is available in urllib3 1.25.4. The fix requires Python 3.7.4 or newer with fix https://bugs.python.org/issue37428 ."

I upgraded urllib3 and requests to the Disco versions:

Unpacking python3-urllib3 (1.24.1-1ubuntu0.1) over (1.22-1ubuntu0.18.04.1) ...
Unpacking python3-requests (2.21.0-1) over (2.18.4-2ubuntu0.1) ...

I still get "HTTPError: 403 Client Error: Forbidden for url: https://localhost/kojihub/ssllogin" in my Bionic VM when I try those versions.

With Bionic's apache 2.4.29-1ubuntu4.12:

"SSLProtocol TLSv1.3 TLSv1.2" - works
"SSLProtocol TLSv1.3 +TLSv1.2" - does not work
"SSLProtocol all -SSLv3" - does not work

There also seems to be https://bugs.python.org/issue37440

In any case, I think this bug is not about apache, other than it's a change introduced there that made tls v1.3 available for clients to use. The clients need to be updated now.

"SSLProtocol all -SSLv3" is in the default /etc/apache2/mods-enabled/ssl.conf. Why does the behavior change when I set "SSLProtocol TLSv1.3 TLSv1.2"?

I guess depends where you change it. If you do it on a specific location or directory, it's my understanding that this is what triggers PHA.

> With Bionic's apache 2.4.29-1ubuntu4.12:
>
>"SSLProtocol TLSv1.3 TLSv1.2" - works

Tried with Firefox 73.0.1 - works, but connection is established using TLS1.2 protocol
when "SSLProtocol TLSv1.3 TLSv1.2 TLSv1.1" is specified, then TLS1.1 is used.

I think we have enough information on this report now; all that remains is some difficult decision making on what, if anything, we can do about it. Depending on the answer, we might need to assign this bug to a different package, etc.

FYI there is a similar bug 1867223 which has a patch suggested at least for some cases of this.

I have uploaded an apache2 package to the security team PPA for testing here: