SSL / TLS 101 para iniciantes

Uma análise aprofundada da criptografia que protege nossas conexões à Internet


Embora a Netscape tenha inventado o SSL originalmente em meados dos anos 90, não era obrigatório para todos os sites instalar um certificado SSL / TLS até o verão de 2018, quando o Google começou a marcar sites não criptografados “Não seguro.”

Embora o Google – com seu mecanismo de pesquisa, navegador Chrome e sistema operacional Android – possa redefinir a Internet unilateralmente, não estava sozinho nesse mandato. Apple, Microsoft, Mozilla e outras grandes partes interessadas na indústria de tecnologia tomaram uma decisão concertada de exigir certificados SSL / TLS e HTTPS.

A razão disso é simples: sem SSL / TLS e a capacidade de conectar-se com segurança via HTTPS, todas as comunicações entre sites e visitantes seriam trocadas em texto sem formatação e facilmente legíveis por terceiros.

A única desvantagem desse empurrão recente para a criptografia universal é o fato de forçar o influxo de novos clientes a um mercado desconhecido, que faz muito pouco para se tornar menos confuso para o site ou proprietário médio da empresa.

Este artigo servirá como um guia abrangente para tudo o que é SSL / TLS. Estabeleceremos as bases abordando conceitos básicos como criptografia, HTTPS e a natureza das conexões com a Internet..

Espero que, no final, você se sinta confiante sobre a seleção, a compra e a implementação de um certificado TLS e lembre-se de ter alguma dúvida que possa deixar nos comentários abaixo.

Elementos Fundamentais

Vamos começar discutindo o conceito que reside no coração de tudo isso: criptografia.

A criptografia, em sua iteração mais direta, é pouco mais do que a mistura de dados – usando uma cifra ou chave predeterminada – para que seja tornada ilegível por qualquer pessoa, exceto por outra parte com a mesma chave privada.

Ao longo do histórico, a criptografia de chave privada tem sido o modelo mais comum usado. Na criptografia de chave privada, ambas as partes devem possuir ou pelo menos trocar uma chave privada que possa ser usada para criptografar e descriptografar informações.

No início, a maioria das cifras subjacentes a esses sistemas de criptografia era primitiva, contando com simples substituições ou substituindo palavras comuns por caracteres. Mas com o tempo as cifras se tornaram mais influenciadas pela matemática e cresceram em complexidade.

Por exemplo, em meados dos anos 1600, na França, o criptografador do rei Luís XIV criou uma cifra tão bem projetada que só foi quebrada 250 anos depois e só então parcialmente. Até hoje, existem centenas de anos de registros nos arquivos franceses que nunca podem ser decifrados.

Mas, embora a criptografia historicamente tenha sido um meio de ser secreta ou clandestina, o advento da Internet tomou o conceito mais mainstream. A internet é onipresente e lida com diversas funções críticas. Todos os dias, bilhões de pessoas o usam para acessar e enviar informações confidenciais, gerenciar suas finanças, fazer transações com empresas – o que você quiser.

O problema é que a internet não foi totalmente projetada para se adaptar ao que se tornou. No início, nos dias em que a academia e o governo dos EUA estavam desenvolvendo protocolos de rede, a internet era vista apenas como um mecanismo para a livre troca de informações entre o governo e as instituições acadêmicas. Nesse ponto, a atividade comercial era ilegal online. O comércio eletrônico ainda não havia sido inventado. E o site era mais uma noção geográfica.

Portanto, quando o HTTP ou o Hypertext Transfer Protocol foi introduzido pela primeira vez em 1991, o fato de as conexões que eles formaram trocaram dados em texto sem formatação não era um problema desqualificante.

As coisas estão muito diferentes hoje. As informações trocadas on-line não são pesquisas acadêmicas ou informações disponíveis gratuitamente, são informações de identificação pessoal e dados confidenciais que podem custar dinheiro às pessoas ou mesmo, em algumas regiões, suas vidas. Isso exigia uma abordagem mais segura.

A resposta foi criptografia.

Um problema de troca de chaves

Um problema que atormenta historicamente até os melhores sistemas de criptografia continua a persistir até hoje.

O que discutimos anteriormente e o que tradicionalmente tem sido o padrão para criptografia é a criptografia de chave privada. Isso também é chamado de criptografia simétrica ou criptografia bidirecional – com chaves privadas manipulando as funções de criptografia e descriptografia necessárias para se comunicar.

Para que a criptografia de chave privada funcione, a chave privada deve ser transferida entre as partes ou ambas precisam possuir sua própria cópia. De qualquer maneira, a segurança da chave privada foi fundamental para a integridade do sistema de criptografia e, como você pode sem dúvida supor, a troca de chaves é um problema tão antigo quanto a própria criptografia.

