Dominando TLS em Profundidade: Handshake, Cipher Suites, mTLS e TLS 1.3 em Projetos Reais Já leu

TLS em Profundidade: Entendendo a Segurança de Comunicação na Era Moderna

TLS (Transport Layer Security) é o protocolo fundamental que protege praticamente toda comunicação sensível na internet moderna. Se você acessa um site, faz uma transação bancária ou usa uma API, está dentro de um túnel TLS. Porém, muitos desenvolvedores usam TLS sem realmente compreender o que acontece nos bastidores. Este artigo é para mudar isso. Vamos explorar o handshake, cipher suites, autenticação mútua (mTLS) e as inovações do TLS 1.3 com exemplos práticos e funcionais.

O Handshake TLS: Como Dois Computadores Estabelecem Confiança

O handshake TLS é o processo inicial onde cliente e servidor estabelecem uma conexão segura. Ele acontece antes de qualquer dado aplicativo ser enviado e é responsável por autenticar o servidor (e opcionalmente o cliente), negociar algoritmos criptográficos e gerar chaves de sessão compartilhadas.

A Sequência do Handshake TLS 1.2

No TLS 1.2 clássico, o handshake segue esta sequência:

1. ClientHello — O cliente envia uma mensagem contendo: versão TLS suportada, lista de cipher suites aceitas, números aleatórios (para futura derivação de chaves) e extensões.
2. ServerHello — O servidor responde com: a versão TLS escolhida, a cipher suite selecionada, seu número aleatório e certificado digital.
3. Certificate — O servidor envia seu certificado X.509, contendo sua chave pública e identidade verificada por uma CA.
4. ServerKeyExchange — O servidor envia parâmetros para o acordo de chave (como parâmetros Diffie-Hellman). Em ECDHE, isso é feito aqui.
5. ServerHelloDone — Marca o fim das mensagens do servidor nesta fase.
6. ClientKeyExchange — O cliente envia sua parte do acordo de chave.
7. ChangeCipherSpec — Ambos sinalizem que passarão a usar o cifrador acordado.
8. Finished — Ambos enviam um MAC (Message Authentication Code) para verificar que o handshake não foi alterado.

O tempo total deste processo é crítico em aplicações real-time. Um handshake TLS 1.2 completo pode levar 100-300ms dependendo da latência de rede.

Exemplo Prático: Observando um Handshake com OpenSSL

openssl s_client -connect www.google.com:443 -showcerts 2>&1 | head -50

Este comando conecta ao Google e exibe cada etapa do handshake. Você verá:

CONNECTED(00000003)
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services LLC, CN = Google Internet Authority G3
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com
verify return:1
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com
   i:C = US, O = Google Trust Services LLC, CN = Google Internet Authority G3
...
---
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

Note que o Google atual usa TLS 1.3. Vamos entender por quê.

O Problema do Latência no Handshake TLS 1.2

No TLS 1.2, o cliente deve esperar completar o handshake antes de enviar dados da aplicação. Se você está em uma conexão com 100ms de latência, o handshake completo leva 2 round-trips = ~200ms apenas para começar a conversa. Isso afeta diretamente a velocidade de carregamento de páginas web.

Além disso, no TLS 1.2, a chave do servidor é pré-assinada, o que significa que se a chave privada vazar, todos os dados históricos podem ser descriptografados — falta Perfect Forward Secrecy sem ECDHE.

Cipher Suites: O Coração do Acordo Criptográfico

Uma cipher suite é um conjunto de algoritmos que trabalham juntos para proteger a comunicação. Ela define:

• Algoritmo de acordo de chave (como ECDHE — Elliptic Curve Diffie-Hellman)
• Cifrador simétrico (como AES-256-GCM)
• Algoritmo de hash (como SHA-256 ou SHA-384)

Anatomia de uma Cipher Suite

Vamos dissecar a suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:

Por Que Alguns Algoritmos São Descontinuados

Algoritmos como MD5, SHA-1, DES e RSA com chaves < 2048 bits foram removidos porque:

1. MD5 e SHA-1 — Colisões foram encontradas; não são mais seguros.
2. DES — Chave de apenas 56 bits; quebrável em horas com hardware moderno.
3. RSA com chaves pequenas — Fatoração via ataques de tempo e força bruta tornou-se viável.

Negoção de Cipher Suite na Prática

import ssl
import socket

# Criar um contexto SSL com suites específicas
context = ssl.create_default_context()

