SNI: Hospedagem Virtual para HTTPS - SSL.com
Início » Sem categoria » SNI: Hospedagem Virtual para HTTPS
Certificado SAN, Indicação do nome do servidor, SNI, hospedagem virtual
HTTPS e Hospedagem Virtual
E os certificados de vários domínios?
Indicação do nome do servidor para o Rescue
Preocupações com o suporte SNI
Preocupações com a privacidade da SNI
Hospedagem virtual é a prática de servir vários sites na Internet mesmo servidor. Embora seja a norma atualmente, isso não era possível nos primeiros dias do HTTP (versões anteriores à 1.1).
Observação: Embora isso não seja tecnicamente correto, para os fins deste artigo "mesmo servidor" indica que todos os nomes de domínio apontam para o mesmo Endereço IP e número da porta.
Originalmente, um servidor só podia hospedar vários sites na mesma máquina (ou seja, no mesmo endereço IP), desde que cada site tivesse uma porta dedicada. Esta não era uma solução ideal porque os navegadores assumem o padrão de porta 80 para HTTP, a menos que o usuário especifique um diferente. Como resultado, a maioria dos proprietários de sites optou por um servidor dedicado para evitar o risco de os usuários não lembrarem o número da porta correto e terminarem em um site diferente.
Hospedando vários sites em várias portas
No entanto, à medida que mais usuários entraram na Web e mais dispositivos de rede começaram a aparecer on-line, o número de endereços IP disponíveis começou a diminuir a um ritmo alarmante. Esse esgotamento antecipado, conhecido como Esgotamento do intervalo de endereços IPv4, levou a indústria a projetar e implementar várias contramedidas, como IPv6 (Sucessor do IPv4), que pode suportar mais endereços do que precisaremos. Infelizmente, embora o IPv6 seja uma solução viável, sua adoção tem sido bastante lenta. De acordo com Estatísticas IPv6 do Google, no momento da redação deste artigo, apenas 25% dos dispositivos da Internet são implantados no IPv6.
A hospedagem virtual também foi implementada como uma atenuação precoce do problema de exaustão, com a introdução do Host cabeçalho em HTTP 1.1. Os navegadores que se comunicam por HTTP 1.1 agora podem se conectar à porta de um servidor 80 e inclua o nome do domínio (por exemplo, www.ssl.com) do site que eles queriam visitar no Host cabeçalho. Independentemente de quantos sites um servidor hospede na mesma porta, ele poderá usar essas informações para identificar o site correto e retornar seu conteúdo.
Hospedagem de vários sites em uma única porta - hospedagem virtual
Numerosos relatórios publicados sobre vulnerabilidades de rede e ataques contra usuários da Web, no entanto, motivaram o setor a comece a se afastar do HTTP inseguro para seu HTTPS alternativo mais seguro. A ampla adoção de HTTPS melhorou a segurança geral do usuário. No entanto, seus aprimoramentos adicionais também aumentaram a complexidade geral das comunicações na web.
Em princípio, HTTPS é bastante semelhante ao HTTP, com a exceção de que as comunicações HTTPS entre navegadores e servidores são criptografadas. Resumidamente, o HTTPS requer que os servidores forneçam aos navegadores um certificado SSL válido emitido por um público confiável autoridade de certificação (CA), como SSL.com. Um navegador pode então usar a chave pública contida no certificado para estabelecer um canal de comunicação criptografado com o servidor. Além disso, um certificado é emitido para um nome de domínio específico, que o navegador verifica para obter uma correspondência com o domínio que o usuário deseja visitar. Portanto, não importa quantos sites o servidor hospede, os navegadores esperam encontrar um certificado SSL válido para o site que solicitaram.
O leitor atento pode já perceber o problema: o navegador requer o certificado do site correto para estabelecer o canal criptografado e enviar o Host cabeçalho, enquanto o servidor precisa do Host cabeçalho para localizar o certificado do site correto. Este é um problema clássico do ovo e da galinha.
Observação: Embora o termo hospedagem virtual foi originalmente cunhado para sites HTTP, também foi transferido para HTTPS. Refere-se à mesma prática de hospedar vários sites em um único servidor, independentemente do método real de implementação.
É evidente que a hospedagem virtual como foi concebida para HTTP não funciona para HTTPS, porque os controles de segurança impedem que os navegadores enviem o Host informações sobre o servidor. No entanto, com o problema de esgotamento do IPv4 ainda sem solução e a adoção cada vez maior da indústria de tecnologias de nuvem (que exigem balanceamento de carga e vários servidores back-end de failover), a hospedagem virtual ainda é uma necessidade.
Uma solução proposta para esse problema é o uso de vários domínios ou Certificados SAN. Um único certificado SAN pode proteger centenas de nomes de domínio diferentes, e os navegadores não reclamarão se encontrarem o nome de domínio que estão tentando visitar na lista de domínios do certificado SAN. Depois que o canal criptografado é configurado, o navegador pode enviar o Host cabeçalho para o servidor e continue como em qualquer outro caso. Esta é uma ótima ideia que utiliza uma tecnologia já presente e disponível, mas os mesmos mecanismos que garantem a segurança dos certificados SAN também introduziram alguns efeitos colaterais potencialmente indesejáveis:
Os certificados SAN são uma boa ferramenta para proteger vários domínios pertencentes à mesma entidade (pessoa, empresa ou organização), mas são um pouco impraticáveis ​​para uso em hospedagem compartilhada; sempre que um novo domínio estiver pronto para ser adicionado ou removido do certificado, um novo certificado com a lista mais recente de domínios deve ser emitido pela CA e reimplantado em todos os domínios.
Além disso, os certificados SAN só podem ser emitidos como Organização validada (OV) ou estendida validada (EV) if todos os domínios pertencem à mesma organização. Esses níveis de validação se referem ao quantidade e tipos de informações do proprietário do certificado em potencial verificadas pela CA antes de emitir o certificado. Foi demonstrado que, quanto maior o nível de validação, maior a confiança dos usuários no site e a confiança do usuário pode afetar o reconhecimento da marca e as taxas de conversão.
Finalmente, é bastante comum em ambientes compartilhados de hospedagem na web que uma empresa compartilhe um servidor com outras empresas ou organizações (mesmo com seus concorrentes). Como os domínios nos certificados SAN são listados publicamente, os proprietários de negócios podem relutar em compartilhar o mesmo certificado com empresas de terceiros.
Embora os certificados SAN sejam ferramentas poderosas e versáteis com inúmeros aplicativos, esses problemas motivaram o IETF - o órgão regulador dos padrões da Internet - a pesquisar abordagens mais adequadas ao problema específico de sites HTTPS hospedados virtualmente.
A solução foi implementada sob a forma de Indicação do nome do servidor (SNI) extensão do TLS protocolo (a parte do HTTPS que lida com criptografia).
O SNI permite que os navegadores especifiquem o nome de domínio ao qual desejam se conectar durante o TLS aperto de mão (a negociação do certificado inicial com o servidor). Como consequência, os sites podem usar seus próprios certificados SSL enquanto ainda estão hospedados em um endereço IP e porta compartilhados, porque os servidores HTTPS podem usar as informações SNI para identificar a cadeia de certificados apropriada necessária para estabelecer a conexão.
Depois, quando o canal de comunicação criptografado tiver sido configurado, o navegador poderá incluir o nome de domínio do site no diretório Host cabeçalho e continuar como faria normalmente. Essencialmente, o SNI executa a mesma função do HTTP Host cabeçalho durante a criação da conexão criptografada.
Hospedagem virtual de sites HTTPS com SNI
Esse truque simples finalmente permitiu que os servidores hospedassem vários sites HTTPS na mesma porta. No entanto, como acontece com a maioria das tecnologias da Internet, o SNI tem algumas limitações.
Embora o SNI esteja bastante maduro desde que foi elaborado pela primeira vez em 1999, ainda existem alguns navegadores legados (IE no Windows XP) e sistemas operacionais (versões do Android <= 2.3) que não o suportam. Para obter uma lista abrangente de navegadores e sistemas operacionais que oferecem suporte a SNI, dê uma olhada em essa mesa.
Embora as participações de mercado de navegadores que não suportam SNI (e, por extensão, as ocorrências desse acontecimento) sejam minúsculas quando comparadas aos navegadores modernos, se um navegador não reconhecer SNI, ele retornará ao certificado SSL padrão e, potencialmente, produzirá um erro de incompatibilidade de nome comum.
Muitas empresas, como o Google, implementam o SNI para os clientes que o suportam e recorrem aos certificados SAN nos casos raros que não o fazem. Naturalmente, espera-se que esse problema diminua à medida que mais usuários e proprietários de empresas atualizam seus sistemas para tecnologias modernas.
A versão estável atual do TLS (versão 1.2) transmite a parte inicial do handshake e, por extensão, as informações de SNI, não criptografadas. Conseqüentemente, um invasor de rede pode descobrir o histórico da web de um usuário, apesar das próprias comunicações web serem totalmente criptografadas.
Vários provedores de serviços em nuvem, como Amazon ou Google, permitiram uma solução alternativa (suja) conhecida como domínio de domínio. O fronting de domínio pode impedir a divulgação do histórico da web porque ofusca as informações SNI usando o nome de host do provedor de nuvem no TLS negociação e o site de destino no cabeçalho HTTP. No entanto, este método não é mais viável, uma vez que Google e Amazon declararam publicamente que suporte desativado para domínio do domínio em seus serviços a partir de abril de 2018.
Felizmente, uma solução mais sistêmica foi proposta como um esboço experimental detalhando o SNI criptografado (ESNI) para o mais novo TLS versão 1.3. A ESNI criptografa as informações SNI, mitigando todas as preocupações com a privacidade. Infelizmente, TLS 1.3 ainda não é amplamente adotado pela indústria, embora TLS 1.3 está lentamente se tornando o protocolo de segurança de rede de fato. Fique de olho nos futuros artigos sobre o status da ESNI e a privacidade do HTTPS e TLS.
Em resumo, com o SNI, você pode hospedar milhões de sites HTTPS em um único servidor. No entanto, dependendo do seu caso individual, um certificado SAN pode funcionar melhor para você. As preocupações de privacidade sobre o SNI ainda existem, embora também exista uma solução potencial com a ESNI. De qualquer forma, usando um ou uma combinação desses dois métodos, você pode implementar facilmente a hospedagem virtual para todos os seus sites com o mínimo de esforço.
Se você tiver mais perguntas sobre SNI ou não souber como escolher entre SANs e SNI, estaremos sempre dispostos a responder a todas as perguntas de nossos clientes sobre seus PKI necessidades. Basta enviar um e-mail para support@ssl.com e um especialista irá ajudá-lo.