Does using SNI have any benefit whatsoever (whether security, scalability, or otherwise) if the TLS certificate validation is performed exclusively using the certificate fingerprint and without regard to the common name? (Examples of systems where this might plausibly be the case include DANE and Convergence.) Even weird benefits that only affect small niche use cases qualify as benefits.

I'm assuming that 100% of visitors will be using fingerprint validation of certificates, so backward-compatibility with common name validation is not a factor.

My motivation for eliminating SNI is that it leaks metadata to a passive eavesdropper. While this is not necessarily a big deal in most cases, it bothers me enough that if it has no benefit in the system I'm describing, I would remove it.

  • For what it's worth, encrypting SNI is on the agenda for TLS 1.3. (You're probably still be leaking the hostname via DNS, though.) Oct 26 '14 at 5:39
  • @MattNordhoff interesting, I wasn't aware of that. I guess while that would prevent passive attacks, it wouldn't prevent active attacks, right? Thanks for the info. Oct 26 '14 at 7:55

(Edited response since you are not confusing SAN and SNI):

With SNI the client sends the expected hostname within the ClientHello. This is necessary if you have multiple certificates behind the same IP address. It does not matter if you validate the certificates the usual way or if you verify it by fingerprint - the only question is if you have a single certificate on the IP (no SNI needed) or multiple certificates (SNI needed).

If the server is under your control and your application should only connect to your server, then a single certificate is enough, so no SNI is needed. But, if you use a CDN then you often have multiple certificates behind the same IP and the relation between the actual server/IP and the hosted certificates might change over time. In this case it is not enough to identify the server as owned by the CDN, but you have to make sure that your certificate is located on the server and you have to tell the server to use the configuration behind the certificate. In this case you need SNI.

And, while the Host header inside an HTTP request also specifies the requested hostname, this is only a property of HTTP (and it is not even required with HTTP/1.0). With protocols like SMTP you don't have such information but SNI is still used with these protocols on the client side (postfix, exim) and also the server side (exim).

  • I'm not confusing them, although I may have explained poorly (if that's the case, I apologize). With applications such as HTTP servers, the HTTP host header will yield the correct website, even if no SNI header is sent. I don't need to distinguish between different websites on the same HTTP server using SNI, because the non-SNI cert can still tell me that I'm talking to the right server (since I'm validating by fingerprint). However, you bring up an interesting question. Are there protocols in wide use other than HTTPS which use only the SNI header to determine what content to send? Oct 26 '14 at 7:41
  • If you only want to identify the "real" server by IP and don't need to distinguish between different virtual servers on the same IP address, then you don't need SNI. As for other protocols: based on a short search postfix will use SNI for when delivering mail but not as server and exim will even be able to serve different certificates if the SMTP client uses SNI. Oct 26 '14 at 8:25
  • "need to distinguish between different virtual servers on the same IP address" what I meant is that you need SNI if these different virtual servers identify different parties which don't need have a relation to the "main" server. For CDN you don't know up-front, which of the CDN servers will handle which hosts, so you have to use SNI to actually get the certificate you want and it is not enough to identify the CDN server itself. Oct 26 '14 at 8:33
  • Since you did not confuse SNI and SAN I've edited the response to answer the question you really had. Oct 26 '14 at 10:38
  • So, I admit that I know just about nothing about how CDN's are designed, so maybe my confusion here is more reflective of my confusion about CDN's rather than confusion about your answer. I don't fully follow why different certificates would be needed for the same machine (which is controlled by a single CDN) just because multiple customers store content there. Why not just have that machine use a single cert, and have clients of all websites using that CDN trust that fingerprint, since by using the CDN you're trusting its operators anyway? Am I horribly confused here? Oct 27 '14 at 11:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.