É difícil de acreditar, mas a indicação de nome de servidor (SNI) TLS existe há treze anos. Em nossos tempos modernos, é um dinossauro, mas estranhamente pouco usado, embora isso esteja finalmente mudando, e é neste blog que exploramos como os balanceadores de carga avançados da edgeNEXUS podem oferecer suporte a esse recurso. A SNI lida com um dos maiores problemas que muitos têm com SSL/TLS/HTTPS: a necessidade de dedicar um endereço IP precioso a cada domínio ou subdomínio que precisa ser protegido. Isso é necessário porque o SSL/TLS protege a conexão antes que possamos inspecionar a solicitação HTTP inicial do cliente, que contém esses preciosos detalhes de nome de domínio.
A única maneira de garantir que você forneça o certificado correto é fornecer apenas um por endereço IP e usar o DNS para garantir que as solicitações para um nome de domínio específico sejam roteadas para o endereço IP de um host que forneça o certificado correto para esse domínio. Em uma empresa privada, talvez pudéssemos usar o mesmo endereço IP, mas com uma porta diferente, mas seríamos obrigados a garantir que todos saibam que devem usar a porta não padrão. Essa não é realmente uma opção viável quando você lida com serviços públicos e acessíveis pela Internet.
Poderíamos usar certificados curinga que protegem todos os subdomínios possíveis (*.jetnexus.co.uk, por exemplo), mas ninguém gosta deles, muito menos os tipos de segurança. Independentemente do que você possa pensar sobre os homens e mulheres do NO! do mundo da segurança da informação, eles provavelmente têm razão. É difícil confiar em algo que, por design, representa literalmente tudo ou qualquer coisa em um domínio. Quantos dispositivos armazenam e quantos funcionários têm acesso ao certificado e à chave em uso?
Os certificados de nome alternativo de servidor (SAN) também sempre estiveram disponíveis, mas exigem o conhecimento de cada domínio específico a ser protegido, no momento em que são gerados. Qualquer necessidade de remover ou adicionar um nome de domínio exige que o certificado seja gerado novamente e que todos os hosts relevantes sejam atualizados com ele.
Essa é a escolha cada vez mais difícil que todos nós enfrentamos repetidas vezes (nossos usuários e clientes também): queimar um endereço IP ou aceitar um compromisso (em todos os sentidos). Cada vez mais difícil porque os endereços IP são um recurso finito, cuja disponibilidade diminui e seu valor aumenta a cada dia. Para nossa sorte, esse problema de longa data tem uma solução há muitos anos. Ela nos oferece o melhor de todos os mundos, mas teve pouco impacto até recentemente.
SNI Fornece um método para que o cliente indique ao servidor (no nosso caso, um jetNEXUS) o nome de domínio com o qual está estabelecendo uma conexão. Isso é feito preenchendo um campo de extensão no primeiro pacote TLS do cliente (um hello) com esse nome de domínio. Isso é enviado “às claras” para que possa ser lido antes de o servidor enviar seu certificado SSL/TLS. Isso permite claramente que o servidor envie o certificado esperado (supondo que ele o tenha), independentemente do número de certificados que lhe foi fornecido.
Assim, um único Virtual Service (e endereço IP) pode ser configurado com quantos certificados SSL para quantos nomes de domínio você quiser que ele atenda. Cada um pode ter um certificado SSL dedicado e válido, fornecido corretamente e sem erros, com base nos dados fornecidos pelo cliente. Você pode atender a www.jetnexus.com e www.loadbalance.co.uk no mesmo endereço IP e fornecer certificados válidos para ambos; sem compromisso, sem confusão e sem desperdício de endereço IP.
Além disso, você pode alterar a lista de domínios compatíveis com o Virtual Service sempre que desejar, com apenas alguns cliques na GUI. Você pode adicionar ou remover certificados para adicionar ou remover os domínios compatíveis com o Virtual Service. Só não se esqueça de atualizar seu DNS em conjunto. Se você quiser usar servidores reais diferentes para um ou dois domínios de alto valor, não há problema: basta uma regra flightPATH rápida em poucos minutos. O mesmo vale para a compactação de HTTP, reescrita de URLs ou qualquer outra coisa que você precise. Um único Virtual Service e um único endereço IP para vários domínios são muito desejáveis, mas isso não precisa restringir nenhum tratamento exclusivo que você queira aplicar ao tráfego de domínios diferentes.
Eu ouvi você perguntar: “Qual é a pegadinha?” Bem, certamente havia uma e esse é o motivo pelo qual a SNI existe há tanto tempo, mas só agora está aparecendo no balanceamento de carga e em outros produtos. Esse motivo? Suporte ao cliente. A longevidade da combinação incrivelmente popular entre o Windows XP e o IE6, que não oferece suporte à SNI, impediu que a maioria o usasse. Ninguém quer cortar potencialmente de 10 a 20% do seu público.
O Windows XP já passou do fim do suporte, o IE6 tem menos de 1% de uso na Internet e a atualização gratuita para o Windows 10 está sendo promovida e adotada rapidamente. Finalmente, podemos ter certeza de que a implementação da SNI não afetará nossos clientes e nossos negócios. O IE 7 em diante (no Vista ou posterior) e quase todas as versões do Chrome, Firefox e Safari, exceto as mais antigas, são compatíveis com a SNI. Se você quiser verificar e ter certeza sobre sua base de usuários específica, há uma regra flightPATH para isso também.
Quanto à questão da segurança, vamos ser claros: o cliente está fornecendo informações em texto simples. Essas são informações que podem ser capturadas pelo fio. O cliente também faz uma consulta de DNS em texto simples antes de se conectar. Não podemos controlar isso, portanto, não é considerado um risco revelar essas informações pela segunda vez mais tarde. Talvez você queira verificar se o nome de domínio SNI corresponde ao encontrado no cabeçalho HTTP Host, com uma regra flightPATH, ou talvez você não se importe, pois cada pessoa é diferente. Você acha que isso sugere um problema de segurança? De qualquer forma, o cliente está conectado e a conexão é segura. A menos que você esteja aplicando uma política de segurança com base no nome do domínio (e não deveria), tudo está bem.
Se você realmente quiser mais detalhes, dê uma olhada na RFC3546original (seção 3.1), na RFC6066posterior (seção 3) e, se achar que é confiável: Indicação de nome de servidor no Wikipedi. Se você precisar de segurança no nível do aplicativo, o WAF da edgeNEXUS é baseado na tecnologia de firewall de aplicativo reforçado líder do setor. Disponível na App Store da edgeNEXUS e utilizando a tecnologia de contêineres de última geração, o Firewall de Aplicativos da edgeNEXUS oferece proteção de segurança abrangente para atender aos requisitos de conformidade do PCI-DSS e do OWASP. Conforme discutido em postagens anteriores do blog, o flightPATH é um mecanismo de regras dinâmico e baseado em eventos desenvolvido pela edgeNEXUS para manipular e rotear de forma inteligente o tráfego IP, HTTP e HTTPS com balanceamento de carga. Para saber mais sobre o gerenciamento de tráfego do flightPATH, clique aqui e, para descobrir como aproveitar ao máximo as regras disponíveis, consulte o Guia do Usuário da edgeNEXUS.
Um único Virtual Service (e endereço IP) pode ser configurado com quantos certificados SSL para quantos nomes de domínio você quiser que ele atenda. Cada um pode ter um certificado SSL dedicado e válido, fornecido corretamente e sem erros, com base nos dados fornecidos pelo cliente.