Então, na década de 1970 – tecnicamente duas épocas diferentes, um oceano inteiro à parte – uma nova forma de criptografia foi conceitualizada e trazida à vida: criptografia de chave pública.

Enquanto a criptografia de chave privada é uma função bidirecional, simétrica, com a chave privada capaz de criptografar e descriptografar dados, a criptografia de chave pública é assimétrica; mão única. Em vez de uma única chave privada, existe um par de chaves público-privado. A chave pública lida com criptografia e, como o nome indica, está disponível ao público, enquanto a chave privada, que lida com descriptografia, é mantida em segredo por seu proprietário. Usando a chave pública, é possível criptografar um dado e enviá-lo ao proprietário da chave, onde somente eles poderão descriptografá-lo.

Ótimo, mas como isso é útil?

Bem, a criptografia unidirecional não é ideal para criptografar conexões com a Internet, é meio difícil se comunicar quando uma parte pode criptografar e a outra apenas descriptografar. Não, para criptografar uma conexão com a Internet, você precisará usar criptografia de chave privada simétrica.

Mas como você troca chaves? Especialmente online?

Criptografia de chave pública.

E é isso, destilado em sua essência, o que é SSL / TLS: troca segura de chaves.

É aqui que amarraremos todos esses conceitos. Se você deseja que sua comunicação com um site seja privada, você precisa se conectar a ele com segurança. Se você deseja se conectar com segurança a esse site, precisará trocar chaves privadas simétricas para poder usá-las para se comunicar. SSL / TLS (e PKI em geral) é apenas um mecanismo sofisticado para criar e trocar essa chave de sessão.

Usando SSL / TLS, você pode autenticar o servidor ou a organização com a qual está prestes a se conectar e garantir a troca segura das chaves privadas usadas para criptografar sua comunicação com a parte pretendida..

Infelizmente, SSL / TLS e PKI têm muitas terminologias e partes móveis que podem confundir facilmente as pessoas, mas elas acreditam que, quando você tira toda a matemática e o jargão técnico, essa é apenas uma solução tecnológica moderna e elegante para uma época antigo problema: troca de chaves.

Agora vamos ver alguns termos importantes

Antes de prosseguirmos, vamos abordar alguns outros termos importantes. Já introduzimos o HTTP, protocolo de transferência de hipertexto, que tem sido a espinha dorsal da Internet há décadas. Mas, como discutimos, a Internet evoluiu para algo muito diferente do que era quando o HTTP foi publicado pela primeira vez em 1991..

Um protocolo mais seguro era necessário. Assim, HTTPS.

O HTTPS, que às vezes é chamado de HTTP sobre TLS, usa criptografia para tornar os dados trocados durante uma conexão ilegível para qualquer pessoa, exceto a parte pretendida. Isso é especialmente importante quando você considera a natureza de uma conexão moderna à Internet.

Enquanto nos primeiros dias da Internet uma conexão era razoavelmente direta, agora as conexões são roteadas através de dezenas de dispositivos a caminho de seu destino final. Se você já desejou uma demonstração prática disso, abra o prompt de comando no seu sistema operacional e digite o comando “tracert geekflare.com”.

O que você verá é o caminho que sua conexão percorreu no caminho para o destino. Até 30 saltos. Isso significa que seus dados passam por cada um desses dispositivos antes de chegarem ao site ou aplicativo ao qual você está se conectando. E se alguém tiver um farejador de pacotes ou algum ouvinte instalado em qualquer um desses dispositivos, poderá roubar todos os dados transmitidos e até manipular a conexão em alguns casos.

Isso é chamado de ataque man-in-the-middle (MITM).

Se você quiser aprender sobre o ataque MITM, confira este curso online.

Há muito mais área de superfície para cobrir com conexões modernas à Internet do que a grande maioria das pessoas imagina, e é por isso que ter os dados criptografados durante a transmissão é crítico. Você não tem idéia de quem poderia estar ouvindo ou como é fácil fazer isso.

Uma conexão HTTP é feita via porta 80. Para nossos propósitos, você pode pensar em portas como construções que indicam um serviço ou protocolo de rede. Um site padrão veiculado via HTTP usa a porta 80. O HTTPS geralmente usa a porta 443. Quando um site instala um certificado, ele pode redirecionar suas páginas HTTP para HTTPS, e os navegadores dos usuários tentam se conectar com segurança pela porta 443, com autenticação pendente.

