3 ms·
> 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 cli
by Perseids 12y ago
> 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.
- sk5t 12y agoNot true; consider SNI as an example of the server choosing a certificate as part of the handshake, without a cleartext exchange of the hostname. http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Server_Name_Indication
- Perseids 12y agoActually 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.html 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.
- bartc 12y agoActually, 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.
- nitrogen 12y agoI think they would use the list of ciphers the browser says it will accept in the TLS handshake, or maybe TLS version. Anything from ClientHello could be used: http://en.wikipedia.org/wiki/Transport_Layer_Security#Basic_TLS_handshake http://en.wikipedia.org/wiki/Transport_Layer_Security#Basic_...