This is a pie-in-the-sky "maybe in 5-10 years if we're lucky" sort of bug, but filing it just so there's some plan on file. So, in TLS, the server can request a client certificate from the user. When this happens, we show a prompt like:

  Select a certificate to
  authenticate yourself to
  www.example.com:

      <Some choices...>

  [ OK ]         [ Cancel ]

There's a whole bunch around client certs that are a disaster, but one of them is that this entire dialog is a lie. In TLS 1.2, we have no reason whatsoever to believe that it was in fact www.example.com that requested the certificate. The CertificateRequest comes in before encryption starts, so it is totally unauthenticated.

Moreover, the client certificate is *sent* before encryption starts. So whatever identity is in the certificate actually just gets leaked everywhere. (The private key is not leaked, so no one can impersonate you. But if your client certificate had, say, an email address, that's leaked.)

TLS 1.3 fixes all this. We need to change the order of some operations in SSLClientSocket ( issue #347402 ), but otherwise, everything works out. We will know it is actually www.example.com, and the certificate is sent encrypted as with anything else over TLS.

(Note that  issue #347402  will *NOT* fix the issue for TLS 1.2. Even if we were to verify the certificate before processing the CertificateRequest, there is nothing binding the CertificateRequest to that verification at the time we need to act on it. And the client certificate is still sent in the clear as before. Though it will clear up some oddities around TLS 1.2 captive portals that request client certificates.)

But  issue #347402  isn't sufficient. The user cannot tell whether TLS 1.3 is being used, so they do not know if the UI is a lie or not. Moreover, even though TLS 1.3 may have been used now, the next connection (which remembers the choice in SSLClientAuthCache) may use TLS 1.2, perhaps because an attacker is doing it.

Once there is enough of a TLS 1.3 client certificate deployment, we should probably do the following:

1. Store in SSLClientAuthCache a bit for cached selection, allow_unencrypted. If the certificate was selected at TLS 1.3, that selection should only be honored in TLS 1.3, and not TLS 1.2. If it was selected at TLS 1.2, either should be fine.

2. When we prompt for certificates, plumb through a bit for whether the client certificate will be encrypted (and whether we have actually authenticated the name). If it will be, use the text as-is. If not, use <do something to communicate this state, even though it will make Enamel extremely unhappy>.

3. Maybe just maybe get rid of TLS 1.2 client certificates someday? Haha, very funny. :-)

It's worth noting that this precondition of there being a TLS 1.3 client certificate deployment is basically "never". Client certificates are primarily used in Enterprise, who are really slow to use anything. TLS 1.3 also requires RSA-PSS, which many smartcards don't support yet, so one can expect TLS 1.3 client cert deployment to be *even slower* than normal.