Infelizmente, os termos SSL / TLS, HTTPS, PKI e criptografia são espalhados por toda parte, às vezes até usados ​​de forma intercambiável, para esclarecer qualquer confusão persistente, aqui está um guia rápido:

  • SSL – Secure Sockets Layer, o protocolo de criptografia original usado com HTTPS
  • TLS – Transport Layer Security, o protocolo de criptografia mais recente que substituiu o SSL
  • HTTPS – A versão segura do HTTP, usada para criar conexões com sites
  • PKI – Infra-estrutura de chave pública, refere-se a todo o modelo de confiança que facilita a criptografia de chave pública

SSL / TLS trabalha em conjunto para habilitar conexões HTTPS. E PKI se refere à coisa toda quando você diminui o zoom.

Entendi? Não se preocupe, você vai.

Construindo uma infraestrutura de chave pública

Agora que lançamos as bases, vamos reduzir o zoom e analisar a arquitetura empregada pelo modelo de confiança no coração do SSL / TLS.

Quando você chega a um site, a primeira coisa que seu navegador faz é verificar a autenticidade do certificado SSL / TLS que o site o apresenta. Vamos ver o que acontece depois que a autenticação ocorre em algumas seções, mas vamos começar discutindo o modelo de confiança que torna tudo isso possível.

Então, começaremos fazendo a pergunta: como meu computador sabe se deve confiar em um determinado certificado SSL / TLS?

Para responder a isso, precisamos discutir a PKI e os vários elementos que a fazem funcionar. Começaremos com autoridades de certificação e programas raiz.

Autoridades de certificação

Uma Autoridade de Certificação é uma organização que cumpre um conjunto de padrões predeterminados em troca da capacidade de emitir certificados digitais confiáveis.

Existem dezenas de CAs, gratuitas e comerciais, que podem emitir certificados confiáveis.

Todos eles devem obedecer a um conjunto de padrões que foram debatidos e legislados pelo CA / Browser Forum, que atua como o órgão regulador do setor de TLS. Esses padrões descrevem coisas como:

  • Salvaguardas técnicas que devem estar em vigor
  • Práticas recomendadas para executar a validação
  • Melhores práticas de emissão
  • Procedimentos e prazos de revogação
  • Requisitos de registro de certificado

Essas diretrizes foram estabelecidas pelos navegadores, em conjunto com as autoridades de certificação. Os navegadores desempenham um papel exclusivo no ecossistema TLS.

Ninguém pode chegar a lugar nenhum na internet sem o navegador da web. Como tal, é o navegador que receberá e validará o certificado TLS digital e depois trocará as chaves com o servidor. Portanto, dado seu papel primordial, eles exercem considerável influência.

E é importante ter em mente que os navegadores foram projetados para serem o mais cético possível. Não confiar em nada. Essa é a melhor maneira de manter seus usuários seguros. Portanto, se um navegador confiar em um certificado digital – que pode ser potencialmente mal usado em detrimento do usuário – ele precisa de certas garantias de que quem emitiu esse certificado fez sua devida diligência.

Esse é o papel e a responsabilidade das autoridades de certificação. E os navegadores também não cometem erros. Existe um cemitério literal de antigas CAs que entraram em conflito com os navegadores e foram atacadas.

Quando uma Autoridade de Certificação demonstra sua conformidade com os requisitos da linha de base do CAB Forum e passa todas as auditorias e revisões necessárias, pode solicitar aos vários programas raiz que seus certificados raiz sejam adicionados.

Programas raiz

Um programa raiz – os principais são executados pela Apple, Microsoft, Google e Mozilla – é o aparelho que supervisiona e facilita os armazenamentos raiz (às vezes chamados de armazenamentos confiáveis), que são coleções de certificados de CA raiz que residem no sistema de um usuário. Mais uma vez, essas raízes são incrivelmente valiosas e incrivelmente perigosas – afinal, elas podem emitir certificados digitais confiáveis ​​- portanto, a segurança é a maior preocupação.

É por isso que as CAs quase nunca emitem diretamente dos próprios certificados de CA raiz. Em vez disso, eles criam certificados raiz intermediários e os utilizam para emitir certificados de usuário final ou folha. Eles também podem entregar essas raízes às Sub-CAs, que são Autoridades de Certificação que não têm suas raízes dedicadas, mas ainda podem emitir certificados assinados entre seus intermediários.

Então, vamos juntar tudo isso. Quando um site deseja que um certificado TLS seja emitido, ele gera algo chamado Solicitação de assinatura de certificado (CSR) no servidor em que está hospedado. Contidos nesta solicitação estão todos os detalhes que o site deseja incluir no certificado. Como você verá em breve, a quantidade de informações pode variar de detalhes comerciais completos a uma identidade de servidor simples, mas, uma vez concluído o CSR, ele é enviado à Autoridade de Certificação para emissão.

