Como Funciona o Protocolo HTTPS que Torna a Web mais Autêntica e Segura

Sabe aquele aviso de site não seguro que encontramos hora ou outra navegando em páginas na internet. Ele é mostrado quando o site em questão ainda não inplementa a camada de segurança em cima do protocolo HTTP.

Aviso de site não seguro.

O que é HTTP?

O HTTP é um protocolo de comunicação na internet, que significa Hypertext Transfer Protocol (em português Protocolo de Transferência de Hipertexto).

Hipertexto parece um palavrão, mas fui ver no dicionário e nada mais é do que a apresentação de informações escritas, organizadas de maneira que o leitor tem liberdade de escolher entre vários caminhos. E cada caminho provoca a exibição de um novo hipertexto.

No final das contas, hipertexto é uma típica página da Wikipédia ou qualquer outra da internet, onde há texto com links que levam a outras páginas. E o HTTP acaba sendo o protocolo que faz a transferência desse hipertexto na rede.

O HTTP trabalha com requisição e resposta, ou seja, o cliente envia uma requisição e o servidor responde.

Requisição e resposta: estilo de comunicação utilizada pelo http.

O problema é que na vida real, essa comunicação não acontece assim de maneira tão simplificada, diretamente do cliente para o servidor.

Uma requisição típica, geralmente passa por diversos pontos intermediários. Ela pode partir do cliente e ir para uma camada de roteamento, que é o roteador da sua casa por exemplo, depois partir para um modem, na sequência, quem sabe, para um firewall e assim por diante.

Pontos intermediários entre cliente e servidor em que uma requisição http passa.

Todos esses pontos intermediários, representam oportunidade de interceptação dos dados por algum invasor. Por exemplo, um Man-in-the-middle attack em que o invasor retransmite as informações entre duas partes que acreditam estar se comunicando diretamente entre si. Ficando portanto, no meio da comunicação e, dessa forma, tendo acesso a todo o conteúdo trocado entre elas.

No caso do HTTP, que trafega texto puro na rede, se alguém ficar no meio da comunicação, poderá tranquilamente ler as informações.

Justamente por isso, surge essa camada de segurança que incorpora o S de Security ao protocolo e tem como finalidade criptografar os dados que trafegam na rede e dar autenticidade aos domínios.

Vamos falar aqui sobre a mecânica para conseguir esses dois objetivos, começando pela autenticidade dos domínios.

Autenticidade dos Domínios

Para que o nosso site passe e ser considerado seguro pelo Browser, precisamos primeiramente ter uma identidade confirmada.

Identidade confirmada é sinônimo de Certificado Digital no mundo web, pois ninguém pode obter um certificado válido sem antes passar por um processo de validação de identidade, inserindo uma entrada exclusiva em seus registros DNS, pois somente o dono do domínio ou pessoas com acesso autorizado podem ter acesso a seus registros de DNS. A outra forma é validando a solicitação do certificado por email.

Existem entidades responsáveis por validar essa autenticidade dos domínios e emitir os certificados, as chamadas Autoridades Certificadoras.

Autoridades Certificadoras são empresas terceiras, publicamente confiáveis, que emitem certificados.

O navegador conhece essas autoridades e ao iniciar uma conexão com algum servidor que implementa essa camada de segurança, quando recebe o certificado, é capaz de validar se é um certificado emitido por uma entidade oficial e confiável.

Podemos visualizar a listagem dessas autoridades acessando as configurações do navegador e fazendo uma busca por certificados.

Acesso à gerência de certificados no Chrome.

E clicar em Gerenciar certificados.

Autoridades de Certificação Raiz Confiáveis e Intermediárias.

Existem as Autoridades de Certificação Raiz Confiáveis que são autônomas na emissão de certificados e as Autoridades de Certificação Intermediárias, que emitem certificados autoassinados pelas Autoridades de Certificação Raiz Confiáveis.

Acima das Autoridades Raiz existem outras que as certificam. E no topo da hierarquia, inclusive entidades governamentais de certificação.

