Revista /dev/All

Quando penso em HTTPS e desenvolvedores web me vêm à mente uma citação de Santo Agostinho sobre o tempo:

Sei o que é o tempo, mas quando me perguntam o que de fato este é, percebo que não sei do que se trata.

Santo Agostinho

Com HTTPS é a mesma coisa: sabemos que aumenta a segurança da web, mas como alguém que desenvolve aplicações web, você realmente sabe por que isto é verdade? Este post (que talvez inicie uma série) tem como objetivo dar uma visão geral a respeito do funcionamento deste protocolo.

Este primeiro post apresenta uma visão mais geral dos conceitos envolvidos: meu objetivo é, com o tempo, ir apresentando os detalhes referentes a todos os atores envolvidos no projeto.

Aviso: este é um texto escrito por um desenvolvedor para outros desenvolvedores. Não sou um especialista em segurança: caso sejam encontrados erros no texto, por favor, me avise nos comentários para que eu possa aplicar as devidas correções, ok?

O que é necessário

Naturalmente, o requisito obrigatório para que o HTTPS possa ser executado consiste na configuração do seu servidor web (você aprende a fazer isto no Apache de forma gratuita neste link). 

E o certificado

Para tal, é obrigatória a presença de um certificado digital. No caso de aplicações web estes podem variar, entretanto o mais comum é o DV (Domain Validation), que tem como objetivo essencialmente dizer quem de fato é o dono daquele domínio e responsável pelo mesmo.

(dado que qualquer um pode gerar um certificado digital para qualquer domínio, esta não é uma garantia real de autenticidade, podemos falar mais a respeito de outras alternativas ao DV no futuro).

Criptografia simétrica e assimétrica

O certificado digital possui em si o que chamamos de assinatura digital, ou seja, um conjunto de bytes que o identifica unicamente. E também possui o essencial para que possamos ter um par de chaves para aplicarmos a criptografia assimétrica sobre as mensagens trafegadas. Hein? Criptografia assimétrica? O que é isto?

Ao falarmos de criptografia precisamos mencionar três atores:

• A mensagem original.
• A chave (senha) usada para codifica-la e decodifica-la.
• A mensagem codificada.

Quando dizemos que uma criptografia é simétrica, a mesma chave (senha) é usada tanto para encriptar uma senha quanto para decripta-la. Já quando falamos em criptografia assimétrica, uma senha é usada para codificar a mensagem (a pública) e outra para decodifica-la (a privada). 

Em mecanismos de criptografia assimétrica algo interessante ocorre: existe uma chave que chamamos de pública, e é a responsável por encriptar os dados. Esta, como o próprio nome já diz, é pública, todos tem acesso a mesma.

Do outro lado há a chave privada, que jamais deverá ser compartilhada, e que fica no seu servidor. Seu papel consiste em receber conteúdo criptografado e, na sequência, decodifica-lo (mesmo por que não faz muito sentido em aplicações web o envio de mensagens que jamais serão decodificadas).

Resumindo: o certificado digital contém um par de chaves público/privada e também uma assinatura que serve para garantir a autenticidade de um domínio ou entidade, isto é, que aquele domínio realmente é quem diz ser. Mas… quem garante a autenticidade do certificado?

A autoridade certificadora entra em cena

Agora você vai entender por que certificados digitais são tão caros e também começar a valorizar horrores a iniciativa Let’s Encrypt.

Um certificado recebe uma assinatura que o identifica unicamente. A questão é: quem o assina? É o que chamamos de autoridade certificadora, ou seja, uma empresa, externa ao dono do certificado, que diz essencialmente: “eu, entidade certificadora, digo que este certificado é válido e você realmente é quem diz ser”. Pense em um “cartório digital”.

Mas mais do que isto: quem garante que a entidade certificadora realmente é uma autoridade certificadora? Outra autoridade certificadora. E esta? Outra… E assim segue até chegarmos na Autoridade Certificadora raíz, que é aquela que essencialmente “se auto assina” ou, melhor dizendo, é a entidade certificadora que possui um “certificado raíz”.

Sim, o certificado digital é assinado por outro certificado digital. E o número de certificados raízes existente é limitado e são bastante caros. No Brasil a principal entidade é o ICP, que possuí seu certificado raíz. 

(neste momento você deve estar pensando em se tornar uma autoridade certificadora raíz, certo? Legal saber que você tem mais de 2 milhões de reais em banco e vai passar por um processo de certificação BEM pesado!)

A autoridade certificadora faz parte do que chamamos de infraestrutura de chaves públicas (Public Key Infrastructure – PKI), o que é assunto, em si só, para um outro post.