Antes de emitir o certificado, a CA terá que realizar a devida diligência exigida pelo Fórum da CA / Navegador e validar se as informações contidas no CSR são precisas. Depois de verificado, assina o certificado com sua chave privada e o envia de volta ao proprietário do site para instalação.

Encadeamento de certificados

Após a instalação do certificado TLS, sempre que alguém visitar o site no servidor que o hospeda, apresentará o certificado ao navegador do usuário. O navegador examinará a assinatura digital no certificado, a que foi feita pela autoridade de certificação confiável, que atesta o fato de que todas as informações contidas no certificado são precisas.

É aqui que o termo encadeamento de certificados entra em cena.

O navegador lerá a assinatura digital e moverá um link na cadeia – em seguida, verificará a assinatura digital no certificado intermediário cuja chave privada foi usada para assinar o certificado em folha. Ele continuará seguindo as assinaturas até que a cadeia de certificados termine em uma das raízes confiáveis ​​em seu armazenamento raiz ou até que a cadeia termine sem atingir uma raiz; nesse caso, um erro do navegador aparecerá e a conexão falhará.

É por isso que você não pode emitir e autoassinar seus certificados.

Os navegadores confiarão apenas nos certificados SSL / TLS que podem ser encadeados de volta ao armazenamento raiz (o que significa que foram emitidos por uma entidade confiável). As autoridades de certificação são obrigadas a cumprir padrões específicos para manter sua confiabilidade e, mesmo assim, os navegadores são relutantes em confiar neles.

Os navegadores não têm essas garantias sobre certificados autoassinados, e é por isso que eles devem ser implantados apenas em redes internas, atrás de firewalls e em ambientes de teste.

Tipos de certificado SSL / TLS e funcionalidade

Antes de analisarmos o SSL / TLS em movimento, vamos falar sobre certificados e as várias iterações disponíveis. Os certificados TLS são o que facilitam o protocolo TLS e ajudam a ditar os termos das conexões HTTPS criptografadas que um site faz.

Mencionamos anteriormente que a instalação de um certificado TLS permite configurar seu site para fazer conexões HTTPS via porta 443. Ele também atua como uma espécie de crachá para o site ou servidor com o qual você está interagindo. Voltando à ideia de que, no fundo, SSL / TLS e PKI são formas requintadas de troca segura de chaves, o certificado SSL / TLS ajuda a notificar o navegador de quem está enviando a chave da sessão – para quem a parte do outro lado da a conexão é.

E quando você detalha as várias iterações de certificados SSL / TLS, é importante ter isso em mente. Os certificados variam em relação à funcionalidade e ao nível de validação. Ou, dito de outra maneira, eles variam com base em:

  • Quantas identidades a serem declaradas
  • Quais terminais para afirmar a identidade em

Responder a essas duas perguntas fornecerá uma indicação bastante clara de que tipo de certificado você precisa.

Quantas identidades para afirmar

Existem três níveis diferentes de validação disponíveis com certificados SSL / TLS e variam de acordo com a quantidade de informações de identidade que seu site deseja reivindicar.

  • Certificados SSL de validação de domínio – afirmar identidade do servidor
  • Certificados SSL de validação da organização – afirmar identidade parcial da organização
  • Certificados SSL de validação estendida – afirmar identidade completa da organização

Os certificados SSL de validação de domínio são de longe os mais populares devido ao preço e à velocidade com que podem ser emitidos. Os certificados DV SSL / TLS requerem uma verificação de controle de domínio simples, que pode ser realizada de várias maneiras diferentes, mas assim que o certificado pode ser emitido. Você também pode obter algumas versões de 30 e 90 dias de graça, o que sem dúvida adicionou à sua participação de mercado.

A desvantagem é que os certificados DV SSL afirmam uma identidade mínima. E, como quase a metade de todos os sites de phishing agora possui um certificado DV SSL instalado, eles não necessariamente compram muito em termos de confiança.

Os certificados SSL da validação da organização são o tipo original de certificado SSL / TLS. Eles também são o único tipo de certificado SSL que pode proteger um endereço IP após uma decisão de 2016 do CAB Forum de invalidar todos os certificados SSL da intranet. A validação da organização requer uma avaliação leve dos negócios e geralmente pode ser emitida dentro de um ou dois dias – às vezes mais rápido. Os certificados SSL OV afirmam algumas informações organizacionais, mas um usuário da Internet precisaria clicar no ícone do cadeado e procurá-lo. Atualmente, você vê muitos certificados SSL OV implantados em grandes redes corporativas e corporativas, para conexões feitas por trás de firewalls, por exemplo.

Como nem os certificados SSL DV nem OV afirmam identidade suficiente para satisfazer a maioria dos navegadores, eles recebem tratamento neutro.

