3

Our web site serves static content through a content delivery network (AWS CloudFront) which is configured to respond to a number of CNAMEs and use our SSL wildcard certificate for these hostnames. Since the CDN may serve many different virtual hosts from the same IP address, SNI support is required on the client-side.

We're well aware that some OS/browser combinations do not support SNI, so we've implemented a fallback to http based on the User-Agent header.

Yet, some customers reported back that content was not being served. There seemed to be no pattern in which browsers or OSes had the problem, e.g. a modern Chrome on a modern Windows would throw an ERR_CONNECTION_CLOSED. Also, entire offices would experience the same problem, so there was a strong indication that the problem stemmed from the network setup rather than individual clients. When we moved to a non-SNI solution the problem went away.

So, my question is if other elements in the network can thwart TLSv1 and/or SNI? Is it possible that gateways, routers, proxies, VPNs, or whatever else you might find in a network setup, can somehow prevent TLSv1/SNI from working?

  • In theory you could do deep packet inspection to identify SNI and then block it, but there would be no point to doing so. I can't imagine anyone has actually intentionally done this, except perhaps the Chinese government. I think a misconfiguration at the client end is much more likely. You should gather more information about the affected clients' networks. – Michael Hampton Nov 3 '14 at 17:07
  • "block" might be the wrong word - could be misunderstood as if something intentionally blocks TLS. If it's possible to misconfigure a network so that TLS doesn't work, I'd be really interested in hearing about that too. – Anders Kaare Nov 4 '14 at 7:57
0

One other possibility is HTTPS capable filtering proxy (like Squid) doing SSL Bumping and incorrectly using wrong (default) certificate based on IP address the connection is established to. See http://www.spinics.net/lists/squid/msg70666.html for a discussion that very much looks like your problem description.

  • That does sound like it could be the culprit! – Anders Kaare Nov 4 '14 at 15:17

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.