Cipher suites TLS com nomes no OpenSSL, GnuTLS e NSS

TLS_NULL_WITH_NULL_NULL

A suite provisória de uma conexão antes de o primeiro handshake terminar: sem troca de chaves, sem autenticação, sem proteção.

TLS_NULL_WITH_NULL_NULL (0x00,0x00) descreve o estado inicial de uma conexão TLS 1.2 (RFC 5246 §6.1). Ela nunca é negociada; um servidor que a seleciona tem um bug grave.

TLS_RSA_WITH_RC4_128_SHA

RC4 com SHA-1 e transporte de chave RSA: antes, uma escolha popular contra o BEAST; hoje, proibida pela RFC 7465.

O RC4 escapava dos ataques ao CBC de 2011 a 2013 e por isso chegou a ser recomendado por pouco tempo, mas os vieses do fluxo de chave (keystream) dele permitem que atacantes recuperem texto claro enviado repetidamente, como cookies. A RFC 7465 §2 determina que os clientes NÃO DEVEM incluir suites RC4 no ClientHello e os servidores NÃO DEVEM selecioná-las.

TLS_RSA_WITH_3DES_EDE_CBC_SHA

A suite que o TLS 1.1 tornou de implementação obrigatória; os blocos de 64 bits a deixaram vulnerável ao ataque de aniversário Sweet32.

A RFC 4346 §9 exigia que as implementações de TLS 1.1 oferecessem suporte a TLS_RSA_WITH_3DES_EDE_CBC_SHA (OpenSSL: DES-CBC3-SHA). O Triple DES tem blocos de 64 bits; por isso, depois de cerca de 2^32 blocos com a mesma chave, as colisões vazam texto claro. O ataque Sweet32, de 2016, recuperou dessa forma cookies HTTP de conexões de longa duração.

Ela também não tem forward secrecy. As bibliotecas modernas a desativam por padrão, e a IANA a marca como desaconselhada.

TLS_RSA_WITH_AES_128_CBC_SHA

A suite que o TLS 1.2 tornou de implementação obrigatória; não tem forward secrecy, usa CBC, e a RFC 10015 agora a proíbe.

A RFC 5246 §9 exigia que toda implementação de TLS 1.2 oferecesse suporte a TLS_RSA_WITH_AES_128_CBC_SHA (OpenSSL: AES128-SHA), por isso ela é a suite de último recurso de muitos clientes antigos. Com o transporte de chave RSA, o cliente criptografa o segredo pré-mestre (premaster secret) com a chave do certificado do servidor: quem obtiver essa chave depois consegue descriptografar todas as sessões gravadas.

O CBC com MAC-then-encrypt a deixou exposta a ataques de padding oracle como o Lucky Thirteen. A RFC 10015 §4 agora determina que os clientes NÃO DEVEM oferecer e os servidores NÃO DEVEM selecionar suites com troca de chaves RSA no TLS 1.2.

TLS_EMPTY_RENEGOTIATION_INFO_SCSV

Um valor de sinalização, e não uma suite de verdade: indica que o cliente aceita a renegociação segura (RFC 5746).

Os clientes colocam TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00,0xFF) na lista de cifras para sinalizar suporte à renegociação segura sem enviar uma extensão. A RFC 5746 §3.3 o introduziu porque alguns servidores tratavam extensões de forma incorreta; ele “não pode ser negociado”. A correção da renegociação eliminou o ataque de 2009 em que um atacante inseria os próprios dados na frente da sessão renegociada de um cliente.

TLS_AES_128_GCM_SHA256

A cipher suite que toda implementação de TLS 1.3 precisa aceitar: AES-128 no modo GCM, com SHA-256 no escalonamento de chaves (key schedule).

A RFC 8446 §9.1 torna obrigatória a implementação da TLS_AES_128_GCM_SHA256 no TLS 1.3, e a RFC 9846, sucessora dela, mantém o requisito. No TLS 1.3, uma suite define apenas o AEAD e o hash do HKDF; a troca de chaves (por exemplo, X25519MLKEM768) e a assinatura (por exemplo, ecdsa_secp256r1_sha256) são negociadas em extensões separadas.

O OpenSSL configura as suites do TLS 1.3 com -ciphersuites, e não com a string -cipher usada no TLS 1.2; por isso, mudar a lista de cifras de um servidor muitas vezes não altera nada no TLS 1.3.

TLS_AES_256_GCM_SHA384

AES-256-GCM com SHA-384, uma das duas suites do TLS 1.3 que, segundo a RFC 8446, as implementações DEVERIAM aceitar.

