Robert Heaton

HTTPS é simplesmente o seu protocolo HTTP standard com uma camada generosa de deliciosa bondade de encriptação SSL/TLS. A menos que algo corra terrivelmente mal (e pode), impede que pessoas como a infame Eva vejam ou modifiquem os pedidos que compõem sua experiência de navegação; é o que mantém suas senhas, comunicações e detalhes de cartão de crédito seguros no fio entre seu computador e os servidores para os quais você quer enviar esses dados. Embora o pequeno cadeado verde e as letras “https” na sua barra de endereço não signifiquem que ainda não haja uma corda ampla para que você e o site que você está vendo se enforquem em outro lugar, eles ajudam a se comunicar com segurança enquanto você o faz.

O que é HTTPS e o que ele faz?

HTTPS leva o conhecido e entendido protocolo HTTP, e simplesmente coloca uma camada de criptografia SSL/TLS (daqui em diante referida simplesmente como “SSL”) em cima dele. Servidores e clientes ainda falam exatamente o mesmo HTTP entre si, mas através de uma conexão SSL segura que criptografa e descriptografa seus pedidos e respostas. A camada SSL tem 2 propósitos principais:

• Verificando que você está falando diretamente com o servidor que você pensa que está falando
• Segurando que somente o servidor pode ler o que você envia e somente você pode ler o que ele envia de volta

A parte realmente, realmente inteligente é que qualquer um pode interceptar cada uma das mensagens que você troca com um servidor, incluindo aquelas em que você está concordando com a chave e a estratégia de criptografia para usar, e ainda não ser capaz de ler nenhum dos dados reais que você envia.

Como é estabelecida uma ligação SSL

Uma ligação SSL entre um cliente e um servidor é estabelecida através de um aperto de mão, cujos objectivos são:

• Para satisfazer o cliente que está a falar com o servidor certo (e opcionalmente vice-versa)
• Para que as partes tenham acordado num “pacote de cifras”, que inclui qual algoritmo de encriptação usarão para trocar dados
• Para que as partes tenham concordado em quaisquer chaves necessárias para este algoritmo

A partir do momento em que a conexão esteja estabelecida, ambas as partes podem usar o algoritmo e as chaves acordadas para enviar mensagens de forma segura uma à outra. Vamos dividir o aperto de mão em 3 fases principais – Olá, Troca de Certificado e Troca de Chaves.

1. Hello – O aperto de mão começa com o cliente a enviar uma mensagem ClientHello. Esta contém toda a informação que o servidor precisa para se conectar ao cliente via SSL, incluindo os vários conjuntos de cifras e a versão máxima SSL que ele suporta. O servidor responde com um ServerHello, que contém informações similares exigidas pelo cliente, incluindo uma decisão baseada nas preferências do cliente sobre qual suíte de cifras e versão do SSL será usada.

2. Certificate Exchange – Agora que o contato foi estabelecido, o servidor tem que provar sua identidade para o cliente. Isto é conseguido utilizando o seu certificado SSL, que é um pouco como o seu passaporte. Um certificado SSL contém vários dados, incluindo o nome do proprietário, a propriedade (ex. domínio) a que está anexado, a chave pública do certificado, a assinatura digital e informações sobre as datas de validade do certificado. O cliente verifica se confia implicitamente no certificado, ou se é verificado e confiado por uma das várias Autoridades Certificadoras (CAs) em que também confia implicitamente. Muito mais sobre isso em breve. Note que o servidor também pode requerer um certificado para provar a identidade do cliente, mas isso normalmente só acontece em aplicações muito sensíveis.

3. Key Exchange – A criptografia dos dados da mensagem real trocada pelo cliente e pelo servidor será feita usando um algoritmo simétrico, cuja natureza exata já foi acordada durante a fase de Olá. Um algoritmo simétrico usa uma única chave tanto para encriptação como para desencriptação, ao contrário dos algoritmos assimétricos que requerem um par de chaves públicas/privadas. Ambas as partes precisam concordar sobre esta chave única e simétrica, um processo que é realizado com segurança usando criptografia assimétrica e as chaves públicas/privadas do servidor.