Sendo assim, até este ponto, no certificado digital, já temos algumas garantias de segurança:

• O certificado é assinado, o que garante sua unicidade.
• Provê uma chave pública e outra privada.
• E existe uma autoridade certificadora que diz ser este um certificado válido.
  

Mas você também pode ter um certificado digital auto assinado. Ele é um certificado válido, mas mais ou menos válido. 🙂 Por que? Por que não existe a autoridade certificadora.

O aperto de mão

Agora que você tem uma ideia por trás do que vêm a ser o certificado digital (o que ele provê), chegou o momento de compreender como a segurança é estabelecida entre seu navegador e o servidor.

O HTTPS tem como base o protocolo TLS (também chamado de SSL). Essencialmente o que temos é conteúdo HTTP sendo trafegado por este protocolo, que será o responsável pela criptografia dos dados.

O protocolo executa uma série de passos (como uma dança), mas o inicial e mais importante é o que chamamos de handshake, no qual o navegador se apresenta ao servidor e vice-versa.

Neste momento o navegador informa ao servidor quais os protocolos de segurança que conhece e o servidor lhe responde de volta se pode ou não atendê-lo com base no que tem.

Mas não apenas isto: no momento do handshake servidor e cliente também criam uma nova senha para que possa ser realizada a criptografia simétrica. Mas hein???

Isto mesmo, criptografia simétrica. Mas por que isto se já temos a criptografia assimétrica provida pelo par de chaves do certificado? Por que não criptografamos o conteúdo usando estas chaves? A razão é triste meus amigos. A criptografia assimétrica se baseia no algoritmo RSA,  e este tem uma pequena limitação: o tamanho máximo da mensagem que ele pode encriptar é de (n / 8) – 11 bytes. Aonde n representa o número de bits que formam a minha chave pública ou privada.

Sendo assim, se tenho uma chave de 1024 bits, o tamanho máximo da mensagem que posso encriptar é de 117 bytes. E quanto maior o tamanho da chave, maior o tempo necessária para que ela seja gerada (aumenta exponencialmente). É por isto que você não tem chaves por aí de 1 Mb de tamanho.

A solução então é criar uma senha temporária, que é acordada entre as duas partes (cliente e servidor), e que será encriptada pela chave pública no cliente, e decriptada pelo lado servidor pela chave privada. Temos então aí a primeira codificação.

A segunda codificação é o corpo da mensagem a ser trafegada. Neste caso, lembra que no momento do handshake o cliente fala quais os algoritmos de criptografia que conhece? Servidor e cliente escolhem um destes algoritmos e a partir deste momento o corpo da mensagem será encriptado usando esta senha temporária.

A senha temporária faz parte, em si, de uma sessão estabelecida entre cliente e servidor que possui um tempo de vida fixo. Quando a sessão expira um novo handshake é executado e outra sessão é iniciada novamente.

Resumindo então:

• No handshake o cliente obtém a chave pública do servidor e criamos uma sessão, na qual está definida uma senha usada para encriptar o conteúdo das mensagens a serem trafegadas.
• A senha temporária é encriptada usando-se a chave pública fornecida pelo servidor.
• Após o handshake, enquanto a sessão for válida, o cliente irá codificar o conteúdo da mensagem a ser transmitida com a senha temporária e, na sequência, enviará este conteúdo criptografado para o servidor.
• O servidor identifica a sessão e, na sequência, usando a senha temporária, decodifica o conteúdo da mensagem, que será em seguida processada pela aplicação.

Não sei se reparou, mas além de resolver o problema da criptografia de conteúdo de tamanho variável, a senha temporária tem outra função: dado que todos tem acesso á chave pública, é ela que define que aquele cliente específico está se comunicando com o servidor.

Sendo assim, se alguém interceptar a mensagem durante a transmissão, por não ter conhecimento a respeito da senha temporária, este vilão não terá (em teoria) como decodificar a mensagem.

E agora você sabe, a grosso modo, como o HTTPS funciona e garante (em teoria) a sua privacidade e segurança na Internet.

Concluindo

Este é o primeiro post que escrevo sobre este tópico. Surgiu da minha própria ignorância a respeito do assunto, o que motivou o início da minha pesquisa sobre o mesmo, especialmente por que não há muita documentação a este respeito, de qualidade, na internet.

Caso tenha encontrado algum erro, por favor, comente comigo nos comentários para que as devidas correções sejam realizadas. O objetivo é expor aos desenvolvedores os conhecimentos básicos para que estes tópicos sejam melhor divulgados.

Para finalizar, cito aqui o melhor livro que encontrei sobre o assunto: Bulletproof SSL and TLS, publicado pela editora Feisty Duck. Uma referência completa sobre o assunto.