1

If I do a packet capture on an https session where SNI is involved, the Client Hello reveals, in plaintext, the hostname that I'm requesting.

I believe that before SNI, there was nothing in an SSL/TLS packet itself that could identify the site somebody was trying to hit. I'm thinking of systems that monitor or filter based on hostname requested. With SNI, they have the ability to do that, even for TLS-encrypted traffic (based on the plaintext Client Hello), whereas they didn't before SNI.

If I install a non-SNI certificate (if I could even get one anymore), does the client still identify itself in the Client Hello packet? Is that just inherent in TLS 1.2 and my references to the SNI "problem" is actually a TLS 1.2 "problem?"

Improve this question

1 Answer 1

Reset to default
5

I believe that before SNI, there was nothing in an SSL/TLS packet itself that could identify the site somebody was trying to hit.

That's wrong. The certificate sent back by the server contains the site name as the subject. Although this is maybe not as specific as SNI since there might be multiple names given as subject (especially true with CDN).

If I install a non-SNI certificate ...

There is no such thing as a SNI or non-SNI certificate. SNI is an extension in the TLS handshake which is needed to support several sites and thus different certificates using the same IP address. It is comparable to the Host header in the HTTP request. And because SNI is used by the client to actually get the certificate matching the target name in the first case it cannot be a property of the certificate.

It is fully up to the client if the SNI extension is used or not. But, all modern browsers and most TLS libraries do it because they need to support the common case of multiple sites sharing the same IP address.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .