Resumo

  • O RFC 8879 permite substituir Certificate por CompressedCertificate no TLS 1.3 quando o receptor anunciou algoritmos que sabe descomprimir. O anúncio permite uma representação; não prova uso nem concede orçamento irrestrito ao emissor.
  • O uncompressed_length precisa coincidir byte a byte com a mensagem reconstruída, e a saída nunca pode ultrapassá-lo. O receptor pode impor um teto local menor que o limite de 24 bits do protocolo, antes de o certificado autenticar qualquer coisa.
  • Descompressão bem-sucedida não é validação. A trilha deve distinguir oferta, escolha, payload, tamanho declarado e real, hash reconstruído, cadeia analisada, resultado de confiança, alerta, fallback e conclusão do transporte.

A primeira pergunta não era quem, mas quanto

Considere um terminador recebendo milhares de conexões novas. O cliente listou zlib, Brotli e Zstandard em ClientHello. O servidor escolheu Brotli e enviou um CompressedCertificate curto cujo cabeçalho declara doze megabytes de saída.

Nome, CA e chave pública continuam dentro da carga. Eles não podem justificar a alocação inicial. O cliente primeiro confirma que ofereceu aquele algoritmo, compara a declaração com o mesmo limite usado para Certificate comum, contém o decoder e exige que a saída final tenha exatamente o tamanho informado.

Essa ordem preserva autoridade local. O servidor escolhe uma forma entre as que o cliente aceitou; o cliente decide quais transforms executa e quanto custo uma sessão ainda não autenticada pode impor. Suporte a Brotli não é autorização para reservar memória livremente.

O framing aceita até 16.777.215 bytes, mas o RFC permite limites inferiores. A fronteira precisa valer igualmente nas rotas comprimida e comum. Uma cadeia grande demais em Certificate não deve entrar no parser só porque atravessou a rede dentro de um envelope menor.

Oferta, uso e sucesso são eventos diferentes

compress_certificate é unidirecional. No ClientHello, descreve como o cliente pode receber o Certificate do servidor. No CertificateRequest, descreve como o servidor pode receber o Certificate do cliente. Não existe resposta simétrica confirmando a extensão.

Quem envia pode selecionar um algoritmo listado ou manter Certificate sem compressão. Logo, ver a extensão 27 não prova que a mensagem 25 apareceu. Métrica de offers mede capacidade declarada; métrica de seleção mede execução; nenhuma delas substitui os contadores de reconstrução e validação.

As direções também não se presumem. Aceitar certificado de servidor comprimido não significa conseguir enviar certificado de cliente comprimido. Builds podem habilitar somente RX ou TX, e cada lado pode aceitar conjuntos diferentes.

O mecanismo vale para TLS 1.3 e posteriores; numa negociação TLS 1.2 ele é ignorado. Ele não reativa compressão geral de records. A transformação é restrita à mensagem Certificate e termina antes de seu processamento comum.

O objeto é a mensagem codificada inteira

Não se comprimem arquivos PEM soltos. A entrada é a Certificate codificada que seria transmitida: context, lista e extensions de cada entrada. Se outra extension altera o conteúdo da mensagem, esses bytes também entram na compressão.

Por isso são necessários hashes em camadas. Um identifica algoritmo, cabeçalho e payload recebidos. Outro identifica a Certificate reconstruída. As fingerprints do leaf e dos intermediários registram, depois, quais objetos a validação de cadeia realmente examinou.

O mesmo input gera representações diferentes com zlib, Brotli e Zstandard. Atualizações de library podem mudar o payload preservando a saída. Um hash apenas do conteúdo comprimido não prova equivalência entre algoritmos nem identifica sozinho a cadeia aceita.

Precompressão segue a mesma regra. OpenSSL permite armazenar certificados de servidor comprimidos; certificados de cliente são produzidos sob demanda porque incluem um context específico do CertificateRequest. Cache de servidor deve estar ligado à mensagem inteira, não ao hostname. Mudança de chain, intermediate ou extension exige invalidação.

O tamanho declarado é uma barreira

Se a descompressão falhar, produzir mais que o valor informado ou terminar com comprimento diferente, o receptor encerra com bad_certificate. A proteção precisa operar durante a saída, não apenas conferir o estrago no fim.

O campo ajuda a rejeitar cedo, mas não autentica o emissor nem promete estrutura válida. Um número permitido pelo protocolo pode inviabilizar um serviço concorrente. O limite local nasce de memória, CPU e volume simultâneo medidos.

Nem toda compressão reduz. Os testes do BoringSSL incluem transformações que encolhem, expandem e geram dados aleatórios. A regra é reconstrução exata dentro da cota. Ratio menor que um é objetivo de performance, não requisito de validade.

Registrar declaração, resultado real, pico de alocação, tempo e classe de erro. Um ratio ótimo pode acompanhar custo excessivo; uma melhora modesta pode evitar um packet importante. O percentual isolado não decide segurança nem latência.

A confiança começa depois do decoder

Certificate reconstruída recebe o mesmo tratamento da versão comum: parse, construção da cadeia, nomes, datas, política local e CertificateVerify no transcript TLS 1.3. Compressão não torna confiável uma CA desconhecida nem corrige assinatura inválida.

Separar as falhas preserva causalidade. Algoritmo não oferecido é negociação; overrun, decoder ou length mismatch são reconstrução; estrutura inválida é parsing; chain e nome são validação; CertificateVerify é autenticação do handshake.

Somar tudo como certificate_error apaga onde houve rejeição. Chamar decompression_success de autenticação também extrapola: ainda não há prova da identidade esperada, da posse da private key ou da permissão de aplicação.

O código mostra a sequência. BoringSSL constrói Certificate, guarda seu comprimento, aplica o callback e serializa a versão comprimida. OpenSSL separa preferências, TX, RX e precompressão. Registro IANA, implementação disponível e configuração ativa são evidências distintas.

A economia precisa chegar ao resultado

Cadeias costumam dominar o primeiro handshake. Menos bytes podem reduzir packets ou evitar um round trip, mas isso depende de congestion window, perda, chain, CPU, cache e algoritmo comum. O tamanho do PEM no disco não equivale à Certificate codificada.

Juntar offer, direção, algoritmo real, tamanhos, records, packets, retransmissões, CPU, memória, validação e tempo final. Usar como controle a mesma identidade e política sem compressão. Só essa comparação permite atribuir benefício.

Sem algoritmo comum, Certificate normal é fallback válido. Aumento de fallback pode refletir client mix, build sem decoder ou deslocamento da terminação TLS. Se ambos os caminhos mantêm limite e validação, muda a representação, não a confiança.

Fontes