A TLS_AES_256_GCM_SHA384 combina uma chave AES de 256 bits com SHA-384 no escalonamento de chaves. A RFC 8446 §9.1 a inclui, junto com a TLS_CHACHA20_POLY1305_SHA256, entre as suites que as implementações DEVERIAM aceitar; a maioria dos servidores a oferece, e os perfis alinhados ao CNSA a exigem.

Contra um atacante quântico, o algoritmo de Grover reduziria, no máximo, pela metade o comprimento da chave do AES em termos efetivos, então o AES-256 mantém uma margem ampla; o NIST também considera o AES-128 adequado, porque esses ataques se paralelizam mal.

TLS_CHACHA20_POLY1305_SHA256

ChaCha20-Poly1305, a suite do TLS 1.3 que é rápida em software em dispositivos sem instruções AES.

A TLS_CHACHA20_POLY1305_SHA256 usa a cifra de fluxo ChaCha20 com o autenticador Poly1305 (RFC 8439). Ela roda em tempo constante sem suporte de hardware, o que a tornou a suite preferida em dispositivos móveis sem instruções AES; os servidores costumam respeitar a preferência do cliente que a coloca em primeiro lugar na lista.

Segundo a RFC 8446 §9.1, as implementações de TLS 1.3 DEVERIAM oferecer suporte a ela. As equivalentes no TLS 1.2 são TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 e TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (RFC 7905).

TLS_AES_128_CCM_SHA256

AES-128-CCM para TLS 1.3, usada principalmente em dispositivos com recursos limitados que já têm hardware de AES-CCM.

O CCM combina a criptografia AES-CTR com um AES-CBC-MAC e é comum em rádios de IoT. A suite TLS_AES_128_CCM_SHA256 é marcada como recomendada pela IANA, ao contrário da TLS_AES_128_CCM_8_SHA256, cuja tag de 8 bytes a IANA não recomenda para uso geral.

TLS_FALLBACK_SCSV

Um valor de sinalização que informa ao servidor que o cliente está tentando de novo com uma versão do protocolo mais baixa (RFC 7507).

Clientes que repetiam handshakes com falha usando versões do protocolo mais antigas podiam ser forçados por um atacante a descer até o SSL 3.0, o que o POODLE explorou em 2014. O cliente envia TLS_FALLBACK_SCSV (0x56,0x00) nessa nova tentativa; um servidor que aceita uma versão mais alta do que a oferecida pelo cliente então aborta com inappropriate_fallback, em vez de continuar. O valor sentinela de downgrade do TLS 1.3 em ServerHello.random torna o mecanismo desnecessário entre pares TLS 1.3.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

A suite comum do TLS 1.2 para certificados ECDSA: troca de chaves ECDHE, autenticação ECDSA e AES-128-GCM.

A TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (RFC 5289) oferece forward secrecy com uma chave efêmera ECDHE e autentica o servidor com um certificado ECDSA, normalmente na curva P-256. É a suite do TLS 1.2 que os navegadores preferem quando o servidor tem um certificado ECDSA.

Nas strings de cifras do OpenSSL, ela se chama ECDHE-ECDSA-AES128-GCM-SHA256. Um servidor que só tem um certificado RSA não consegue negociá-la — a parte de autenticação de uma suite do TLS 1.2 precisa corresponder ao tipo de chave do certificado.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

A suite do TLS 1.2 que o HTTP/2 exige: troca de chaves ECDHE, autenticação RSA e AES-128-GCM.

A RFC 9113 §9.2.2 exige que as implantações de HTTP/2 com TLS 1.2 ofereçam suporte a TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 com a curva P-256, para que um cliente e um servidor que sigam as restrições do HTTP/2 sobre o TLS 1.2 sempre tenham uma suite em comum.

O OpenSSL a chama de ECDHE-RSA-AES128-GCM-SHA256. Apesar do nome, a chave RSA só assina o handshake; a chave de sessão vem da troca ECDHE efêmera, então a suite tem forward secrecy.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

A variante de 256 bits da suite mais comum do TLS 1.2: ECDHE, autenticação RSA, AES-256-GCM e a PRF com SHA-384.

Quase todo servidor TLS 1.2 com certificado RSA oferece a TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289). O SHA384 do nome define o hash da PRF do TLS 1.2; o GCM em si não precisa de um MAC separado.

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

ChaCha20-Poly1305 para TLS 1.2, com troca de chaves ECDHE e certificado ECDSA (RFC 7905).

Adicionada ao TLS 1.2 em 2016, esta suite levou o AEAD ChaCha20-Poly1305, eficiente em software, a servidores que ainda não podiam oferecer TLS 1.3. A IANA a marca como recomendada. No OpenSSL, o nome dela é ECDHE-ECDSA-CHACHA20-POLY1305.