Hi folks,

We've run into some problems with client certificate alerts in Chrome that
I'd like to fix going forward.

The first is easy. handshake_failure is an unhelpful alert for server which
required client certs. This confuses users, so we're planning to
heuristically map it to a client certificate error if it's received after
declining to send certs. This seems poor, so I've uploaded this PR which
adds a certificate_required alert:

Second, there is the access_denied alert. This alert has an unfortunate
name. Per spec, it is for:

      A valid certificate [TLS1.3: or PSK] was received, but when access
control was
      applied, the sender decided not to proceed with negotiation.  This
      message is always fatal.

Accordingly, Chrome maps it to a client certificate error. But, by the name
alone, it sounds much more general. We're seeing evidence of some kind of
network filtering software mistakenly sending it to block a connection. (I
can't blame them too much, since we ourselves mistook it for an alert to
send in a server-side DoS handler! This has since been fixed.)

>From an unscientific survey of recent Chrome user complaints about this
error, this is twice as prominent as actual client cert errors! So we'll
want to add another heuristic: if we see access_denied without a
CertificateRequest, map it to a more generic TLS error. This also seems
worth fixing going forward.

Does anyone actually send this alert? OpenSSL does not appear to. My best
rename is certificate_denied if we drop 1.3's "or PSK", but perhaps we can
remove the alert completely? You haven't gotten application data yet, so
you don't really have anything to apply access control on, particularly for
PSK. (For certs, there's post-handshake auth, but I would think you'd send
an application-level error there?)

TLS mailing list

Reply via email to