Os certificados SSL de validação estendida são, de longe, os mais controversos, já que alguns membros da comunidade tecnológica acham que é necessário fazer mais para fortalecer a validação da qual eles dependem. Mas, EV SSL afirma identidade máxima. Para concluir a validação estendida, a Autoridade de Certificação submete a organização a um rigoroso processo de verificação que pode levar mais de uma semana em alguns casos.

Mas o benefício é inegável: como ele afirma identidade suficiente, um site com um certificado EV SSL recebe tratamento exclusivo do navegador, incluindo a exibição do nome na barra de endereços do navegador..

Não há outra maneira de fazer isso, e você não pode fingir – a barra de endereço EV é um dos indicadores visuais mais potentes que temos hoje.

Quais terminais para afirmar a Identidade em

A outra maneira pela qual os certificados SSL / TLS variam é em relação à funcionalidade. Os sites evoluíram bastante desde os primeiros dias da Internet, com várias empresas implantando sites de maneiras diferentes. Alguns têm vários domínios para diferentes verticais da empresa; outros usam subdomínios para múltiplas funções e aplicativos da web. Alguns usam ambos.

Não importa qual seja o contexto, há um certificado SSL / TLS que pode ajudar a protegê-lo.

Domínio único

O site principal e o certificado SSL padrão são apenas um único domínio. A maioria dos certificados SSL / TLS modernos protegerá as versões WWW e não WWW desse domínio, mas está limitado a um único domínio. Você pode compare os certificados SSL aqui.

Vários Domínios

Certificados de vários domínios ou Certificados de comunicação unificada (no caso dos servidores Microsoft Exchange e Office Communications) também existem para oferecer às organizações a capacidade de criptografar vários domínios com um único certificado. Essa pode ser uma opção atraente, pois economiza dinheiro e simplifica muito o gerenciamento dos certificados (vencimentos / renovações)..

Os certificados de vários domínios e UCC usam SAN, o campo Nome alternativo do sujeito no CSR, para adicionar domínios adicionais ao certificado. A maioria das CAs permite até 250 SANs diferentes em um único certificado. E a maioria dos certificados de vários domínios vem com 2 a 4 SANs complementares, com o restante disponível para compra, conforme necessário.

Certificados SSL curinga

Certificados SSL curinga são um tipo de certificado extremamente útil porque podem criptografar um número ilimitado de subdomínios no mesmo nível da URL. Por exemplo, se você tem um site que usa subdomínios como:

  • app.website.com
  • portal.website.com
  • user.website.com

Você pode criptografar todos eles com o mesmo certificado curinga usando um asterisco no campo FQDN do seu CSR: * .website.com

Agora, qualquer subdomínio, mesmo os que você ainda não adicionou, pode ser protegido com esse certificado.

Existem duas desvantagens nos certificados curinga. A primeira é que, usando a mesma chave pública em alguns pontos de extremidade, você fica mais vulnerável a certas explorações, como ataques de Bleichenbacher.

A outra é que não há opção curinga EV. Devido à natureza aberta da funcionalidade curinga, os navegadores não concordam em delegar a eles esse nível de confiança. Se você deseja a barra de endereço EV em seus subdomínios, precisará criptografá-los individualmente ou usar um certificado de vários domínios EV.

Curinga de vários domínios

Uma adição relativamente nova ao ecossistema SSL / TLS, o curinga de vários domínios pode criptografar até 250 domínios diferentes, mas também pode usar um asterisco nos campos SANs, o que também permite criptografar 250 domínios diferentes E todos os seus respectivos subdomínios de nível superior.

Outro caso de uso para o curinga de vários domínios é o curinga de vários níveis, onde ele pode criptografar subdomínios em vários níveis da URL (um curinga padrão só pode criptografá-los em um nível).

Devido à funcionalidade curinga, os curingas de vários domínios não estão disponíveis no EV, seja.

SSL / TLS em movimento

Agora que abordamos todos os conceitos significativos que compõem SSL / TLS e PKI, vamos juntar tudo e ver em movimento.

Validação e Emissão

Vamos começar desde o início com um site que compra um certificado SSL / TLS de uma CA ou revendedor. Após a compra, o contato organizacional que está lidando com a aquisição do certificado cria uma Solicitação de Assinatura de Certificado no servidor em que o certificado será instalado (o servidor que hospeda o site).

Juntamente com o CSR, o servidor também irá gerar um par de chaves pública / privada e salvar a chave privada localmente. Quando a CA recebe o CSR e a Chave pública, executa as etapas de validação necessárias para garantir que todas as informações contidas no certificado sejam precisas. Geralmente, para certificados de autenticação comercial (não DV), isso envolve procurar informações de registro e registros públicos de uma organização em bancos de dados governamentais.