O cliente gera uma chave aleatória para ser usada para o algoritmo principal e simétrico. Ele criptografa usando um algoritmo também acordado durante a fase de Olá, e a chave pública do servidor (encontrada em seu certificado SSL). Ele envia essa chave criptografada para o servidor, onde ela é descriptografada usando a chave privada do servidor, e as partes interessantes do aperto de mão estão completas. As partes estão suficientemente contentes por estarem a falar com a pessoa certa, e concordaram secretamente numa chave para encriptar simetricamente os dados que estão prestes a enviar um ao outro. Os pedidos e respostas HTTP podem agora ser enviados, formando uma mensagem em texto simples e depois encriptando-a e enviando-a. A outra parte é a única que sabe como decifrar esta mensagem, e assim os Ataqueiros do Meio são incapazes de ler ou modificar qualquer pedido que eles possam interceptar.

Certificados

No seu nível mais básico, um certificado SSL é simplesmente um arquivo texto, e qualquer um com um editor de texto pode criar um. Você pode, de fato, trivialmente, criar um certificado afirmando que você é Google Inc. e que você controla o domínio gmail.com. Se esta fosse a história toda então o SSL seria uma piada; a verificação de identidade seria essencialmente o cliente a perguntar ao servidor “você é Google?”, o servidor a responder “er, sim totalmente, aqui está um pedaço de papel com ‘eu sou Google’ escrito nele” e o cliente a dizer “OK óptimo, aqui estão todos os meus dados”. A magia que impede esta farsa está na assinatura digital, que permite a uma parte verificar que o pedaço de papel de outra parte é realmente legítimo.

Existem 2 razões sensatas para confiar num certificado:

• Se estiver numa lista de certificados em que confie implicitamente
• Se for capaz de provar que é confiado pelo controlador de um dos certificados da lista acima

O primeiro critério é fácil de verificar. Seu navegador tem uma lista pré-instalada de certificados SSL confiáveis das Autoridades Certificadoras (CAs), que você pode visualizar, adicionar e remover. Estes certificados são controlados por um grupo centralizado de (em teoria, e geralmente na prática) organizações extremamente seguras, confiáveis e confiáveis como a Symantec, Comodo e GoDaddy. Se um servidor apresenta um certificado dessa lista, então você sabe que pode confiar neles.

O segundo critério é muito mais difícil. É fácil para um servidor dizer “er yeah, meu nome é er, Microsoft, você confia na Symantec e er, eles confiam totalmente em mim, então é tudo legal”. Um cliente inteligente pode perguntar à Symantec: “Tenho aqui uma Microsoft que diz que confias neles, é verdade?” Mas mesmo que a Symantec diga “sim, nós conhecemo-los, a Microsoft é legítima”, ainda não sabes se o servidor que diz ser a Microsoft é mesmo a Microsoft ou algo muito pior. É aqui que entram as assinaturas digitais.

3.2 Assinaturas digitais

Como já foi notado, os certificados SSL têm um par de chaves público/privado associado. A chave pública é distribuída como parte do certificado, e a chave privada é guardada de forma incrivelmente segura. Este par de chaves assimétricas é utilizado no aperto de mão SSL para trocar uma outra chave para que ambas as partes encriptem e desencriptem simetricamente os dados. O cliente usa a chave pública do servidor para encriptar a chave simétrica e enviá-la com segurança para o servidor, e o servidor usa a sua chave privada para a desencriptar. Qualquer pessoa pode criptografar usando a chave pública, mas apenas o servidor pode decifrar usando a chave privada.

O oposto é verdadeiro para uma assinatura digital. Um certificado pode ser “assinado” por uma outra autoridade, onde a autoridade efetivamente registra como dizendo “nós verificamos que o controlador deste certificado também controla a propriedade (domínio) listada no certificado”. Neste caso, a autoridade utiliza a sua chave privada para (em termos gerais) encriptar o conteúdo do certificado, e este texto cifrado é anexado ao certificado como a sua assinatura digital. Qualquer pessoa pode desencriptar esta assinatura utilizando a chave pública da autoridade, e verificar que resulta no valor desencriptado esperado. Mas apenas a autoridade pode criptografar o conteúdo usando a chave privada, e assim apenas a autoridade pode realmente criar uma assinatura válida em primeiro lugar.

Então, se um servidor aparece alegando ter um certificado para Microsoft.com que é assinado pela Symantec (ou alguma outra CA), o seu navegador não tem que levar a sua palavra para ele. Se for legítimo, a Symantec terá usado sua chave privada (ultra-secreta) para gerar a assinatura digital do certificado SSL do servidor, e assim seu navegador pode usar sua chave pública (ultra-pública) para verificar se essa assinatura é válida. A Symantec terá tomado medidas para garantir que a organização para a qual está assinando realmente possui Microsoft.com, e assim, dado que seu cliente confia na Symantec, pode ter certeza que está realmente falando com Microsoft Inc.

3.3 Auto-sinalização

Note que todos os certificados CA raiz são “auto-sinalizados”, significando que a assinatura digital é gerada usando a própria chave privada do certificado. Não há nada intrinsecamente especial no certificado da CA raiz – você pode gerar seu próprio certificado autoassinado e usá-lo para assinar outros certificados, se quiser. Mas como o seu certificado aleatório não é pré-carregado como uma CA em nenhum navegador, nenhum deles confiará em você para assinar o seu próprio certificado ou outros certificados. Você está efetivamente dizendo “er yeah, eu sou totalmente Microsoft, aqui está um certificado oficial de identidade emitido e assinado por mim”, e todos os navegadores que funcionam corretamente vão vomitar uma mensagem de erro muito assustadora em resposta às suas duvidosas credenciais.

Isso coloca uma enorme carga sobre todos os navegadores e editores de SO para confiar apenas em CA de raiz limpa, pois estas são as organizações em que seus usuários acabam confiando para vetar sites e manter os certificados seguros. Esta não é uma tarefa fácil.

3.4 Em que você está confiando?

É interessante notar que seu cliente não está tecnicamente tentando verificar se deve ou não confiar na parte que lhe enviou um certificado, mas se deve confiar na chave pública contida no certificado. Os certificados SSL são completamente abertos e públicos, portanto qualquer atacante poderia pegar o certificado da Microsoft, interceptar o pedido de um cliente para Microsoft.com e apresentar o certificado legítimo para ele. O cliente aceitaria isto e começaria de bom grado o aperto de mão. Entretanto, quando o cliente criptografa a chave que será usada para a criptografia de dados real, ele o faz usando a chave pública real da Microsoft a partir deste certificado real. Como o atacante não tem a chave privada da Microsoft para decifrá-la, eles agora estão presos. Mesmo que o aperto de mão seja concluído, eles ainda não serão capazes de descriptografar a chave e, portanto, não serão capazes de descriptografar nenhum dos dados que o cliente envia para eles. A ordem é mantida enquanto o atacante não controlar a chave privada de um certificado de confiança. Se o cliente é de alguma forma enganado para confiar num certificado e numa chave pública cuja chave privada é controlada por um atacante, os problemas começam.

4.1 Um café pode monitorizar o tráfego do meu HTTPS através da sua rede?

Nope. A magia da criptografia de chave pública significa que um atacante pode observar cada byte de dados trocados entre o seu cliente e o servidor e ainda não tem idéia do que estão dizendo um ao outro além da quantidade de dados que estão trocando. No entanto, seu tráfego HTTP normal ainda é muito vulnerável em uma rede wi-fi insegura, e um site frágil pode ser vítima de qualquer número de soluções que, de alguma forma, enganam você para enviar tráfego HTTPS sobre HTTP simples ou apenas para o lugar errado completamente. Por exemplo, mesmo que um formulário de login envie um combo nome de usuário/senha sobre HTTPS, se o próprio formulário for carregado inseguro sobre HTTP então um atacante poderia interceptar o HTML do formulário a caminho de sua máquina e modificá-lo para enviar os detalhes de login para seu próprio endpoint.

4.2 Minha empresa pode monitorar meu tráfego HTTPS através de sua rede?

Se você também estiver usando uma máquina controlada por sua empresa, então sim. Lembre-se que na raiz de cada cadeia de confiança está uma CA de confiança implícita, e que uma lista dessas autoridades é armazenada no seu navegador. Sua empresa poderia usar o acesso deles à sua máquina para adicionar seu próprio certificado autoassinado a esta lista de ACs. Eles poderiam então interceptar todos os seus pedidos HTTPS, apresentando certificados que afirmam representar o site apropriado, assinados pela sua AC falsa e, portanto, inquestionavelmente confiáveis pelo seu navegador. Uma vez que estaria a encriptar todos os seus pedidos HTTPS utilizando a chave pública do seu certificado duvidoso, eles poderiam utilizar a chave privada correspondente para desencriptar e inspeccionar (ou mesmo modificar) o seu pedido, e depois enviá-lo para a sua localização pretendida. Provavelmente não o fazem. Mas eles poderiam.

Incidentalmente, esta é também a forma como você usa um proxy para inspecionar e modificar os pedidos HTTPS inacessíveis feitos por um aplicativo do iPhone.

4.3 Então o que aconteceu com Lavabit e o FBI?

Lavabit foi o provedor de e-mail super seguro de Edward Snowden durante a insanidade dos vazamentos de NSA de 2013. Como vimos, nenhuma quantidade de hackery padrão poderia permitir ao FBI ver quaisquer dados no seu caminho entre a Lavabit e os seus clientes. Sem a chave privada para o certificado SSL da Lavabit, a agência estava ferrada. No entanto, um útil juiz americano disse ao fundador da Lavabit, Ladar Levison, que ele tinha que entregar essa chave, dando efetivamente ao FBI um reinado livre para bisbilhotar o tráfego de acordo com o seu conteúdo. Levison fez uma tentativa corajosa de empatar entregando a chave de 2.560 caracteres em 11 páginas impressas do tipo 4 pontos, mas foi golpeado com uma ordem que o obrigava a entregar a chave num formato útil ou enfrentar uma multa de $5.000/dia até que o fizesse.

Após ter cumprido, GoDaddy, o Lavabit CA, revogou o certificado, tendo (correctamente) considerado comprometido. Isto adicionou o certificado Lavabit a uma Lista de Revogação de Certificado (CRL), uma lista de certificados desacreditados em que os clientes não devem mais confiar para fornecer uma conexão segura. Certificados comprometidos, autoassinados ou não confiáveis fazem com que os navegadores exibam uma grande mensagem de erro vermelha e desencorajem ou proíbam totalmente outras ações por parte do usuário. Infelizmente, os navegadores continuarão a confiar em um certificado quebrado até que eles puxem as mais novas atualizações do CRL, um processo que aparentemente é imperfeito na prática.

Conclusion

HTTPS não é inquebrável, e o protocolo SSL tem que evoluir constantemente à medida que novos ataques contra ele são descobertos e esmagados. Mas ainda é uma forma impressionantemente robusta de transmitir dados secretos sem se importar com quem vê suas mensagens. Claro que há muitos detalhes de implementação não mencionados aqui, tais como o formato exato e a ordem das mensagens de aperto de mão, apertos de mão abreviados para pegar as sessões recentes sem ter que renegociar chaves e suítes de cifras, e as inúmeras opções de criptografia diferentes disponíveis em cada estágio. O importante a lembrar é que embora o HTTPS mantenha os dados seguros no fio até o seu destino, ele não protege você (como usuário ou desenvolvedor) contra vazamentos de XSS ou banco de dados ou qualquer outra coisa – que não seja “ir contra a noite”. Fique feliz que ele o protege, mas fique atento. Nas imortais palavras de Will Smith, “Ande na sombra, mova-se em silêncio, proteja-se contra a violência extra-terrestre”

Se você gostou disso, provavelmente gostará do meu post explicando os detalhes da vulnerabilidade FREAK de 2015 em SSL.