# Exibir suites suportadas
print("Cipher suites suportadas:")
for suite in context.get_ciphers():
    print(f"  {suite['name']}")

# Conectar ao servidor
with socket.create_connection(("www.google.com", 443)) as sock:
    with context.wrap_socket(sock, server_hostname="www.google.com") as ssock:
        print(f"\nCipher suite negociada: {ssock.cipher()[0]}")
        print(f"Protocolo: {ssock.version()}")
        cert = ssock.getpeercert()
        print(f"Certificado do servidor: {cert['subject']}")

Saída esperada (em TLS 1.3):

Cipher suites suportadas:
  TLS_AES_256_GCM_SHA384
  TLS_CHACHA20_POLY1305_SHA256
  TLS_AES_128_GCM_SHA256
  ...

Cipher suite negociada: TLS_AES_256_GCM_SHA384
Protocolo: TLSv1.3
Certificado do servidor: ((('commonName', 'www.google.com'),),)

Escolha Estratégica de Cipher Suites

Para um servidor moderno, recomenda-se suportar:

# TLS 1.3 (principal)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# TLS 1.2 (compatibilidade)
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384

Nunca suporte cipher suites com nomes contendo "NULL", "EXPORT", "RC4", "MD5" ou "DES".

mTLS: Autenticação Mútua com Certificados

Até agora, apenas o servidor é autenticado (você verifica que é realmente Google). mTLS (mutual TLS) vai além: o cliente também se autentica com um certificado. Isso é fundamental em arquiteturas de microsserviços e comunicação máquina-para-máquina.

Diferença entre TLS Padrão e mTLS

No TLS tradicional (one-way):
- Servidor apresenta certificado
- Cliente verifica a identidade do servidor
- Qualquer cliente pode conectar (autenticação é opcional)

No mTLS (two-way):
- Servidor apresenta certificado; cliente verifica
- Cliente apresenta certificado; servidor verifica
- Apenas clientes com certificados válidos conseguem conectar

Isso é especialmente útil em APIs internas, comunicação entre microsserviços, VPNs e IoT.

Implementação de mTLS com Python e Flask

Primeiro, precisamos gerar certificados auto-assinados para teste:

# Gerar chave privada da CA
openssl genrsa -out ca-key.pem 2048

# Gerar certificado da CA
openssl req -new -x509 -days 365 -key ca-key.pem -out ca-cert.pem \
  -subj "/CN=MyCA"

# Gerar chave privada do servidor
openssl genrsa -out server-key.pem 2048

# Criar CSR (Certificate Signing Request) do servidor
openssl req -new -key server-key.pem -out server.csr \
  -subj "/CN=localhost"

# Assinar o certificado do servidor com a CA
openssl x509 -req -days 365 -in server.csr \
  -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial \
  -out server-cert.pem

# Repetir para o cliente
openssl genrsa -out client-key.pem 2048
openssl req -new -key client-key.pem -out client.csr \
  -subj "/CN=client"
openssl x509 -req -days 365 -in client.csr \
  -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial \
  -out client-cert.pem

Agora, servidor Flask com mTLS:

from flask import Flask, jsonify
import ssl

app = Flask(__name__)

@app.route('/secure', methods=['GET'])
def secure_endpoint():
    return jsonify({"message": "Você passou na autenticação mTLS!"})

if __name__ == '__main__':
    # Criar contexto SSL para mTLS
    context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
    context.load_cert_chain(
        certfile='server-cert.pem',
        keyfile='server-key.pem'
    )
    # Exigir certificado do cliente e verificar contra CA
    context.load_verify_locations('ca-cert.pem')
    context.verify_mode = ssl.CERT_REQUIRED  # Isso é a chave para mTLS
    context.check_hostname = False  # Desabilitar para teste local

    app.run(ssl_context=context, host='localhost', port=5000)

Cliente Python que se autentica com seu certificado:

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.ssl_ import create_urllib3_context

# Configurar cliente com seu certificado
session = requests.Session()

# Carregar certificado do cliente e chave privada
session.cert = ('client-cert.pem', 'client-key.pem')

# Carregar certificado da CA para validar o servidor
session.verify = 'ca-cert.pem'

# Fazer requisição
response = session.get('https://localhost:5000/secure')
print(response.json())

Saída:

{"message": "Você passou na autenticação mTLS!"}

Se o cliente tentar conectar sem certificado válido:

# Sem certificado
response = requests.get('https://localhost:5000/secure', verify='ca-cert.pem')
# Erro: SSLError: ("certificate required")

Casos de Uso Reais de mTLS

1. Kubernetes e Istio — mTLS automático entre pods para segurança de rede zero-trust
2. gRPC inter-service — Microsserviços autenticam uns aos outros
3. IoT — Dispositivos provam identidade para backend
4. APIs bancárias B2B — Instituições autenticam mutuamente

TLS 1.3: A Revolução da Segurança e Performance

TLS 1.3 (RFC 8446, 2018) é uma redesenho radical do protocolo. Não é apenas um aprimoramento incremental — é uma reengenharia focada em segurança, performance e simplicidade.

Melhorias Principais do TLS 1.3

1. Handshake Reduzido (1-RTT vs 2-RTT)

TLS 1.2 requer 2 round-trips de rede. TLS 1.3 consegue em apenas 1:

• TLS 1.2: ClientHello → ServerHello + Certificate + ServerKeyExchange + ServerHelloDone → ClientKeyExchange + ChangeCipherSpec + Finished → Finished (3 mensagens do servidor, 2 do cliente)
• TLS 1.3: ClientHello (com sugestão de chave) → ServerHello + Certificate + Finished (servidor já pode enviar dados após isso)

Resultado: tempo até primeiro byte (TTFB) reduzido em ~50% em conexões de alta latência.

2. Perfect Forward Secrecy Obrigatório

No TLS 1.2, você precisa de ECDHE. No TLS 1.3, é mandatório — não existe cipher suite sem PFS. Isso significa: se a chave privada do servidor vazar amanhã, seus dados de hoje continuam seguros.

3. Remoção de Algoritmos Frágeis

TLS 1.3 removeu completamente:
- SHA-1, MD5
- RSA com PKCS#1 v1.5 (apenas RSA-PSS é permitido)
- Cifradores de bloco em modo CBC
- Compressão (vulnerável a ataques como CRIME)

4. 0-RTT (Zero Round-Trip Time)

Se você já conversou com o servidor antes, o cliente pode enviar dados sem esperar o handshake completo. Útil para navegação HTTP/2, mas requer cuidado com replay attacks.

Anatomia do Handshake TLS 1.3

Cliente                                             Servidor

ClientHello
(com key_share contendo chave ECDHE pré-calculada)
                        ------->
                                              ServerHello
                                         (com key_share)
                                            {Certificate}
                                      {CertificateVerify}
                                             {Finished}
                        <-------
{Finished}
                        ------->

[Aplicação pode enviar dados aqui]

As mensagens entre {} são cifradas. O cliente e servidor já derivaram as chaves simétricas a partir dos key_shares ECDHE, então toda comunicação após ServerHello é criptografada.

Implementação de TLS 1.3 com Python

import ssl
import socket
import sys

def test_tls13_connection(hostname, port=443):
    """Conectar com TLS 1.3 e exibir detalhes"""

    # Criar contexto que força TLS 1.3
    context = ssl.create_default_context()
    context.minimum_version = ssl.TLSVersion.TLSv1_3
    context.maximum_version = ssl.TLSVersion.TLSv1_3

    try:
        with socket.create_connection((hostname, port), timeout=5) as sock:
            with context.wrap_socket(sock, server_hostname=hostname) as ssock:
                print(f"✓ Conectado com sucesso!")
                print(f"  Protocolo: {ssock.version()}")
                print(f"  Cipher suite: {ssock.cipher()[0]}")

                # Exibir detalhes do certificado
                cert = ssock.getpeercert()
                for field in cert.get('subject', ()):
                    for key, value in field:
                        print(f"  {key}: {value}")

                # Em TLS 1.3, exibir PSK (se usando resumption)
                # Nota: Python 3.11+ suporta PSK

    except ssl.SSLError as e:
        print(f"✗ Erro SSL: {e}")
        sys.exit(1)
    except Exception as e:
        print(f"✗ Erro: {e}")
        sys.exit(1)

if __name__ == '__main__':
    test_tls13_connection('www.google.com')

Saída:

✓ Conectado com sucesso!
  Protocolo: TLSv1.3
  Cipher suite: TLS_AES_256_GCM_SHA384
  commonName: www.google.com

Cipher Suites Permitidas em TLS 1.3

TLS 1.3 simplifica drasticamente. Existem apenas 5 cipher suites oficiais:

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256       (menos comum)
TLS_AES_128_CCM_8_SHA256     (IoT, menos comum)

Todas incluem ECDHE obrigatoriamente. A negociação é muito mais simples — o cliente lista suas 3-5 preferidas, servidor escolhe 1.

Implementação de Servidor TLS 1.3 com FastAPI

from fastapi import FastAPI
from fastapi.responses import JSONResponse
import ssl
import uvicorn

app = FastAPI()

@app.get("/health")
async def health():
    return JSONResponse({"status": "ok"})

@app.get("/data")
async def get_data():
    return JSONResponse({
        "message": "Transmitido via TLS 1.3!",
        "timestamp": "2024-01-15T10:30:00Z"
    })

if __name__ == '__main__':
    # Criar contexto SSL com TLS 1.3
    ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
    ssl_context.load_cert_chain(
        certfile='server-cert.pem',
        keyfile='server-key.pem'
    )

    # Forçar apenas TLS 1.3
    ssl_context.minimum_version = ssl.TLSVersion.TLSv1_3
    ssl_context.maximum_version = ssl.TLSVersion.TLSv1_3

    # Configurar cipher suites preferidas
    ssl_context.set_ciphers(
        'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256'
    )

    uvicorn.run(
        app,
        host='0.0.0.0',
        port=8443,
        ssl_context=ssl_context
    )

Cliente testando:

import httpx

async def test():
    async with httpx.AsyncClient(verify=False) as client:  # verify=False apenas para teste
        response = await client.get('https://localhost:8443/data')
        print(response.json())

# Executar com: asyncio.run(test())

0-RTT em TLS 1.3

0-RTT permite que o cliente envie dados antes do handshake completar, usando uma PSK (Pre-Shared Key) de uma conexão anterior:

import ssl

context = ssl.create_default_context()
context.options |= ssl.OP_NO_TICKET  # Desabilitar tickets se necessário

# Em Python, suporte a 0-RTT é limitado. OpenSSL 1.1.1+ é necessário
# e requer configuração manual. Não é trivial em código Python puro.

# Verificar suporte:
print(f"OpenSSL version: {ssl.OPENSSL_VERSION}")
print(f"0-RTT suportado: {'TLSv1_3' in dir(ssl.TLSVersion)}")

Aviso de Segurança com 0-RTT: Dados 0-RTT são vulneráveis a replay attacks. Um atacante pode capturar a mensagem 0-RTT e reenviá-la. Use apenas para operações idempotentes (GET, não POST).

Compatibilidade com TLS 1.2

Em 2024, TLS 1.2 ainda é suportado em muitos sistemas legados. Uma estratégia pragmática é:

import ssl

context = ssl.create_default_context()

# Permitir TLS 1.2 e 1.3
context.minimum_version = ssl.TLSVersion.TLSv1_2
context.maximum_version = ssl.TLSVersion.TLSv1_3

# Cipher suites para ambos
context.set_ciphers(
    # TLS 1.3
    'TLS_AES_256_GCM_SHA384:'
    'TLS_CHACHA20_POLY1305_SHA256:'
    # TLS 1.2
    'ECDHE-RSA-AES256-GCM-SHA384:'
    'ECDHE-RSA-CHACHA20-POLY1305'
)

Conclusão

Dominar TLS é essencial para qualquer desenvolvedor moderno. As três principais aprendizagens deste artigo são:

1. Handshake é negociação — O handshake não apenas encripta; ele autentica o servidor, negocia algoritmos e estabelece chaves compartilhadas. TLS 1.3 reduziu esse processo pela metade, tornando-o mais rápido e seguro.

2. Cipher suites definem o nível de proteção — Compreender os componentes (ECDHE, AES-256-GCM, SHA-384) permite escolher estrategicamente quais algoritmos suportar. A regra de ouro: retire suporte a MD5, SHA-1, DES e RSA com chaves < 2048 bits. Prefira ECDHE para Perfect Forward Secrecy.

3. mTLS é segurança zero-trust em ação — Quando o cliente também se autentica, você deixa de confiar apenas em senhas/tokens e entra em um modelo onde identidade é verificável criptograficamente. É o futuro das arquiteturas de microsserviços e IoT.

Referências

1. RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
   https://datatracker.ietf.org/doc/html/rfc8446

2. OWASP — Transport Layer Protection
   https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html

3. Mozilla — SSL Configuration Generator
   https://ssl-config.mozilla.org/

4. Cloudflare — How does TLS 1.3 differ from TLS 1.2?
   https://www.cloudflare.com/learning/ssl/what-is-tls-1-3/

5. Cryptography and SSL/TLS Toolkit — OpenSSL Documentation
   https://www.openssl.org/docs/