Após a conclusão da validação, a CA usa uma das chaves privadas de um de seus certificados de emissão, geralmente uma raiz intermediária, e assina o certificado antes de devolvê-lo ao proprietário do site..

Agora, o proprietário do site pode pegar o certificado SSL / TLS recém-emitido, instalá-lo no servidor e configurar o site para fazer conexões HTTPS na porta 443 (usando redirecionamentos 301 para enviar tráfego das páginas HTTP pré-existentes para os novos homólogos HTTPS).

Autenticação e o handshake SSL

Agora que o certificado SSL / TLS está instalado e o site foi configurado para HTTPS, vamos ver como ele facilitará as conexões criptografadas com os visitantes do site..

Ao chegar ao site, o servidor apresentará o certificado SSL / TLS ao navegador do usuário. O navegador do usuário realiza uma série de verificações.

Primeiro, ele vai autenticar o certificado, visualizando sua assinatura digital e seguindo a cadeia de certificados. Ele também garantirá que o certificado não tenha expirado e verificará os logs de transparência do certificado (CT) e as listas de revogação de certificados (CRLs). Desde que a cadeia retorne a uma das raízes do armazenamento confiável do sistema e que seja válida, o navegador confiará no certificado.

Agora é hora do aperto de mão.

O handshake SSL / TLS é a série de etapas em que o cliente (usuário) e o servidor (site) negociam os parâmetros de sua conexão segura, geram e trocam chaves de sessão simétricas.

Primeiro, eles vão decidir sobre um conjunto de cifras. Um conjunto de cifras é o grupo de algoritmos e cifras que serão usados ​​para a conexão. O certificado SSL / TLS fornece uma lista de conjuntos de criptografia que o servidor suporta. Geralmente, um conjunto de criptografia inclui um algoritmo de criptografia de chave pública, um algoritmo de geração de chave, um algoritmo de autenticação de mensagens e um algoritmo de criptografia simétrica ou em massa – embora isso tenha sido refinado no TLS 1.3.

Ao receber a lista de cifras suportadas, o cliente escolhe uma agradável e a comunica ao servidor. A partir daí, o cliente irá gerar uma chave de sessão simétrica, criptografá-la usando a chave pública e depois enviá-la ao servidor, que possui a chave privada necessária para descriptografar a chave da sessão.

Depois que as duas partes tiverem uma cópia da chave da sessão, a comunicação poderá começar.

E isso é SSL / TLS.

Você pode ver como todos os conceitos pelos quais passamos anteriormente interagem entre si para criar um sistema sofisticado e elegante para proteger as conexões à Internet. Usamos criptografia de chave pública para trocar as chaves de sessão com segurança com as quais nos comunicaremos. Os certificados que afirmam a identidade organizacional ou do servidor podem ser confiáveis ​​devido à infraestrutura que temos entre as várias CAs, navegadores e programas raiz.

E a comunicação ocorre como resultado da criptografia de chave privada simétrica, descendente dos sistemas criptográficos clássicos da antiguidade.

Existem muitas partes móveis, mas quando você diminui a velocidade e as entende individualmente, é muito mais fácil ver como tudo funciona juntas.

Antes de partir, vamos terminar com alguns movimentos relacionados ao SSL / TLS que você pode fazer após a instalação / configuração para aproveitar ao máximo seu investimento.

Após SSL / TLS – Aproveitando ao máximo sua implementação

Simplesmente ter um certificado instalado e ter seu site configurado corretamente não significa que ele esteja seguro. O TLS é apenas um componente de uma estratégia holística mais ampla de defesa cibernética. Mas um componente importante, no entanto. Vamos abordar algumas coisas que você pode fazer para garantir que você aproveite ao máximo a implementação.

Desabilitar o suporte do servidor para protocolos antigos

Voltando à conversa que tivemos anteriormente sobre o Cipher Suites, parte da configuração do servidor está decidindo quais conjuntos de cifras e versões SSL / TLS devem suportar. É imperativo que você desabilite o suporte para versões mais antigas de SSL / TLS, bem como algoritmos específicos para evitar vulnerabilidades a várias explorações conhecidas.

O SSL 2.0 e o SSL 3.0 têm mais de 20 anos. A melhor prática foi descontinuar o suporte para eles anos atrás, mas até hoje cerca de 7% dos 100.000 principais do Alexa ainda os permitem. Isso é perigoso porque expõe você a ataques de desconexão e downgrade de SSL, como POODLE.

O TLS 1.0 e o TLS 1.1 também estão no tempo emprestado.

As principais empresas de tecnologia, Apple, Microsoft, Google e Mozilla, anunciaram em conjunto neste outono que depreciarão o suporte ao TLS 1.0 e 1.1 no início de 2020.

