Nosso site oferece conteúdo estático por meio de uma rede de entrega de conteúdo (AWS CloudFront) que é configurada para responder a vários CNAMEs e usar nosso certificado curinga SSL para esses nomes de host. Como o CDN pode atender a muitos hosts virtuais diferentes do mesmo endereço IP, o suporte a SNI é necessário no lado do cliente.
Sabemos que algumas combinações de SO / navegador não suportam SNI , por isso implementamos um fallback para http com base no cabeçalho User-Agent.
No entanto, alguns clientes informaram que o conteúdo não estava sendo exibido. Não parecia haver nenhum padrão em que os navegadores ou sistemas operacionais tivessem o problema, por exemplo, um Chrome moderno em um Windows moderno lançaria um ERR_CONNECTION_CLOSED . Além disso, escritórios inteiros experimentariam o mesmo problema, portanto, havia uma strong indicação de que o problema estava na configuração da rede, e não em clientes individuais. Quando nos mudamos para uma solução não-SNI, o problema desapareceu.
Então, minha pergunta é se outros elementos na rede podem impedir o TLSv1 e / ou o SNI? É possível que gateways, roteadores, proxies, VPNs ou qualquer outra coisa que você possa encontrar em uma configuração de rede, possa de alguma forma impedir que o TLSv1 / SNI funcione?
Outra possibilidade é o proxy de filtragem com HTTPS (como o Squid) fazendo SSL Bumping e incorretamente usando certificado errado (padrão) com base no endereço IP para o qual a conexão foi estabelecida. Consulte o link para uma discussão que se parece muito com a descrição do seu problema.
Tags tls https sni amazon-cloudfront