Subject: [TLS] Client certificate alerts

From: David Benjamin <[email-masked]>
Date: Sat, 17 Sep 2016 20:09:40 +0000

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

---

From: Hubert Kario <[email-masked]>
Date: Mon, 19 Sep 2016 15:00:26 +0200

> https://github.com/tlswg/tls13-spec/pull/640

+1 

> Does anyone actually send this alert? OpenSSL does not appear to.

I've done a quick survey of about 60 servers, given the different 
intolerancies and limits they appear to have. Just that 60 servers were 
handled by at least a dozen different implementations, 2 of which were unique 
and unless people already deployed 1.1.0 in droves, the dominant 
implementation didn't look like OpenSSL.

So I don't think we should guide ourselves with what OpenSSL does or doesn't 
do.

> My best

if it was already misused by multiple people, deprecating it and creating a 
new one probably is a good idea to make it unambiguous.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic