<\/p>\n
\u00c9 dif\u00edcil de acreditar, mas a indica\u00e7\u00e3o de nome de servidor (SNI) TLS<\/a> existe h\u00e1 treze anos. Em nossos tempos modernos, \u00e9 um dinossauro, mas estranhamente pouco usado, embora isso esteja finalmente mudando, e \u00e9 neste blog que exploramos como os balanceadores de carga avan\u00e7ados da edgeNEXUS podem oferecer suporte a esse recurso. A SNI lida com um dos maiores problemas que muitos t\u00eam com SSL\/TLS\/HTTPS: a necessidade de dedicar um endere\u00e7o IP precioso a cada dom\u00ednio ou subdom\u00ednio que precisa ser protegido. Isso \u00e9 necess\u00e1rio porque o SSL\/TLS protege a conex\u00e3o antes que possamos inspecionar a solicita\u00e7\u00e3o HTTP inicial do cliente, que cont\u00e9m esses preciosos detalhes de nome de dom\u00ednio. <\/p>\n A \u00fanica maneira de garantir que voc\u00ea forne\u00e7a o certificado correto \u00e9 fornecer apenas um por endere\u00e7o IP e usar o DNS para garantir que as solicita\u00e7\u00f5es para um nome de dom\u00ednio espec\u00edfico sejam roteadas para o endere\u00e7o IP de um host que forne\u00e7a o certificado correto para esse dom\u00ednio. Em uma empresa privada, talvez pud\u00e9ssemos usar o mesmo endere\u00e7o IP, mas com uma porta diferente, mas ser\u00edamos obrigados a garantir que todos saibam que devem usar a porta n\u00e3o padr\u00e3o. Essa n\u00e3o \u00e9 realmente uma op\u00e7\u00e3o vi\u00e1vel quando voc\u00ea lida com servi\u00e7os p\u00fablicos e acess\u00edveis pela Internet. <\/p>\n Poder\u00edamos usar certificados curinga que protegem todos os subdom\u00ednios poss\u00edveis (*.jetnexus.co.uk, por exemplo), mas ningu\u00e9m gosta deles, muito menos os tipos de seguran\u00e7a. Independentemente do que voc\u00ea possa pensar sobre os homens e mulheres do NO! do mundo da seguran\u00e7a da informa\u00e7\u00e3o, eles provavelmente t\u00eam raz\u00e3o. \u00c9 dif\u00edcil confiar em algo que, por design, representa literalmente tudo ou qualquer coisa em um dom\u00ednio. Quantos dispositivos armazenam e quantos funcion\u00e1rios t\u00eam acesso ao certificado e \u00e0 chave em uso? <\/p>\n Os certificados de nome alternativo de servidor (SAN) tamb\u00e9m sempre estiveram dispon\u00edveis, mas exigem o conhecimento de cada dom\u00ednio espec\u00edfico a ser protegido, no momento em que s\u00e3o gerados. Qualquer necessidade de remover ou adicionar um nome de dom\u00ednio exige que o certificado seja gerado novamente e que todos os hosts relevantes sejam atualizados com ele. <\/p>\n Essa \u00e9 a escolha cada vez mais dif\u00edcil que todos n\u00f3s enfrentamos repetidas vezes (nossos usu\u00e1rios e clientes tamb\u00e9m): queimar um endere\u00e7o IP ou aceitar um compromisso (em todos os sentidos). Cada vez mais dif\u00edcil porque os endere\u00e7os IP s\u00e3o um recurso finito, cuja disponibilidade diminui e seu valor aumenta a cada dia. Para nossa sorte, esse problema de longa data tem uma solu\u00e7\u00e3o h\u00e1 muitos anos. Ela nos oferece o melhor de todos os mundos, mas teve pouco impacto at\u00e9 recentemente. <\/p>\n SNI Fornece um m\u00e9todo para que o cliente indique ao servidor (no nosso caso, um jetNEXUS) o nome de dom\u00ednio com o qual est\u00e1 estabelecendo uma conex\u00e3o. Isso \u00e9 feito preenchendo um campo de extens\u00e3o no primeiro pacote TLS do cliente (um hello) com esse nome de dom\u00ednio. Isso \u00e9 enviado \u201c\u00e0s claras\u201d 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\u00famero de certificados que lhe foi fornecido. <\/p>\n Assim, um \u00fanico Virtual Service (e endere\u00e7o IP) pode ser configurado com quantos certificados SSL para quantos nomes de dom\u00ednio voc\u00ea quiser que ele atenda. Cada um pode ter um certificado SSL dedicado e v\u00e1lido, fornecido corretamente e sem erros, com base nos dados fornecidos pelo cliente. Voc\u00ea pode atender a www.jetnexus.com<\/a> e www.loadbalance.co.uk<\/a> no mesmo endere\u00e7o IP e fornecer certificados v\u00e1lidos para ambos; sem compromisso, sem confus\u00e3o e sem desperd\u00edcio de endere\u00e7o IP. <\/p>\n Al\u00e9m disso, voc\u00ea pode alterar a lista de dom\u00ednios compat\u00edveis com o Virtual Service sempre que desejar, com apenas alguns cliques na GUI. Voc\u00ea pode adicionar ou remover certificados para adicionar ou remover os dom\u00ednios compat\u00edveis com o Virtual Service. S\u00f3 n\u00e3o se esque\u00e7a de atualizar seu DNS em conjunto. Se voc\u00ea quiser usar servidores reais diferentes para um ou dois dom\u00ednios de alto valor, n\u00e3o h\u00e1 problema: basta uma regra flightPATH r\u00e1pida em poucos minutos. O mesmo vale para a compacta\u00e7\u00e3o de HTTP, reescrita<\/a> de URLs ou qualquer outra coisa que voc\u00ea precise. Um \u00fanico Virtual Service e um \u00fanico endere\u00e7o IP para v\u00e1rios dom\u00ednios s\u00e3o muito desej\u00e1veis, mas isso n\u00e3o precisa restringir nenhum tratamento exclusivo que voc\u00ea queira aplicar ao tr\u00e1fego de dom\u00ednios diferentes. <\/p>\n Eu ouvi voc\u00ea perguntar: \u201cQual \u00e9 a pegadinha?\u201d Bem, certamente havia uma e esse \u00e9 o motivo pelo qual a SNI existe h\u00e1 tanto tempo, mas s\u00f3 agora est\u00e1 aparecendo no balanceamento de carga e em outros produtos. Esse motivo? Suporte ao cliente. A longevidade da combina\u00e7\u00e3o incrivelmente popular entre o Windows XP e o IE6, que n\u00e3o oferece suporte \u00e0 SNI, impediu que a maioria o usasse. Ningu\u00e9m quer cortar potencialmente de 10 a 20% do seu p\u00fablico. <\/p>\n O Windows XP j\u00e1 passou do fim do suporte, o IE6 tem menos de 1% de uso na Internet e a atualiza\u00e7\u00e3o gratuita para o Windows 10 est\u00e1 sendo promovida e adotada rapidamente. Finalmente, podemos ter certeza de que a implementa\u00e7\u00e3o da SNI n\u00e3o afetar\u00e1 nossos clientes e nossos neg\u00f3cios. O IE 7 em diante (no Vista ou posterior) e quase todas as vers\u00f5es do Chrome, Firefox e Safari, exceto as mais antigas, s\u00e3o compat\u00edveis com a SNI. Se voc\u00ea quiser verificar e ter certeza sobre sua base de usu\u00e1rios espec\u00edfica, h\u00e1 uma regra flightPATH para isso tamb\u00e9m. <\/p>\n Quanto \u00e0 quest\u00e3o da seguran\u00e7a, vamos ser claros: o cliente est\u00e1 fornecendo informa\u00e7\u00f5es em texto simples. Essas s\u00e3o informa\u00e7\u00f5es que podem ser capturadas pelo fio. O cliente tamb\u00e9m faz uma consulta de DNS em texto simples antes de se conectar. N\u00e3o podemos controlar isso, portanto, n\u00e3o \u00e9 considerado um risco revelar essas informa\u00e7\u00f5es pela segunda vez mais tarde. Talvez voc\u00ea queira verificar se o nome de dom\u00ednio SNI corresponde ao encontrado no cabe\u00e7alho HTTP Host, com uma regra flightPATH, ou talvez voc\u00ea n\u00e3o se importe, pois cada pessoa \u00e9 diferente. Voc\u00ea acha que isso sugere um problema de seguran\u00e7a? De qualquer forma, o cliente est\u00e1 conectado e a conex\u00e3o \u00e9 segura. A menos que voc\u00ea esteja aplicando uma pol\u00edtica de seguran\u00e7a com base no nome do dom\u00ednio (e n\u00e3o deveria), tudo est\u00e1 bem. <\/p>\n Se voc\u00ea realmente quiser mais detalhes, d\u00ea uma olhada na RFC3546<\/a>original (se\u00e7\u00e3o 3.1), na RFC6066<\/a>posterior (se\u00e7\u00e3o 3) e, se achar que \u00e9 confi\u00e1vel: Indica\u00e7\u00e3o de nome de servidor no Wikipedi. Se voc\u00ea precisar de seguran\u00e7a no n\u00edvel do aplicativo, o WAF da edgeNEXUS \u00e9 baseado na tecnologia de firewall de aplicativo refor\u00e7ado l\u00edder do setor. Dispon\u00edvel na App Store da edgeNEXUS e utilizando a tecnologia de cont\u00eaineres de \u00faltima gera\u00e7\u00e3o, o Firewall de Aplicativos da edgeNEXUS oferece prote\u00e7\u00e3o de seguran\u00e7a abrangente para atender aos requisitos de conformidade do PCI-DSS e do OWASP. Conforme discutido em postagens anteriores do blog, o flightPATH \u00e9 um mecanismo de regras din\u00e2mico e baseado em eventos desenvolvido pela edgeNEXUS para manipular e rotear de forma inteligente o tr\u00e1fego IP, HTTP e HTTPS com balanceamento de carga. Para saber mais sobre o gerenciamento de tr\u00e1fego do flightPATH, clique aqui e, para descobrir como aproveitar ao m\u00e1ximo as regras dispon\u00edveis, consulte o Guia do Usu\u00e1rio da edgeNEXUS. <\/p>\n <\/p>\n Um \u00fanico Virtual Service (e endere\u00e7o IP) pode ser configurado com quantos certificados SSL para quantos nomes de dom\u00ednio voc\u00ea quiser que ele atenda. Cada um pode ter um certificado SSL dedicado e v\u00e1lido, fornecido corretamente e sem erros, com base nos dados fornecidos pelo cliente. <\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":" \u00c9 dif\u00edcil de acreditar, mas a indica\u00e7\u00e3o de nome de servidor (SNI) TLS existe h\u00e1 treze anos. Em nossos tempos modernos, \u00e9 um dinossauro, mas estranhamente pouco usado, embora isso esteja finalmente mudando, e \u00e9 neste blog que exploramos como os balanceadores de carga avan\u00e7ados da edgeNEXUS podem oferecer suporte a esse recurso. A […]<\/p>\n","protected":false},"author":13,"featured_media":34798,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[377],"tags":[419,1480,1479,1481,1168,1478],"class_list":["post-53078","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-pt-br","tag-balanceador-de-carga","tag-certificados-ssl-pt-br","tag-identificacao-do-nome-do-servidor","tag-seguranca-ssl","tag-ssl-pt-br","tag-tls-sni-pt-br"],"yoast_head":"\n