SSL/TLS: conceitos-chave e protocolos no desenvolvimento

O que é SSL/TLS?

SSL (Secure Sockets Layer) e TLS (Transport Layer Security) são protocolos criptográficos que garantem a transmissão segura de dados pela rede. O SSL, desenvolvido pela Netscape na década de 1990, é considerado obsoleto após a versão 3.0 devido às vulnerabilidades POODLE e BEAST. O TLS, seu sucessor, passou pelas versões 1.0, 1.1, 1.2 e 1.3 — apenas TLS 1.2 e TLS 1.3 são considerados atuais. Todas as plataformas móveis modernas exigem TLS para conexões de rede, e a App Store e o Google Play verificam isso durante a revisão.

Por que TLS para aplicativos móveis

Sem TLS, o tráfego entre o aplicativo e o servidor é transmitido como texto simples — qualquer pessoa na mesma rede Wi-Fi pode interceptar logins, senhas, tokens e dados pessoais dos usuários usando Wireshark ou tcpdump. O TLS criptografa todos os dados transmitidos (criptografia em nível de transporte) e verifica a autenticidade do servidor através de uma cadeia de certificados X.509. De acordo com IETF (2018), o TLS 1.3 usa apenas cifras AEAD modernas (AES-GCM, ChaCha20-Poly1305), excluindo algoritmos obsoletos como RC4 e 3DES.

HTTPS e TLS

HTTPS (HTTP Secure) é HTTP sobre TLS. Quando um aplicativo móvel faz uma requisição via https://, ele primeiro estabelece uma conexão TLS com o servidor e depois transmite os cabeçalhos HTTP e o corpo da requisição através do canal criptografado. Sem HTTPS, nenhuma API séria deve operar — é a higiene básica de segurança. De acordo com OWASP (2026), conexões não seguras estão entre as 3 principais vulnerabilidades de aplicativos móveis.

Como funciona o TLS Handshake

TLS Handshake é o processo de estabelecimento de uma conexão segura entre um cliente e um servidor. As partes negociam a versão do protocolo, selecionam um conjunto de cifras (cipher suite), trocam chaves através de criptografia assimétrica e verificam certificados. No TLS 1.2, o handshake requer 2 Round Trip Time (2 RTT): cliente → servidor com ClientHello, servidor → cliente com ServerHello e Certificate, em seguida as mensagens finais Finished. O TLS 1.3 reduz esse processo para 1 RTT.

Etapas detalhadas do handshake TLS 1.2

Primeira etapa: ClientHello — o cliente envia versões TLS suportadas, uma lista de conjuntos de cifras e um número aleatório. O servidor responde com ServerHello, selecionando uma versão e um conjunto de cifras, envia seu certificado X.509 (Certificate) e a mensagem ServerHelloDone. O cliente verifica o certificado através de uma cadeia de autoridades certificadoras (CA) confiáveis, gera um pre-master secret, criptografa-o com a chave pública do certificado e o envia ao servidor em ClientKeyExchange. Após isso, ambas as partes geram chaves de sessão e trocam mensagens ChangeCipherSpec e Finished. A partir deste ponto, todos os dados são criptografados simetricamente.

import Security

let url = URL(string: "https://api.example.com")!
let session = URLSession(configuration: .default,
                           delegate: self,
                           delegateQueue: nil)

func urlSession(
    _ session: URLSession,
    didReceive challenge: URLAuthenticationChallenge,
    completionHandler: @escaping (URLSession.AuthChallengeDisposition,
                                    URLCredential?) -> Void
) {
    let trust = challenge.protectionSpace.serverTrust
    guard let trust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    completionHandler(.useCredential, URLCredential(trust: trust))
}

Exemplo de tratamento de URLAuthenticationChallenge no iOS via URLSessionDelegate. Este método é chamado durante cada TLS Handshake, permitindo que o aplicativo faça uma verificação personalizada do certificado do servidor. Para uso em produção, adicione a verificação do certificado via SecTrustEvaluateWithError e compare com uma impressão digital pré-salva — só então chame useCredential.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, 2018) é a primeira grande atualização do protocolo em 10 anos. Principais melhorias: handshake reduzido para 1 RTT (0 RTT para conexões repetidas), remoção de conjuntos de cifras obsoletos (troca de chaves RSA, modo CBC), Perfect Forward Secrecy (PFS) obrigatório e proteção contra ataques de downgrade via signed transcript. De acordo com Qualys SSL Labs (2026), o TLS 1.3 oferece proteção mesmo quando a chave de longo prazo do servidor é comprometida graças ao PFS.