As versões do protocolo são suscetíveis a vulnerabilidades como POODLE, FREAK, BEAST e CRIME (todos esses acrônimos). O TLS 1.2 está em vigor há dez anos e deve ser o padrão. O TLS 1.3 foi finalizado no último verão e a adoção está em ritmo constante desde.

Além disso, também existem algoritmos específicos que não devem ser usados. O DES, por exemplo, pode ser quebrado em questão de horas. O RC4 é mais vulnerável do que se pensava e já foi proibido pelas normas de segurança de dados do setor de cartões de pagamento. E, finalmente, dadas as notícias de explorações recentes, não é mais aconselhável usar o RSA para troca de chaves.

Algoritmos / cifras sugeridos:

  • Troca de chaves: curva elíptica Diffie-Helman (ECDH)
  • Autenticação: Algoritmo de assinatura digital de curva elíptica (ECDSA)
  • Criptografia simétrica / em massa: AES 256 no modo contador Galois (AES256-GCM)
  • Algoritmo MAC: SHA-2 (SHA384)

SSL sempre ativo

No passado, os sites às vezes migravam apenas as páginas da Web que coletam informações para HTTPS, enquanto atendiam o restante do site via HTTP. Esta é uma má prática.

Além do fato de o Google marcar essas páginas como “Não seguras”, você também pode expor os visitantes do seu site a riscos, fazendo com que os navegadores alternem entre as páginas criptografadas e as HTTP..

Você deve configurar todo o site para HTTPS. Isso é chamado de SSL sempre ativo. Afinal, não é como se você pagasse pela página, seu certificado SSL / TLS pode criptografar todo o site. Então faça assim.

Configurar um registro CAA (Certificate Authority Authorization)

Um dos riscos mais significativos apresentados pelos certificados digitais, em geral, é a emissão incorreta. Se uma parte diferente de você receber um certificado SSL / TLS para o SEU site, poderá efetivamente se passar por você e causar todos os tipos de problemas.

Os registros da CAA ajudam a atenuar esse risco, restringindo quais autoridades de certificação podem emitir certificados digitais para o seu site. As autoridades de certificação são obrigadas pelo Fórum da CA / Navegador a verificar os registros da CAA antes de emitir qualquer certificado. Se a CA não tiver autorização para emitir para esse site, não poderá. Fazer isso seria considerado uma emissão incorreta e angariaria a ira da comunidade de navegadores.

Adicionar um registro CAA é relativamente fácil, é um registro DNS simples que pode ser adicionado através da interface da maioria das plataformas de hospedagem. Você pode restringir as autoridades de certificação que podem emitir para o seu domínio e também se os certificados curinga também podem ser emitidos para ele..

Adicione seu site à lista de pré-carregamento do HSTS

O HTTP Strict Transport Security, ou HSTS, é um cabeçalho HTTP que força os navegadores apenas a fazer conexões HTTPS com um determinado site. Dessa forma, mesmo se o usuário da web tentar acessar a versão HTTP da página, ele acabará visitando a versão HTTPS. Isso é importante porque fecha a janela para várias explorações conhecidas, como ataques de downgrade e seqüestro de cookies.

Infelizmente, um pequeno vetor de ataque permanece com o HSTS, e é por isso que você deve adicionar seu site à lista de pré-carregamento. Normalmente, quando um visitante chega ao seu site, o navegador faz o download do cabeçalho HTTP e o mantém por quanto tempo a política tiver sido definida para durar. Mas nessa primeira visita, antes de o cabeçalho ser recebido, ainda há uma pequena abertura para um invasor.

A lista de registros de pré-carregamento do HSTS é executada pelo Google e algumas variações são usadas pelos principais navegadores. Esses navegadores sabem apenas se conectar via HTTPS a qualquer site que esteja na lista, mesmo que nunca tenha sido visitado antes. Pode levar uma semana ou duas para o seu site aparecer na lista devido ao fato de que as atualizações da lista são enviadas juntamente com as agendas de lançamento dos navegadores.

Perguntas frequentes sobre SSL / TLS

O que é um certificado X.509?

X.509 refere-se ao tipo de certificado digital usado com SSL / TLS e outros tipos de PKI. X.509 é um padrão de criptografia de chave pública. Ocasionalmente, você verá as empresas usarem o certificado X.509 no lugar de “certificado digital” ou “certificado PKI”.

Por que os certificados SSL / TLS expiram?

Há duas razões para isso.

A primeira é que a internet está mudando continuamente, sites vêm e sites vão. E, dada a sensibilidade dos navegadores em confiar nesses certificados, eles querem saber que os sites que apresentam os certificados estão passando por validações regulares. Não é tão diferente de como você ocasionalmente precisa fazer check-in para atualizar as informações na sua carteira de motorista.

