A IETF | Internet Engineering Task Force, aprovou recentemente a extensão de compactação do certificado TLS , uma otimização que promete reduzir o tamanho do handshake TLS compactando sua maior parte.
Essa publicação é uma colaboração de Adriano Frare
Ao mesmo tempo, o recurso de título do QUIC é o handshake de baixa latência integrado, mais dependente de tamanhos pequenos de handshake do que é amplamente conhecido.
As implementações do QUIC agora enfrentam a decisão de atualizar ou não o código TLS incorporado para suportar a compactação de certificado.
Neste artigo, usarei dados reais (anônimos e agregados) da rede Fastly para ilustrar a importância da compactação na prática para alcançar o desempenho rápido de inicialização que o QUIC promete.
O problema
O handshake de baixa latência do QUIC é seu recurso principal. Ele atinge sua velocidade sobrepondo a funcionalidade do TCP – Transmission Control Protocol e TLS – Transport Layer Security, em uma única troca, em vez de fazê-las em série. Portanto, espera-se concluir na metade do tempo do TCP e TLS empilhados um sobre o outro.
No entanto, a quantidade de dados transferidos por esses handshakes otimizados é restrita devido a considerações de segurança. Em muitos casos, esse limite pode ser pequeno demais para conter todo o aperto de mão completo na parte rápida.
Handshake grandes demais não serão concluídos mais rapidamente do que seus predecessores TCP – Transmission Control Protocol. Manter o aperto de mão pequeno é essencial para cumprir a promessa da QUIC.
Se você não estiver familiarizado com o formato, diagramas como este podem indicar acidentalmente que há um pacote fluindo do servidor para o cliente com Initial, Hello, Cert e Fin. Na realidade, está mostrando um voo de dados nessa direção. Dependendo da quantidade de dados, o vôo pode ser composto de vários datagramas IP consecutivos.
Existem regras de segurança, discutidas abaixo, que limitam a quantidade de dados que um servidor QUIC pode enviar nesse voo sem adicionar um atraso de ida e volta. As cadeias de certificados TLS são muito grandes e, se excederem esse limite, estragarão a promessa de um aperto de mão rápido.
Não é possível para o QUIC confiar nos resultados da validação de endereço do cliente (a propriedade fornecida pelo handshake SYN no TCP) enquanto envia o primeiro voo dos dados do handshake TLS, porque as duas coisas estão integradas e estão sendo feitas ao mesmo tempo.
Para atenuar a ameaça de um ataque de amplificação, o servidor QUIC está limitado a transmitir 3x os dados recebidos do cliente antes de concluir a validação de endereço. Apertos de mão que não se encaixam devem esperar uma viagem de ida e volta extra para concluir a validação de endereço antes de prosseguir e, portanto, perder uma grande vantagem de desempenho do QUIC.
O desempenho do handshake é normalmente limitado pela latência, portanto, o único fator que pode ser controlado sobre a rapidez com que eles são concluídos é o número de viagens de ida e volta no handshake. Adicionar uma viagem extra de ida e volta (ou “voo”) é um grande negócio.
Os ataques de amplificação são projetados para induzir os servidores a enviar grandes quantidades de dados a uma vítima involuntária de terceiros. Simplificando, o atacante finge ser a vítima no primeiro datagrama que envia ao servidor e, em seguida, o servidor responde com uma resposta muito maior diretamente à vítima.
O ataque é chamado de amplificação porque os dados de resposta são projetados para serem muito maiores que os dados originais do invasor e, portanto, permitem que o invasor utilize mais largura de banda através dessa reflexão do que se enviasse dados diretamente para a vítima. A limitação QUIC de um fator 3x mantém a ameaça de amplificação modesta. Os handshakes TLS sobre TCP não têm essa limitação porque o handshake TLS acontece apenas após a conclusão da instalação do TCP. A validação de endereço impede a reflexão de terceiros.
A maioria das partes do handshake QUIC é pequena e varia apenas em tamanho em uma faixa estreita, dependendo exatamente de quais recursos estão sendo usados. O enquadramento QUIC, o servidor TLS Hello, extensões criptografadas e finalizado compõem a maioria desses tipos de bytes. Eles geralmente têm cerca de 200 bytes nas partes do handshake que não variam muito em tamanho.
Há uma grande fonte de conteúdo de tamanho variável que domina a contagem de bytes no QUIC Handshake: a cadeia de certificados TLS. A cadeia de certificados pode ter apenas algumas centenas de bytes ou mais de 10 kilobytes. O tamanho dos certificados incluídos determina em grande parte se o aperto de mão pode ou não ser enviado em um único voo.
A compactação de certificado tem o potencial de melhorar o problema de exceder o fator de amplificação de 3x, reduzindo o tamanho dos handshakes para um tamanho compatível com a restrição de segurança. De fato, o QUIC original do Google (ou seja, pré-padronização) continha um mecanismo semelhante e a introdução da compressão de handshake baseada em padrões para TLS foi projetada para restaurar essa propriedade.
Simplesmente reduzir os bytes no handshake não é suficiente; é óbvio que a compactação de certificado conseguirá isso. Precisamos ver se a compressão geralmente afeta se um aperto de mão se encaixa ou não no orçamento de amplificação de 3x.
O conjunto de dados
O conteúdo de uma cadeia de certificados TLS é o mesmo sobre TCP e QUIC. Isso me permitiu colher amostras de nossa pilha HTTP baseada em TCP amplamente implantada para determinar a distribuição dos tamanhos da cadeia de certificados vistos no mundo real. Era importante pesquisar o uso real para ponderar os dados de acordo com o impacto nos usuários finais. Nenhum dado secreto ou protegido é usado neste conjunto de dados.
A análise
Lembre-se de que a regra de atenuação da amplificação restringe o primeiro voo dos dados do handshake a ser 3x o número de bytes recebidos do cliente. Há vários fatores que complicam uma análise exata de quais amostras em nosso conjunto de dados estão em conformidade com essa regra, porque ela é expressa em bytes de dados relativos a uma quantidade variável de dados que o cliente pode ter enviado. No entanto, o princípio aproximado é intuitivo: você recebe um datagrama para poder enviar três ou menos em resposta.
Vamos ver como os dados são exibidos usando essa abordagem simplificada de contagem de datagramas. Eu o executei primeiro usando um tamanho de datagrama pessimista de 1280, porque todas as redes que suportam IPv6 devem suportar uma MTU (unidade máxima de transmissão) de pelo menos 1280 e a especificação QUIC exige isso no mínimo pelo mesmo motivo.
Esses gráficos mostram um histograma do número de datagramas UDP que seriam necessários para cada handshake em nosso conjunto de dados, com e sem compactação.
Para o MTU de 1280, uma olhada casual nesse gráfico indica que muito mais amostras no conjunto de cadeias de certificados não compactadas (azul) excederam o orçamento de três datagramas do que no conjunto de dados compactado (vermelho). Antes de detalhar os números exatos, vejamos o mesmo conjunto de dados organizado em datagramas de 1500 bytes. 1500 é o MTU mais comum na Internet.
A distribuição geral dos comprimentos de datagramas para o uso de compressão claramente mudou significativamente para menos datagramas em comparação com o descompactado. Obviamente, o uso de datagramas maiores com uma MTU de 1500 bytes significa que você precisa enviar menos deles do que com o MTU 1280, mas a parte dos handshakes mudou para estar em conformidade com a regra de amplificação ao adicionar compactação para as duas MTUs.
Podemos tirar algumas conclusões importantes nesta fase da investigação. Primeiro, entre 40% e 43% (dependendo da MTU) das cadeias de certificado não compactadas observadas são grandes demais para caber em um único voo QUIC de 3 datagramas. Essa é uma fração muito grande de apertos de mão que sofrerá uma penalidade de desempenho devido ao seu tamanho.
Segundo, após aplicar a compactação às cadeias de certificados, apenas 1% a 8% delas (novamente dependendo do MTU) são muito grandes para caber no orçamento de 3 datagramas. A compressão mostra uma melhoria impressionante significativa através desta lente.
Isso é extremamente promissor, mas ainda devemos considerar os dados com base no limite de amplificação expresso em bytes, em vez de datagramas, conforme a especificação exigir. Desta vez, podemos nos concentrar especificamente no limite-chave implícito no fator de aplicação, e não na distribuição inteira de tamanhos.
Infelizmente, isso introduz uma variável que está fora do controle da implementação do servidor: o número de bytes no datagrama inicial do cliente. Enquanto o cliente envia confiavelmente apenas um datagrama, seu tamanho exato depende da implementação do cliente.
O tamanho mínimo que o datagrama inicial de um cliente pode ter é de 1200 bytes (além do UDP / IP) e, realisticamente, o máximo seria baseado na MTU do cliente. Portanto, vamos usar 1452 como a extremidade superior, com base em um datagrama IPv6 completo de 1500 bytes. O Chrome do Google usa um MTU de 1350 bytes no meio do intervalo. Coloquei os pacotes QUIC usando esses tamanhos de datagrama e os mesmos 200 bytes de dados de handshake sem certificado, além de bytes de quadro QUIC que usamos anteriormente. O resultado foi um orçamento da cadeia de certificados para um handshake eficiente entre 3333 e 4356 bytes, dependendo se o tamanho do pacote inicial do cliente estava no limite inferior ou superior do intervalo.
Com base nesses limites, coloquei cada amostra em uma das três categorias: cabe dentro do orçamento, mesmo sem compactação, precisa de compactação para caber dentro do orçamento ou nunca se encaixa dentro do orçamento. Para amostras que não se enquadravam abaixo do limite sem compactação, a economia média de compactação era de 34% e, com frequência, era uma redução suficiente para alterar o estado da amostra para “precisar de compactação para caber no orçamento”.
Os clientes que usam pacotes iniciais de 1452 bytes poderiam concluir com eficiência uma fração ainda maior de seus handshakes, porque têm permissão para receber 4356 informações da cadeia de certificados.
É hora de revisar nossas perguntas iniciais uma última vez, com base nesses dados refinados baseados em tamanho de bytes. Felizmente, eles contam uma história muito semelhante à análise simplificada baseada em datagramas.
Entre 40% e 44% (dependendo do tamanho do pacote inicial do cliente) das cadeias de certificados descomprimidas observadas são grandes demais para caber em um único voo de handshake QUIC que está em conformidade com a regra de amplificação de 3x. Essa é uma fração muito grande de apertos de mão que sofrerá uma penalidade de desempenho devido ao seu tamanho.
Segundo, após aplicar a compactação às cadeias de certificados, apenas 1% a 9% delas (novamente dependendo de quantos bytes o cliente iniciou a conexão) são muito grandes para caber no orçamento de amplificação de 3x. A compactação não apenas reduz a contagem de bytes, mas o faz de uma maneira que interage extremamente favoravelmente com as regras de segurança.
É provável que esses resultados possam ser melhorados um pouco mais usando um algoritmo de compactação mais agressivo, como brotli, em vez de desinflar. O equilíbrio certo dependerá do ambiente de execução. Brotli geralmente tem melhores taxas de compactação, mas com maior custo para criar. Servidores que podem pré-calcular cadeias de certificados podem achar essa uma opção atraente, embora pareçamos estar alcançando o ponto de retornos decrescentes.
A conclusão
Primeiro, a extensão de compactação do certificado TLS tem um impacto muito grande no desempenho do QUIC. Embora a extensão seja nova e esteja sendo introduzida com bastante atraso no processo, quando comparada às agendas gerais de implantação do QUIC, parece muito importante que clientes e servidores implementem a nova extensão para que o handshake do QUIC possa cumprir seu faturamento. Sem ajuda, 40% dos handshakes completos do QUIC não seriam melhores que o TCP, mas a compactação pode reparar a maior parte desse problema.
Diante de tudo que foi exposto, esta extensão tem um futuro muito promissor.
Fonte: https://www.fastly.com
O TLS é um padrão proposto pela IETF |Internet Engineering Task Force, definido pela primeira vez em 1999, e a versão atual é o TLS 1.3 definido no RFC 8446 em agosto de 2018. O TLS baseia-se nas especificações SSL anteriores (1994, 1995, 1996) desenvolvidas pela Netscape Communications para adicionar o protocolo HTTPS ao navegador da Web Navigator.
LEIA OUTROS ARTIGOS DE ADRIANO FRARE
Relatório de Segurança de 1 milhão de sites. Por Adriano Frare
TLS 1.3: A tímida adoção de criptografia mais forte está ajudando os bandidos. Por Adriano Frare
Como o Google faz o gerenciamento do ciclo de vida do certificado. Por Adriano Frare
O que é transparência de certificado? Por Adriano Frare
Quer confirmar o local onde pretende fazer a validação do certificado digital ICP-Brasil?
LCR fora do ar suspende a utilização dos certificados digitais ICP-BRASIL
