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: https://github.com/tlswg/tls13-spec/pull/640 Second, there is the access_denied alert. This alert has an unfortunate name. Per spec, it is for: access_denied 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?) David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
