TLS handshake

Uma conexão segura é estabelecida através de um proxy por meio do TLS handshake, no qual o cliente e o servidor final (a origem ou o próprio proxy, dependendo da configuração) autenticam identidades e negociam parâmetros criptográficos para criar um canal de comunicação criptografado. Esse processo garante confidencialidade, integridade e autenticidade dos dados para aplicações que se comunicam através de redes.

Entendendo o TLS handshake

O protocolo Transport Layer Security (TLS) é fundamental para proteger as comunicações na internet. Ele opera acima da camada de transporte (TCP) e fornece criptografia e autenticação ponta a ponta. O TLS handshake é a fase inicial de negociação, na qual cliente e servidor concordam sobre os parâmetros criptográficos e estabelecem uma sessão segura antes da troca de dados de aplicação.

Os principais objetivos do TLS handshake são:
* Autenticação: verificar a identidade do servidor (e, opcionalmente, do cliente) por meio de certificados digitais.
* Troca de chaves: acordar com segurança uma chave secreta compartilhada para criptografia simétrica.
* Negociação de cipher suite: selecionar os algoritmos de criptografia, hashing e troca de chaves.

Etapas do TLS handshake direto

Em uma conexão direta, sem proxy, o TLS handshake ocorre assim:

1. Client Hello: o cliente inicia o handshake enviando uma mensagem Client Hello. Essa mensagem inclui:
   • Versões de TLS suportadas.
   • Uma lista de cipher suites suportadas.
   • Uma sequência aleatória de bytes (Client Random).
   • Métodos de compressão suportados.
   • Server Name Indication (SNI) para hospedagem virtual.
2. Server Hello: o servidor responde com uma mensagem Server Hello, selecionando:
   • A versão de TLS a ser usada.
   • Uma cipher suite escolhida da lista do cliente.
   • Uma sequência aleatória de bytes (Server Random).
3. Certificate: o servidor envia seu certificado digital, que contém sua chave pública e é assinado por uma Autoridade Certificadora (CA). O cliente verifica esse certificado.
4. Server Key Exchange (opcional): se a cipher suite escolhida exigir (por exemplo, para Diffie-Hellman efêmero), o servidor envia parâmetros para a troca de chaves.
5. Server Hello Done: o servidor indica que concluiu sua parte do handshake inicial.
6. Client Key Exchange: o cliente gera um pre-master secret, criptografa-o com a chave pública do servidor (obtida do certificado) e o envia ao servidor.
7. Change Cipher Spec (cliente): o cliente envia uma mensagem Change Cipher Spec, indicando que todas as mensagens seguintes serão criptografadas com as chaves e a cipher suite negociadas.
8. Encrypted Handshake Message (cliente): o cliente envia uma mensagem Finished, criptografada com a chave simétrica recém-estabelecida, para verificar a integridade do handshake.
9. Change Cipher Spec (servidor): o servidor envia sua própria mensagem Change Cipher Spec.
10. Encrypted Handshake Message (servidor): o servidor envia sua mensagem Finished, também criptografada.
11. Application Data: ambas as partes já podem trocar dados de aplicação criptografados.

Tipos de proxy e interação com o TLS handshake

Os proxies alteram a forma como o TLS handshake é iniciado e processado, conforme seu modo de operação.

Forward proxy (sem interceptação)

Um forward proxy atua como intermediário para clientes que buscam acessar recursos externos. Para tráfego HTTPS, um forward proxy sem interceptação normalmente funciona como um túnel TCP. O cliente se configura explicitamente para usar o proxy.

Mecanismo:
O cliente envia uma requisição HTTP CONNECT ao proxy para estabelecer um túnel TCP até o servidor de origem. Uma vez estabelecido o túnel, cliente e servidor de origem realizam o TLS handshake diretamente através desse túnel. O proxy encaminha os bytes criptografados sem descriptografá-los.

Fluxo do TLS handshake:
1. Cliente para proxy (TCP): o cliente estabelece uma conexão TCP com o proxy.
2. Requisição CONNECT do cliente: o cliente envia uma requisição HTTP CONNECT ao proxy, especificando o hostname e a porta do servidor de origem (por exemplo, CONNECT example.com:443 HTTP/1.1).
3. Proxy para origem (TCP): o proxy estabelece uma conexão TCP com o servidor de origem especificado.
4. 200 OK do proxy: se a conexão com o servidor de origem for bem-sucedida, o proxy responde ao cliente com HTTP/1.1 200 Connection established.
5. Cliente para origem (TLS via túnel): ao receber o 200 OK, o cliente inicia o TLS handshake padrão diretamente com o servidor de origem através do túnel TCP estabelecido.
6. Encaminhamento pelo proxy: o proxy encaminha de forma transparente todos os bytes criptografados subsequentes entre cliente e servidor de origem. Ele não participa do TLS handshake nem descriptografa o tráfego.

Exemplo de código: requisição CONNECT do cliente

CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443
Proxy-Connection: Keep-Alive

Resposta do proxy

HTTP/1.1 200 Connection established

Reverse proxy (terminação TLS)

Um reverse proxy fica à frente de um ou mais servidores de origem e intercepta as requisições dos clientes destinadas a esses servidores. Para tráfego HTTPS, um reverse proxy frequentemente realiza a terminação TLS.

Mecanismo:
O reverse proxy recebe a requisição HTTPS do cliente, encerra a conexão TLS, descriptografa o tráfego e então estabelece uma nova conexão (que pode ou não ser criptografada com TLS) com o servidor de origem no backend.

Fluxo do TLS handshake:
1. Cliente para reverse proxy (TLS handshake 1):
* O cliente realiza um TLS handshake padrão diretamente com o reverse proxy.
* O reverse proxy apresenta seu próprio certificado digital ao cliente.
* É estabelecido um canal seguro e criptografado entre o cliente e o reverse proxy.
2. Descriptografia no reverse proxy: o reverse proxy descriptografa a requisição do cliente.
3. Reverse proxy para origem (TLS handshake 2 ou HTTP):
* O reverse proxy então inicia uma nova conexão com o servidor de origem apropriado no backend.
* Essa conexão pode ser HTTP puro (comum em redes internas confiáveis) ou outra conexão criptografada com TLS (para criptografia ponta a ponta).
* Se TLS for usado, o reverse proxy atua como cliente e realiza um segundo TLS handshake com o servidor de origem, que apresenta o próprio certificado.
4. Processamento na origem: o servidor de origem processa a requisição e envia a resposta de volta ao reverse proxy.
5. Criptografia no reverse proxy: se a conexão com o cliente era TLS, o reverse proxy recriptografa a resposta usando as chaves da sessão TLS voltada ao cliente.
6. Reverse proxy para cliente: a resposta criptografada é enviada de volta ao cliente.

Proxy transparente (interceptação TLS MITM)

Um proxy transparente intercepta o tráfego sem que o cliente esteja explicitamente configurado para usá-lo. Para HTTPS, isso normalmente envolve uma abordagem Man-in-the-Middle (MITM).

Mecanismo:
Quando um cliente tenta se conectar a um site HTTPS, o proxy transparente intercepta a conexão. Ele gera um certificado falso para o domínio solicitado, assinado pela sua própria CA raiz. O cliente realiza um TLS handshake com o proxy, que então realiza outro TLS handshake com o servidor de origem. Isso permite ao proxy descriptografar, inspecionar e potencialmente modificar o tráfego. Para funcionar sem erros de certificado, o certificado da CA raiz do proxy precisa ser confiável para o cliente. Isso é comum em ambientes corporativos, para monitoramento de segurança.

Comparação dos tipos de proxy e da interação com TLS

Considerações de segurança

Ao estabelecer conexões seguras através de um proxy, surgem várias implicações de segurança:

• Confiança no proxy:
  • Forward proxy: como o proxy apenas tunela dados criptografados, os requisitos de confiança quanto à confidencialidade dos dados são mínimos. No entanto, o proxy pode registrar metadados da conexão (IPs, domínios).
  • Reverse proxy / proxy transparente (MITM): esses proxies descriptografam o tráfego. A confiança no operador do proxy torna-se essencial, pois ele tem acesso a dados sensíveis descriptografados. No caso de proxies MITM transparentes, o cliente precisa confiar explicitamente na CA raiz do proxy, normalmente instalando-a no repositório de confiança do sistema.
• Certificate pinning: aplicações que usam certificate pinning podem falhar ao se conectar através de um reverse proxy ou de um proxy MITM transparente, pois o proxy apresenta um certificado diferente do esperado do servidor de origem. Trata-se de um recurso de segurança projetado para impedir ataques MITM.
• Imposição de versão de TLS e cipher suite: os proxies podem ser configurados para impor versões de TLS e cipher suites específicas, aumentando a segurança ao proibir protocolos criptográficos obsoletos ou fracos, mesmo que o cliente ou o servidor de origem os suportem.
• Registro e auditoria: proxies, especialmente dos tipos reverso e transparente, podem oferecer amplos recursos de log do tráfego descriptografado, auxiliando em auditorias de segurança e na resposta a incidentes.
• Sobrecarga de desempenho: a terminação TLS em um proxy introduz sobrecarga computacional de criptografia e descriptografia, o que precisa ser considerado em ambientes de alto tráfego. A aceleração por hardware (por exemplo, SSL offloading) é comumente usada para mitigar isso.