SSL/TLS — o que é, protocolos e princípio de funcionamento da criptografia

O que é SSL/TLS?

SSL (Secure Sockets Layer) é um protocolo desenvolvido pela Netscape em 1995 para proteger o tráfego web. A primeira versão, SSL 1.0, nunca foi publicada; SSL 2.0 (1995) e SSL 3.0 (1996) foram usados até o início dos anos 2000, mas continham vulnerabilidades críticas. O SSL foi sucedido pelo TLS (Transport Layer Security) — uma versão melhorada padronizada pela IETF. TLS 1.0 (1999) foi baseado no SSL 3.0, enquanto as versões subsequentes TLS 1.1 (2006), TLS 1.2 (2008) e TLS 1.3 (2018) gradualmente se afastaram da arquitetura original, adicionando novos algoritmos de criptografia e corrigindo vulnerabilidades. Hoje, o SSL é considerado obsoleto e todos os sistemas modernos usam TLS, embora ambos os protocolos sejam frequentemente mencionados juntos como SSL/TLS por inércia.

História do protocolo

A história do SSL/TLS começou com a necessidade de transmissão segura de dados no início da web. Em 1994, a Netscape desenvolveu o SSL 1.0 para seu navegador Navigator, mas o protocolo nunca foi publicado devido a sérios problemas de segurança. O SSL 2.0 foi lançado em 1995 e teve uso prático, embora contivesse inúmeras vulnerabilidades: falta de proteção contra ataques Man-in-the-Middle, algoritmos de criptografia fracos e suscetibilidade a ataques de truncamento. O SSL 3.0 (1996) corrigiu a maioria dos problemas, mas em 2014 foi descoberta a vulnerabilidade POODLE, após a qual a IETF declarou oficialmente todas as versões do SSL obsoletas. TLS 1.0–1.3 melhoraram progressivamente a solidez criptográfica, o desempenho e a privacidade, com TLS 1.3 reduzindo o handshake de duas viagens de ida e volta para uma — algo crítico para aplicativos móveis com conexões instáveis.

Como funciona o Handshake SSL/TLS

Handshake é o processo de estabelecimento de uma conexão segura entre um cliente e um servidor. Consiste em várias etapas sequenciais durante as quais as partes concordam com a versão do protocolo, selecionam algoritmos de criptografia, trocam chaves e se autenticam mutuamente. No TLS 1.3, o handshake leva apenas uma viagem de ida e volta (1-RTT), enquanto no TLS 1.2 eram necessárias duas (2-RTT).

O primeiro passo é o cliente enviar um ClientHello — uma mensagem contendo uma lista de versões TLS suportadas, conjuntos de cifra e um número aleatório. O servidor responde com um ServerHello contendo a versão e cifra escolhidas, seu certificado X.509 e uma assinatura digital. O cliente verifica o certificado através da cadeia de autoridades certificadoras (CA), gera uma chave de sessão e a envia criptografada com a chave pública do servidor extraída do certificado. Após a confirmação do servidor, começa a transmissão segura de dados. Todo o handshake leva de 1 a 3 milissegundos em dispositivos modernos, tornando-o imperceptível para o usuário.

Certificados X.509 e cadeia de confiança

A base da autenticação TLS é a Infraestrutura de Chave Pública (PKI) construída sobre certificados no formato X.509. Cada certificado contém: um nome de domínio (Common Name ou Subject Alternative Name), a chave pública do servidor, o nome do emissor (Autoridade Certificadora), uma data de validade e a assinatura digital da CA. O cliente verifica o certificado do servidor ao longo da cadeia de confiança: do certificado do servidor até a CA raiz, cujo certificado está embutido no sistema operacional. Em dispositivos Android, os certificados raiz são armazenados no keystore do sistema, atualizado via Google Play Services; no iOS — via atualizações do iOS. Se algum elo da cadeia for quebrado (certificado expirado, incompatibilidade de domínio, CA desconhecida), o cliente encerra a conexão. Para certificados autoassinados (usados em desenvolvimento), é necessária confiança explícita — no Android via Network Security Config, no iOS via NSExceptionDomains no Info.plist. O processo de validação da cadeia de certificados também inclui verificação de status de revogação através de CRL (Lista de Revogação de Certificados) ou OCSP (Protocolo de Status de Certificado Online), embora em dispositivos móveis as solicitações OCSP sejam frequentemente ignoradas para acelerar a conexão — este é um compromisso entre segurança e desempenho que os arquitetos devem considerar.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()