O que é a Indicação de Nome de Servidor (SNI)?
Observação: você perceberá que estamos usando aqui o termo tecnicamente correto “Certificado TLS” em vez de “SSL” porque os protocolos TLS, sucessores do SSL, é o que se usa atualmente. Para obter mais explicações, leia nossa publicação sobre TLS vs. SSL.
A Indicação de Nome de Servidor (SNI, Server Name Indication) permite que o servidor hospede com segurança vários Certificados TLS de diversos sites em um único endereço IP. Ele adiciona o nome de host do servidor (site) ao handshake do TLS como uma extensão na mensagem “CLIENT HELLO”.
Dessa forma, o servidor sabe qual site apresentar ao usar IPs compartilhados. Normalmente, as empresas que usam IPs compartilhados em um servidor são empresas de hospedagem e enfrentam o seguinte problema diariamente: “como faço com que meu servidor selecione e apresente o certificado correto?”
Vamos analisar o problema detalhadamente. Em um site HTTP, um servidor usa cabeçalhos HTTP HOST para determinar qual site HTTP ele deve apresentar. No entanto, no uso do TLS (o protocolo por trás do HTTPS), é necessário criar a sessão segura antes que seja possível estabelecer a sessão HTTP; enquanto isso não for feito, nenhum cabeçalho de host estará disponível.
Então este é o dilema: com HTTPS, não é possível concluir o handshake do TLS no navegador sem um Certificado TLS em primeiro lugar, mas o servidor não sabe qual certificado apresentar porque não pode acessar o cabeçalho do host.
O que é a SNI e como ela pode ajudar?
A Indicação de Nome de Servidor (SNI) é uma extensão do protocolo TLS. O cliente especifica a qual nome de host ele quer se conectar usando a extensão SNI no handshake do TLS. Isso permite que um servidor (por exemplo, Apache, Nginx ou um balanceador de carga como HAProxy) selecione a chave privada correspondente e a cadeia de certificados que são necessários para estabelecer a conexão de uma lista ou um banco de dados e ao mesmo tempo hospedar todos os certificados em um único endereço IP.
Quando a SNI é usada, o nome de host do servidor é incluído no handshake do TLS. Isso permite que sites HTTPS tenham Certificados TLS exclusivos, mesmo que estejam em um endereço IP compartilhado.
Você pode se perguntar por que isso é tão importante. Por que precisamos de uma maneira de permitir certificados exclusivos para IPs compartilhados?
O Dilema da Escassez de IPv4
A versão 4 do Protocolo de Internet (IPv4) tem cerca de 4 bilhões de endereços IP. Porém, já existem mais de 4 bilhões de computadores conectados à Internet no mundo todo, portanto estamos diante de uma escassez de endereços IPv4. A versão 6 do Protocolo de Internet (IPv6) deve corrigir esse problema, oferecendo trilhões de endereços, mas alguns equipamentos de rede existentes ainda não são compatíveis com o IPv6. Estima-se que 90% dos sistemas operacionais comuns de celulares, computadores e servidores sejam compatíveis com o IPv6. Assim sendo, estamos chegando muito perto da compatibilidade total com o IPv6. Contudo, para os poucos sistemas antigos que ainda precisam de IPs compartilhados, pode ser necessário adotar uma abordagem dupla: SNI para IPv4 para os poucos navegadores antigos e IPs exclusivos para todos os domínios por meio de IPv6 para o restante.
Como a SNI pode ajudá-lo e solucionar a escassez de IPv4
Com a SNI, o servidor pode hospedar com segurança vários Certificados TLS de vários sites em um único endereço IP.
Assim, menos endereços IP são necessários e utilizados, tornando os endereços IP mais disponíveis. Embora chegue o momento em que ficaremos sem endereços IPv4, o processo fica mais lento e dá às pessoas mais tempo para começarem a usar navegadores, roteadores e servidores compatíveis.
A SNI também facilita muito a configuração e o gerenciamento de vários sites porque todos eles podem apontar para o mesmo endereço IP. Além disso, existe a vantagem de que a simples varredura de um endereço IP não revela o certificado, o que aumenta a segurança geral.
A SNI tem alguma desvantagem?
É claro que a SNI é uma excelente solução para IPs compartilhados, mas ainda existe uma pequena desvantagem, que afeta somente um número muito pequeno dos usuários de Internet: aqueles que utilizam navegadores ou sistemas operacionais antigos.
A SNI não é compatível com navegadores e servidores da web antigos. Todos os navegadores modernos (geralmente com menos de seis anos) podem trabalhar bem com a SNI, mas os dois maiores navegadores antigos que têm problemas com a SNI são o Internet Explorer no Windows XP (ou anteriores – estima-se que eles foram usados para acessar sites por 3,18% dos usuários em abril de 2018) e o Android 2.3 e anteriores (usados por aproximadamente 0,3% dos usuários do Android). Se o navegador ou sistema operacional antigo não é compatível com a SNI, o handshake escolhe o certificado padrão, o que pode resultar em um erro comum de incompatibilidade de nome.
O uso do XP e de versões anteriores ao Android 2.3 continuará diminuindo, portanto os problemas de compatibilidade se tornarão cada vez menos importantes. Também é bom lembrar que o Windows XP não é compatível com TLS 1.1 ou TLS 1.2, e que com os próximos requisitos do PCI, os usuários não poderão mais visitar muitos sites de qualquer forma.
O uso desses navegadores está em declínio e continuará diminuindo, mas isso significa que uma porcentagem dos usuários da web continuará tendo problemas para receber um site HTTPS se ele for apresentado por meio da SNI.
Temos aqui uma lista completa dos navegadores e das versões compatíveis e incompatíveis com a SNI.
Uma maneira de contornar esse problema é usar um TLS de vários domínios como certificado padrão para que seja possível listar todos os domínios no IP compartilhado em um único certificado (leia mais sobre isso abaixo).
Outro aspecto importante sobre a SNI é que a conexão começa sem criptografia no TLS 1.2, expondo os clientes a censura e inspeção. O TLS 1.3 resolveu esse problema, mas ainda não é totalmente compatível. Portanto esteja preparado para começar a usar o TLS 1.3 assim que ele for amplamente adotado.
Esses desafios com certeza não são suficientes para degradar a beleza da SNI. Recomendamos que você use a SNI sempre que puder.
Diferenças entre SNI e SANs
Um Certificado de Vários Domínios (às vezes chamado Certificado SAN) representa outra maneira de lidar com a escassez de IPv4. Os Certificados TLS de Vários Domínios não têm as desvantagens de compatibilidade com navegadores ou servidores que a SNI tem. Eles funcionam como qualquer outro Certificado TLS e abrangem até 200 domínios em um único certificado. Por outro lado, a SNI pode facilmente hospedar milhões de domínios no mesmo endereço IP.
Por que então não usamos apenas Certificados de Vários Domínios?
Em um Certificado de Vários Domínios, todos os domínios precisam ser adicionados a esse certificado. Esses domínios são listados como Nomes Alternativos de Assunto, ou SANs. Se um SAN precisa ser adicionado ou removido, ou se um certificado precisa ser revogado ou renovado, o certificado precisa ser substituído e implantado novamente em todos os domínios. Também fica visível quem compartilha o mesmo certificado. Para as empresas que obtêm seus certificados de uma empresa de hospedagem, por exemplo, que utiliza Certificados de Vários Domínios para seus clientes, pode não ser muito agradável compartilhar um certificado com a concorrência.
Isso também torna o certificado maior, e quanto mais nomes são adicionados, maior fica o certificado. Embora estejamos falando apenas de quilobytes, essa informação precisa ser baixada antes que seja possível baixar qualquer outra coisa nos sites. Essencialmente, isso impede que o site seja carregado por um milissegundo ou mais, dependendo da conexão de Internet; não é de forma alguma um grande atraso, mas quando a concorrência pela classificação no Google é acirrada, alguns milissegundos na velocidade de carregamento da página podem significar muita coisa.
Outra desvantagem importante é que Certificados de Vários Domínios não podem aceitar SANs de OV (Validação por Organização) ou de EV (Validação Estendida) quando compartilhados entre organizações. Por exemplo, na situação da empresa de hospedagem mencionada anteriormente, com domínios de várias empresas listados como SANs em um único certificado, esses domínios estariam no nível DV (Validação por Domínio). Esses níveis de validação referem-se à quantidade de informações que são verificadas antes da emissão do certificado. DV significa que o proprietário do site demonstrou controle administrativo sobre o domínio, enquanto OV e EV também verificam informações sobre a identidade do proprietário do site (por exemplo, existência jurídica e operacional).
Entre os usuários conhecidos de Certificados de Vários Domínios estão a Cloudflare e a Google. A Google só os utiliza para clientes antigos que não têm compatibilidade com a SNI.
Então o que preciso fazer? Devo usar a SNI ou Certificados de Vários Domínios?
Em geral, apesar de a SNI e os Certificados de Vários Domínios fazerem a mesma coisa, ou seja, reduzir a quantidade de endereços IPv4 necessários, eles fazem isso de maneiras opostas:
Com a SNI, é possível ter certificados exclusivos para cada domínio (ou seja, muitos certificados), enquanto esses domínios compartilham o mesmo IP. Os Certificados de Vários Domínios, por outro lado, simplesmente usam um certificado para muitos domínios, o que por sua vez também significa um IP para muitos domínios.
Fica claro que existe espaço tanto ara a SNI quanto para os Certificados de Vários Domínios, isoladamente ou combinados. Com essas soluções, você pode continuar hospedando certificados para os clientes sem precisar se preocupar com endereços IP dedicados ou compatibilidade.
Se quiser falar com a GlobalSign sobre uma solução que seja ideal para você, entre em contato hoje mesmo.
Fonte: Blog Globalsign
