Наш веб-сайт обслуживает статический контент через сеть доставки контента (AWS CloudFront), которая настроена для ответа на ряд CNAME и использует наш SSL-сертификат с подстановочными знаками для этих имен хостов. Поскольку CDN может обслуживать множество разных виртуальных хостов с одного и того же IP-адреса, на стороне клиента требуется поддержка SNI.
Мы прекрасно понимаем, что некоторые комбинации ОС / браузера не поддерживают SNI, поэтому мы реализовали возврат к http на основе заголовка User-Agent.
Тем не менее, некоторые клиенты сообщили, что контент не обслуживается. Казалось, что не было модели, в которой браузеры или ОС имели проблему, например современный Chrome в современной Windows вызовет ERR_CONNECTION_CLOSED. Кроме того, с той же проблемой столкнутся целые офисы, поэтому было явное указание на то, что проблема связана с настройкой сети, а не с отдельными клиентами. Когда мы перешли на решение без поддержки SNI, проблема исчезла.
Итак, мой вопрос в том, могут ли другие элементы в сети помешать TLSv1 и / или SNI? Возможно ли, что шлюзы, маршрутизаторы, прокси, VPN или что-то еще, что вы можете найти в настройке сети, могут каким-то образом помешать работе TLSv1 / SNI?
Еще одна возможность - это HTTPS-способный фильтрующий прокси (например, Squid), выполняющий SSL Bumping и неправильно использующий неправильный (по умолчанию) сертификат на основе IP-адреса, к которому установлено соединение. Видеть http://www.spinics.net/lists/squid/msg70666.html для обсуждения, которое очень похоже на описание вашей проблемы.