TLSv1.3 client certificate authentication with renegotiation unsupported in browsers

[Andreas Hasenack]

This is mostly a place holder bug, as more information becomes available.

What is known so far is that a certain configuration of client certificate authentication using TLSv1.3 is not working with most (all at this point?) browsers, resulting in the server returning this error message:

Forbidden

You don't have permission to access / on this server.
Reason: Cannot perform Post-Handshake Authentication.
Apache/2.4.38 (Ubuntu) Server at disco-apache-client-cert.lxd Port 443

It also logs it to error.log:
[Fri Jun 28 16:59:24.596425 2019] [ssl:error] [pid 1391:tid 139642783385344] [client 10.0.100.1:41452] AH10129: verify client post handshake
[Fri Jun 28 16:59:24.596493 2019] [ssl:error] [pid 1391:tid 139642783385344] [client 10.0.100.1:41452] AH10158: cannot perform post-handshake authentication
[Fri Jun 28 16:59:24.596513 2019] [ssl:error] [pid 1391:tid 139642783385344] SSL Library Error: error:14268117:SSL routines:SSL_verify_client_post_handshake:extension not received

These are upstream bugs about it:
Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1511989
Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=911653
Apache2 (invalid): https://bz.apache.org/bugzilla/show_bug.cgi?id=62975

One server workaround is to disable TLSv1.3. Something like this:

SSLProtocol all -SSLv3 -TLSv1.3

("-TLSv1.3" is what was added to that default config)

Sample server config to show the problem (minus the SSL certificate parameters):
<Location />
    SSLVerifyClient require
    Require ssl-verify-client
</Location>

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.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Andreas Hasenack (ahasenack)]

There is nothing that needs fixing in Apache here, it's a client (i.e., browser) issue.

[Matthias Klose (doko)]

seen with bionic as well

[Andreas Hasenack (ahasenack)]

This can be enabled in firefox 68+ by going to "about:config" and setting security.tls.enable_post_handshake_auth to true. It's disabled by default (from upstream), not sure why.

[Olivier Tilloy (osomon)]

This is implemented in firefox, but not enabled by default indeed. See https://hg.mozilla.org/mozilla-central/rev/1bb8ad865648:

  // Turn off post-handshake authentication for TLS 1.3 by default,
  // until the incompatibility with HTTP/2 is resolved:
  // https://tools.ietf.org/html/draft-davidben-http2-tls13-00
  pref("security.tls.enable_post_handshake_auth", false);

And chrom{e,ium} isn't even considering implementing it until the specification is clarified.