A Web Segura com HTTPS

Já estamos acessando nosso site pelo domínio que configuramos nas aulas passadas. Mas temos ainda uma questão de segurança para tratar.

O próprio navegador alerta informando ao usuário que o site não é seguro. Isso se dá pelo fato de não termos ainda adicionado a camada de segurança ao protocolo HTTP.

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 tal maneira que o leitor tem liberdade de escolher entre vários caminhos. E cada caminho provoca a exibição de um novo hipertexto com informações relativas ao referido elemento.

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 de 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.

Imagine que você vai fazer o login para acessar seu facebook. Vou simular isso aqui colocando uma informação qualquer nos campos login e senha. Em paralelo, vou abrir as ferramentas de desenvolvedor, pressionando F12 no teclado, para ver as requisições sendo feitas ao servidor.

Simular cenário de envio de dados por um site.

Aquelas informações constantes nos campos email e pass na seção Form Data são exatamente as que digitei como sendo meu usuário e senha para fazer o login no facebook.

No caso do facebook que usa o protocolo HTTPS, e praticamente todos os sites na internet, essas informações serão criptografadas antes de serem enviadas ao servidor.

Porém, o nosso site ainda está usando HTTP e dessa forma essas credenciais seriam trafegadas em texto puro na internet. Num cenário assim, se alguém interceptar a comunicação, poderá ver as informações.

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 esse processo de legitimação, inserindo aquela entrada exclusiva em seus registros DNS que fizemos na etapa passada ou validando a solicitação do certificado por email.

Conforme mencionamos brevemente na etapa passada, existem entidades responsáveis por validar essa autenticidade dos domínios e emitir os certificados, as chamadas Autoridades Certificadoras.

O navegador conhece essas autoridades e ao iniciar uma conexão com algum site, 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.

Podemos também visualizar informações e certificado de um site específico. Vamos voltar para nossa janela onde está a página de login do facebook e acessar novamente as ferramentas de desenvolvedor.

Acessando as Ferramentas do Desenvolvedor no Chrome.

Na aba Security constam as informações sobre o certificado

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

Podemos inclusive ver o certificado clicando em View certificate.

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

Criptografia, o segundo propósito

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

No processo de comunicação via HTTPS, ao estabelecer conexão, o servidor envia ao cliente o certificado e uma chave pública que será usada pelo cliente para encriptar as informações que serão enviadas ao servidor. Essas informações, uma vez criptografadas, só poderão ser decifradas pela chave privada que é diferente da pública e jamais saiu do servidor. Portanto, ninguém teve acesso a ela.

Porém, logo que o cliente recebe o certificado e a chave pública vindas do servidor e verifica que se trata de um certificado válido, ele cria outro par de chaves. Mas desta vez elas são idênticas. Na sequência, utiliza a chave pública que recebeu do servidor, para encriptar uma cópia dessa chave e enviar para o servidor que vai decifrá-la usando sua chave privada. Após esse momento a conexão está estabelecida e nenhuma chave mais trafega pela rede.

Redirecionar as solicitações HTTP para HTTPS

Uma vez que já temos o certificado, pois foi emitido na aula passada, vamos ativar o uso do protocolo HTTPS acessando o CloudFront.

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. Então simplesmente ao receber esse tipo de acesso faremos o direcionamento para a versão segura.

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.

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