Podemos ver isso, acessando o certificado do site através das ferramentas do Desenvolvedor.

Acessando as Ferramentas do Desenvolvedor no Chrome.

Na aba Security, clicando em View certificate.

Informações sobre o certificado ssl/tls de site específico na aba Security das Ferramentas do Desenvolvedor no Chrome.

No certificado propriamente dito, na aba Caminho de Certificação, vemos que, no nosso caso, a Amazon certificou a autenticidade do domínio devcontent.com.br. Mas existem autoridades que certificam a Amazon.

Visualização de certificado ssl/tls de site específico.

Com isso, é mais difícil um domínio se passar por outro.

O outro propósito – Criptografia

Além de garantir a identidade, essa camada de segurança também implementa criptografia. Utilizando para isso, pares de chave a fim de impedir que a informação trafegue em texto puro na rede.

Esse processo é feito em duas etapas. Primeiramente, utilizando-se criptografia assimétrica. Onde há um par de chaves, composto por uma chave privada e outra pública, sendo uma diferente da outra.

Porém, a criptografia assimétrica tem um problema, ela é lenta. É aí que, num segundo momento, entra a criptografia simétrica, composta por um par de chaves idênticas, as chamadas chaves de sessão.

Criptografia Simétrica e Assimétrica.

Então na prática, o processo funciona assim: quando um servidor que implementa essa camada de segurança recebe uma requisição de um cliente, ele responde enviando o certificado e a chave pública daquele par de chaves da criptografia assimétrica.

Servidor com camada de segurança SSL/TLS.

O cliente, como vimos acima, verifica se o certificado é válido. Estando tudo ok com o certificado, gera um novo par de chaves, as chaves de sessão.

Envio da chave pública e certificado ao cliente.

Na sequência, o cliente utiliza a chave pública, recebida previamente do servidor, para criptografar uma cópia das chaves de sessão. E faz o envio dessa cópia ao servidor.

Envio da chave de sessão ao servidor.

Se no meio do caminho, essa cópia for interceptada por alguém mal intencionado, e que tenha a chave pública, esse alguém não poderá decifrar a informação porque a chave pública só criptografa. A única capaz de decifrar a informação é a chave privada que está em posse do servidor e nunca é enviada a lugar nenhum.

Assim que o servidor decifra a cópia da chave de sessão que veio do cliente, ambos passam a utilizar cada um a sua cópia dessa chave de sessão para trocarem informações.

Então, como a criptografia assimétrica é lenta, ela é utilizada unicamente num primeiro momento para garantir que somente os entes envolvidos na comunicação tenham acesso, cada um à sua chave de sessão, que será utilizada a partir daí na comunicação entre as partes.

Redirecionar as solicitações HTTP para HTTPS

Nós já temos o certificado, pois tivemos que emiti-lo para que fosse possível customizar o domínio do nosso site. Vamos então ativar o uso do protocolo HTTPS.

Faremos isso editando a aba Behavior do CloudFront marcando a opção Redirect HTTP to HTTPS em Viewer Protocol Policy.

Escolher redirecionar solicitações http para https no CloudFront.

Não marcamos a opção HTTPS Only porque o usuário pode forçar o uso do protocolo sem a camada de segurança, especificando http:// antes do endereço, e não queremos que ele receba um erro de acesso negado ou algo do tipo ao fazer isso. Então, simplesmente ao receber esse tipo de acesso faremos o direcionamento para a versão segura.

Após a alteração, espere o Status da distribuição mudar de In Progress para Deployed o que pode demorar 10 minutos ou mais.

Mudança deployada! Vamos agora abrir uma nova janela anônima do navegador para garantir que não tenhamos dados cacheados e forçar o acesso via http a fim de ver se há o redirecionamento para a versão segura, digitando http://devcontent.tk

Ok. Garantimos que nosso site só será acessado via HTTPS e o problema de segurança está sanado.

Ir para o topo