A while back I launched a SSL scanner [1] and got tons of feedback from people at Facebook, Google, Microsoft.
The most divisive item was how to represent SHA1 deprecation. The OPs article doesn't really touch on it, but the reason that Google and everyone else haven't moved on is that there still exist a sizeable number of clients that can only accept SHA1 (and will error on anything else).
I actually suspect that large sites like Facebook, etc will maintain multiple certs at the different levels and dynamically serve the best one up that the client can support. They're already doing things like only serving HSTS to browsers that identify as Chrome, etc.
> I actually suspect that large sites like Facebook, etc will maintain multiple certs at the different levels and dynamically serve the best one up that the client can support.
How would you do that? When the TLS connection is established you know nothing about the client except its IP address. All of the interesting information about the browser is transported via the HTTP stream which is tunneled inside the TLS connection.
HSTS is simple by comparison, as it's only an HTTP header.
Actually the SNI extension is sent in the clear. That's one of the things TLS 1.3 is supposed to fix. (See e.g. http://www.ietf.org/mail-archive/web/tls/current/msg10484.ht... for a discussion about how to handle SNI there). You have a point, though, in that the TLS extensions sent by the client might give you some indication with what client you are talking with. I would not hope for it though, and even if, such heuristics are hell of an ugly hack inside the TLS stack.
Actually, in the case of SNI, the hostname IS sent in plain text. It's sent with the initial ClientHello message so that the server can use it to select the proper server certificate for the session.
That's right, but the root cert is not sent by the server (in my case). More importantly, SHA-1 isn't a problem for root certs, as their signature is not used to verify their integrity.
Because it was seen as easier to use X.509 (aka a certificate) as a delivery of a Trust Anchor (specifically, a "subject name" and "public key" pair) than to invent yet another storage format.
Certificate verification stops when you encounter a TA. Some libraries do the wrong thing and check that the terminal cert is self-signed, but that's not actually required (nor recommended). You just check that the previous cert is signed by the TA, which involves checking the previous cert's signature (aka the intermediate) with the trust anchor's key.
That's why the trust anchor's signature is irrelevant.
See RFC 6024 for a discussion of terminology and concepts.
There's less chance to screw things up if the spec says that root certs should look exactly like all other certs, rather than trimming out parts that shouldn't be needed.
The most divisive item was how to represent SHA1 deprecation. The OPs article doesn't really touch on it, but the reason that Google and everyone else haven't moved on is that there still exist a sizeable number of clients that can only accept SHA1 (and will error on anything else).
I actually suspect that large sites like Facebook, etc will maintain multiple certs at the different levels and dynamically serve the best one up that the client can support. They're already doing things like only serving HSTS to browsers that identify as Chrome, etc.
1 - https://www.expeditedssl.com/simple-ssl-scanner/scan?target_...