A outra razão é mais técnica. É mais difícil proliferar atualizações e alterações técnicas quando os certificados não expiram por 3 a 5 anos. Visto que, se os certificados expirarem a cada 24 meses, o mais longo prazo que um certificado pode estar desatualizado é de dois anos. Em 2017, a validade máxima foi reduzida de três anos para dois. Provavelmente será reduzido para 12 meses em breve.

Como você renova um certificado SSL / TLS?

A renovação pode ser um pouco inadequada porque você está substituindo o certificado antigo por um certificado recém-emitido. Fazer isso regularmente permite que você fique atualizado com os novos avanços da tecnologia de criptografia e garanta que suas informações de validação permaneçam atualizadas. As CAs podem reutilizar apenas as informações de validação que foram inicialmente fornecidas por tanto tempo antes que os requisitos da linha de base os obriguem a revalidá-las..

Ao renovar, você pode manter o mesmo tipo de certificado que possuía antes, ou pode optar por algo novo, e até alterar CAs. O importante é quanto tempo resta no certificado expirando – você pode levar até três meses. Desde que você renove antes que o certificado expire, você pode continuar o tempo restante e reutilizar qualquer informação de validação que não tenha atingido o tempo limite desde a sua última validação. Se você deixar expirar, você começará do zero.

O que é Inspeção HTTPS?

Muitas empresas maiores e com redes maiores gostam de ter visibilidade sobre seu tráfego. Nesse sentido, o HTTPS é uma faca de dois gumes. Ele protege a privacidade das pessoas, mas também pode ajudar os cibercriminosos a se esconderem. Muitas organizações descriptografam o tráfego HTTPS em um dispositivo de borda ou em uma caixa intermediária e depois o enviam em texto sem formatação por trás do firewall ou o criptografam novamente e o enviam a caminho. Quando você não criptografa novamente o tráfego, ele se chama Terminação SSL. Quando você re-criptografa, isso é chamado de ponte SSL.

O que é o descarregamento SSL?

A transferência de SSL é outra prática corporativa. Em grande escala, executar milhares de handshakes e, em seguida, criptografar e descriptografar todos esses dados pode sobrecarregar os recursos de uma rede. Portanto, muitas redes maiores descarregam as funções SSL para outro dispositivo, para que o servidor de aplicativos possa se concentrar em suas tarefas principais. Isso às vezes é chamado de balanceamento de carga.

Por que minha CA me enviou um certificado intermediário?

Lembre-se anteriormente quando discutimos programas raiz?

O Very OS possui um repositório raiz que ele usa para fazer julgamentos de confiança na PKI. Mas as autoridades de certificação não emitem certificados de usuário final com base nessas raízes, por medo do que aconteceria se algum dia fosse revogado. Em vez disso, eles criam raízes intermediárias e as emitem. O problema é que essas raízes intermediárias não residem no armazenamento confiável de um sistema.

Portanto, se o site não apresentar o certificado intermediário junto com o certificado SSL / TLS em folha, muitos navegadores não poderão concluir a cadeia de certificados e emitirão um aviso. Alguns navegadores armazenam em cache certificados intermediários, mas ainda é considerado uma prática recomendada instalar quaisquer intermediários junto com seu certificado em folha.

De que documentação eu preciso para um certificado SSL de Validação Estendida?

Na maioria dos casos, a Autoridade Certificadora que executa a validação estendida primeiro tentará acessar as informações por meio de recursos de “autoridade governamental” publicamente disponíveis.

No entanto, em alguns locais, isso pode não ser possível. Existem algumas coisas que podem ajudar a acelerar a validação. Embora o número de verificações de validação que uma Carta de Opinião Profissional possa satisfazer tenha sido reduzido recentemente, com um advogado ou contador em boa situação, ainda é possível ajudar consideravelmente.

Além disso, você pode fornecer uma credencial comercial emitida pelo governo ou um documento “Prova de direito” que dê à sua organização o direito de fazer negócios com o nome listado. Alguns exemplos desses documentos são:

  • Artigos de Incorporação
  • Certificados de Formação
  • Licenças comerciais / de fornecedor / comerciante
  • Documentos da Carta
  • Acordos de parceria
  • Registro de Nome Comercial ou Assumido
  • Registro Mercantil

Em Fechamento

Espero que isso lhe dê uma idéia sobre SSL / TLS. Se você estiver interessado em aprender mais, recomendo fazendo este curso online.

Este post foi contribuído por Patrick Nohe, editor de Hashed Out pela loja SSL, um blog que cobre notícias e tendências de segurança cibernética.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map