Qual é a tecnologia por trás do SSL baseado em Hostname (vários ssl vhosts em um único IP)?

Question

O conhecido provedor de PaaS Heroku oferece várias soluções para o problema SSL. Um deles é um produto chamado SSL baseado em nome do host

Isso não é SNI. Eles afirmam que funciona em todos os navegadores em qualquer configuração, mas tem outras desvantagens, principalmente (citando os documentos):

• O SSL baseado em nome do host não funcionará com domínios raiz, pois depende do alias de CNAME de seus nomes de domínio personalizados.

• O nome do host SSL funciona apenas com um domínio. Por exemplo, www.domain.com funcionaria, mas se um segundo certificado for secure.domain.com for adicionado ao aplicativo, ele não funcionará.

• Nossa oferta SSL baseada em nome de host atualmente remove alguns cabeçalhos HTTP; isso pode ser um problema quando seu aplicativo precisa examinar o IP do cliente, por exemplo.

Usando esta solução de construção personalizada, a Heorku pode servir vários sites SSL em um único endereço IP e, como eles afirmam, eles funcionam em qualquer coisa.

Alguém pode explicar o lado técnico desta solução e tecnologia por trás deste produto?

    

Answer 1

Não é bem o que você pensa. O Heroku não está exibindo vários certificados SSL em um único endereço IP. Se você executar um nslookup com diferentes implementações SSL do Hostname, por exemplo, verá que cada um deles aponta para um Amazon ELB diferente . Aí reside o molho secreto.

Quando um cliente solicita SSL com base no nome do host, um ELB é provisionado para ele e o cliente é solicitado a CNAME para o nome de host desse ELB. Esses ELBs se conectam novamente à malha de roteamento Heroku conforme apropriado.

Espero que isso elimine algumas coisas. Sinta-se à vontade para fazer mais perguntas.

    

Answer 2

Eu não sei, então tenho que especular. Isso pode funcionar como resultado de uma interação entre os servidores DNS e os servidores HTTP do Heroku. O fluxo pode ser assim:

1. O cliente está solicitando o link
2. O resolvedor de DNS do cliente resolve www.yourdomain.com como um CNAME para um RR nos servidores de nomes da heroku (por exemplo, app1234.apps.heroku.com)
3. O resolvedor de DNS do cliente consulta o A RR para app1234.apps.heroku.com do servidor de nomes para apps.heroku.com
4. O servidor de nomes para apps.heroku.com distribui um endereço e notifica o servidor web correspondente de um cliente no endereço IP 1.2.3.4 solicitando o host www.seudominio.com.br
5. O cliente inicia um handshake de conexão SSL para app1234.apps.heroku.com
6. O servidor HTTPS, sabendo que o cliente em 1.2.3.4 solicitará www.yourdomain.com como o site, seleciona o certificado correto para www.seudominio.com e prossegue com o handshake SSL

O fluxo pode quebrar em alguns cenários, especialmente com muitos pedidos de sites diferentes originados de um único endereço IP (como seria o caso de clientes por trás de um proxy ou de um gateway NAT), mas isso poderia ser "nivelado" por espalhando as solicitações de hosts de destino diferentes a partir de um único IP de origem entre muitos servidores HTTPS, para que um único servidor HTTPS não tivesse qualquer ambiguidade ao decidir qual certificado escolher para um determinado cliente.