Os desenvolvedores geralmente querem criar aplicações e infraestrutura usando bibliotecas lançadas oficialmente e com suporte. Mesmo com o HTTP/3, há uma grande necessidade de uma biblioteca prática que ofereça suporte ao QUIC sem aumentar os custos de manutenção nem a complexidade operacional da infraestrutura de produção.
Para muitos usuários de QUIC+HTTP/3, a biblioteca criptográfica padrão é a OpenSSL. Instalada por padrão na maioria dos sistemas operacionais baseados em Linux, a OpenSSL é a principal biblioteca de Segurança da Camada de Transporte (TLS) e é usada pela maioria das aplicações de rede.
O problema: incompatibilidade entre o OpenSSL e o QUIC+HTTP/3
Mesmo sendo tão amplamente utilizado, o OpenSSL não fornece a API TLS necessária para oferecer suporte ao QUIC. Em vez disso, o Comitê de Gestão do OpenSSL decidiu implementar por conta própria uma pilha QUIC completa. Essa iniciativa exige um esforço considerável e está prevista para o OpenSSL v3.4, mas, de acordo com o roadmap do OpenSSL, isso provavelmente não acontecerá antes do final de 2024. Além disso, o Produto Mínimo Viável inicial da implementação do OpenSSL não incluirá a implementação da API QUIC, portanto, não há um caminho claro para que os usuários obtenham suporte a HTTP/3 com o OpenSSL.
Opções de suporte a TLS para QUIC
Nessa situação, há duas opções para os usuários que buscam suporte a QUIC TLS para suas necessidades de HTTP/3:
- Implementação de QUIC do OpenSSL – Como mencionado acima, o OpenSSL está trabalhando atualmente na implementação de uma pilha QUIC completa por conta própria. Esse desenvolvimento incorporará todas as funcionalidades do QUIC à implementação, facilitando muito o uso da API TLS do OpenSSL por usuários de HTTP/3, sem que precisem se preocupar com funcionalidades específicas do QUIC.
- Bibliotecas compatíveis com a API QUIC do BoringSSL – Várias bibliotecas SSL, como BoringSSL, quicTLS e LibreSSL (todas originalmente derivadas do OpenSSL), agora oferecem a funcionalidade QUIC TLS por meio da implementação da API QUIC do BoringSSL. No entanto, essas bibliotecas não são tão amplamente adotadas quanto o OpenSSL. Essa opção também exige compilar a biblioteca SSL a partir do código-fonte e instalá-la em todos os servidores que precisam de suporte a QUIC+HTTP/3, o que pode não ser viável para todos. Ainda assim, atualmente essa é a única opção para quem deseja usar HTTP/3, pois a implementação QUIC TLS do OpenSSL ainda não está pronta.
Uma nova solução: a camada de compatibilidade com o OpenSSL
Na NGINX, esses desafios nos inspiraram a criar a Camada de Compatibilidade com OpenSSL para simplificar as implantações de QUIC+HTTP/3 que usam OpenSSL e ajudar a evitar as complexidades associadas à manutenção de uma biblioteca SSL separada em ambientes de produção.
Disponível com o NGINX Open Source mainline desde a versão 1.25.0 e o NGINX Plus R30, a Camada de Compatibilidade com OpenSSL permite que o NGINX execute QUIC+HTTP/3 sobre o OpenSSL sem precisar aplicar patches ou recompilá-lo. Isso elimina a necessidade de compilar e implantar bibliotecas TLS de terceiros para obter suporte a QUIC. Como os usuários não precisam usar bibliotecas de terceiros, também reduz a dependência dos cronogramas e roteiros dessas bibliotecas, tornando-a uma solução comparativamente mais fácil de implantar em produção.
Como funciona a camada de compatibilidade com o OpenSSL
A Camada de Compatibilidade com o OpenSSL implementa estas etapas:
- Converte um handshake QUIC em um handshake TLS 1.3 compatível com o OpenSSL.
- Encaminha as mensagens de handshake TLS para o OpenSSL e recebe as mensagens dele.
- Obtém do OpenSSL as chaves de criptografia para os níveis de criptografia de handshake e de aplicação.
- Transfere os parâmetros de transporte QUIC de e para o OpenSSL.
Considerando o nível de adoção atual do OpenSSL e sua situação em relação ao suporte oficial a QUIC+HTTP/3, acreditamos que oferecer uma opção simples e escalável para habilitar o QUIC é um passo na direção certa. Isso também promoverá a adoção do HTTP/3 e permitirá obter feedback valioso. Acima de tudo, confiamos que a Camada de Compatibilidade do OpenSSL nos ajudará a oferecer uma solução mais robusta e escalável para nossos usuários corporativos e para toda a comunidade NGINX.
Observação: embora estejamos garantindo que os usuários do NGINX tenham uma opção fácil e escalável com a disponibilização da Camada de Compatibilidade do OpenSSL, eles ainda podem usar bibliotecas de terceiros, como BoringSSL, quicTLS ou LibreSSL, com o NGINX. Para decidir qual é o melhor caminho para você, considere qual abordagem atende melhor aos seus requisitos e o quanto você se sente à vontade para compilar e gerenciar bibliotecas como dependências.
Uma observação sobre 0-RTT
O 0-RTT é um recurso do QUIC que permite que um cliente envie dados da aplicação antes que o handshake TLS seja concluído. A funcionalidade 0-RTT é viabilizada pela reutilização de parâmetros negociados em uma conexão anterior. Para isso, o cliente memoriza parâmetros essenciais e fornece ao servidor um tíquete de sessão TLS que permite recuperar as mesmas informações.
Embora esse recurso seja uma parte importante do QUIC, ele ainda não é compatível com a Camada de Compatibilidade do OpenSSL. Se você tiver casos de uso específicos que precisem de 0-RTT, agradecemos seus comentários para orientar nosso roteiro.
Saiba mais sobre o NGINX com QUIC+HTTP/3 e OpenSSL
Você pode começar a usar hoje mesmo a Camada de Compatibilidade com OpenSSL do NGINX com o NGINX Open Source ou iniciando uma avaliação gratuita de 30 dias do NGINX Plus. Esperamos que ela seja útil e agradecemos seus comentários.
Mais informações sobre o NGINX com QUIC+HTTP/3 e OpenSSL estão disponíveis nos recursos abaixo.
- Introdução à rede QUIC e à criptografia no NGINX
- Pacotes binários agora disponíveis para a implementação de prévia do NGINX QUIC+HTTP/3
- Nosso roteiro para oferecer suporte a QUIC e HTTP/3 no NGINX
- Apoiando o código aberto para um mundo mais seguro: F5 NGINX anuncia patrocínios ao Let’s Encrypt e ao OpenSSL
Sobre o autor
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.