0-RTT (Zero Round Trip Time) é um recurso do TLS 1.3 que permite ao cliente enviar dados imediatamente junto com ClientHello durante uma conexão repetida via PSK (Pre-Shared Key). Isso acelera o carregamento de telas subsequentes em aplicativos móveis, especialmente com requisições frequentes ao mesmo servidor. No entanto, os dados 0-RTT não são protegidos contra ataques de repetição — podem ser interceptados e reenviados. Use 0-RTT apenas para requisições idempotentes (GET, PUT) sem efeitos colaterais.

TLS no iOS: App Transport Security

App Transport Security (ATS) é o mecanismo da Apple que exige conexões HTTPS com TLS 1.2 ou superior, ativado por padrão desde o iOS 9. O ATS bloqueia todas as conexões HTTP e HTTPS com TLS abaixo de 1.2. O desenvolvedor pode configurar exceções no Info.plist via NSAppTransportSecurity para domínios específicos, mas a Apple recomenda minimizar exceções e usar HTTPS em todos os lugares. Violar os requisitos do ATS é motivo de rejeição do aplicativo na revisão da App Store.

<!-- Info.plist — App Transport Security -->
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <false/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>cdn.example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
        </dict>
    </dict>
    <key>NSAllowsLocalNetworking</key>
    <true/>
</dict>

Configuração do ATS no Info.plist. NSAllowsArbitraryLoads está definido como false — todas as conexões devem usar HTTPS. Para o domínio cdn.example.com, uma versão mínima de TLS 1.2 é especificada, NSAllowsLocalNetworking=true permite HTTP para rede local (útil para servidores de desenvolvimento). A Apple recomenda fortemente não ativar NSAllowsArbitraryLoads sem NSExceptionDomains — isso deve ser uma exceção, não uma regra geral.

TLS no Android: Network Security Config

Network Security Config é o mecanismo do Android para configurar HTTPS e TLS sem alterar o código Java/Kotlin. A configuração é especificada no arquivo network_security_config.xml e conectada no AndroidManifest através do atributo android:networkSecurityConfig. Suporta configuração de certificados confiáveis (CA de usuário e sistema), Certificate Pinning, desativação de HTTP em texto claro, substituições de depuração e redirecionamento de tráfego.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-01-01">
            <pin digest="SHA-256">
                47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
            </pin>
        </pin-set>
    </domain-config>
</network-security-config>

Network Security Config para Android. O base-config bloqueia tráfego em texto claro e confia apenas em certificados CA do sistema (sem certificados de usuário — proteção contra instalação de certificados MitM por usuários). O domain-config para api.example.com contém um pin-set com uma impressão digital SHA-256 do certificado. Se o certificado do servidor mudar antes da data de expiração especificada, a conexão será rejeitada — esta é uma forma estrita de Certificate Pinning.

Certificate Pinning e segurança

Certificate Pinning é uma técnica de fixação do certificado ou chave pública do servidor no código do aplicativo. Durante cada TLS Handshake, o cliente compara o certificado do servidor com uma impressão digital pré-salva (hash SHA-256). Mesmo que um invasor obtenha um certificado CA confiável ou comprometa a autoridade certificadora, ele não pode realizar um ataque MitM — o aplicativo verifica a impressão digital específica, não a cadeia CA. Isso é especialmente importante para aplicativos financeiros e aplicativos que lidam com dados confidenciais.

Riscos e alternativas ao Pinning

Certificate Pinning requer cautela: quando o certificado do servidor muda, todas as versões antigas do aplicativo pararão de se conectar. Recomenda-se armazenar várias impressões digitais de backup (principal + backup), especificar uma data de expiração do pin-set e implementar um mecanismo de fallback através de verificação CA padrão. Uma alternativa é Trust On First Use (TOFU), onde o aplicativo memoriza o certificado na primeira conexão e alerta o usuário quando ele muda. De acordo com a OWASP (2026), a ausência de Certificate Pinning está entre as 3 principais vulnerabilidades de aplicativos móveis (M3: Comunicação insegura).

Implementação de Pinning no Alamofire

No Alamofire 5+, o Certificate Pinning é configurado através de ServerTrustManager com PinnedCertificatesTrustEvaluator (verificação do certificado completo) ou PublicKeysTrustEvaluator (apenas a chave pública). A chave pública é preferível — ela não muda quando o certificado é renovado com o mesmo CA. Crie um ServerTrustManager com um dicionário [host: evaluator], passe-o para Session e use-o para todas as requisições a APIs protegidas.