Les développeurs souhaitent généralement créer des applications et des infrastructures à l’aide de bibliothèques publiées, officielles et prises en charge. Même avec HTTP/3, il existe un réel besoin d’une bibliothèque pratique prenant en charge QUIC sans augmenter les coûts de maintenance ni la complexité opérationnelle de l’infrastructure de production.
Pour de nombreux utilisateurs de QUIC+HTTP/3, la bibliothèque cryptographique par défaut est OpenSSL. Installée par défaut sur la plupart des systèmes d’exploitation basés sur Linux, OpenSSL est la principale bibliothèque de sécurité de la couche de transport (TLS) et est utilisée par la majorité des applications réseau.
Le problème : l’incompatibilité entre OpenSSL et QUIC+HTTP/3
Malgré son utilisation très répandue, OpenSSL ne fournit pas l’API TLS nécessaire à la prise en charge de QUIC. Le comité de gestion d’OpenSSL a plutôt décidé de développer lui-même une pile QUIC complète. Ce projet représente un travail considérable prévu pour OpenSSL v3.4, mais d’après la feuille de route d’OpenSSL, cela ne devrait vraisemblablement pas se concrétiser avant la fin de l’année 2024. En outre, la première version minimale viable de l’implémentation d’OpenSSL n’inclura pas l’API QUIC. Il n’existe donc aucune solution clairement définie permettant aux utilisateurs de bénéficier de la prise en charge de HTTP/3 avec OpenSSL.
Options de prise en charge de TLS pour QUIC
Dans cette situation, les utilisateurs à la recherche d’une prise en charge de QUIC TLS pour leurs besoins en HTTP/3 disposent de deux options :
- Implémentation QUIC d’OpenSSL – Comme indiqué précédemment, OpenSSL travaille actuellement à la mise en œuvre de sa propre pile QUIC complète. Cette évolution intégrera toutes les fonctionnalités QUIC au sein de l’implémentation, ce qui permettra aux utilisateurs de HTTP/3 d’utiliser beaucoup plus facilement l’API TLS d’OpenSSL sans avoir à se soucier des fonctionnalités propres à QUIC.
- Bibliothèques prenant en charge l’API QUIC de BoringSSL – Diverses bibliothèques SSL telles que BoringSSL, quicTLS et LibreSSL (toutes initialement dérivées d’OpenSSL) proposent désormais des fonctionnalités QUIC TLS en implémentant l’API QUIC de BoringSSL. Cependant, ces bibliothèques ne sont pas aussi largement adoptées qu’OpenSSL. Cette solution nécessite également de compiler la bibliothèque SSL à partir du code source et de l’installer sur chaque serveur devant prendre en charge QUIC+HTTP/3, ce qui n’est pas forcément envisageable pour tout le monde. Cela dit, il s’agit actuellement de la seule solution pour les utilisateurs souhaitant utiliser HTTP/3, car l’implémentation QUIC TLS d’OpenSSL n’est pas encore prête.
Une nouvelle solution : la couche de compatibilité OpenSSL
Chez NGINX, ces défis nous ont inspirés à créer la couche de compatibilité OpenSSL afin de simplifier les déploiements QUIC+HTTP/3 utilisant OpenSSL et d’éviter les difficultés liées à la maintenance d’une bibliothèque SSL distincte dans les environnements de production.
Disponible avec NGINX Open Source mainline depuis la version 1.25.0 et NGINX Plus R30, la couche de compatibilité OpenSSL permet à NGINX d’exécuter QUIC+HTTP/3 sur OpenSSL sans avoir à appliquer de correctif ni à le recompiler. Il n’est ainsi plus nécessaire de compiler et de déployer des bibliothèques TLS tierces pour bénéficier de la prise en charge de QUIC. Comme les utilisateurs n’ont pas besoin de recourir à des bibliothèques tierces, ils ne dépendent plus non plus des calendriers et des feuilles de route de ces bibliothèques, ce qui en fait une solution relativement plus facile à déployer en production.
Fonctionnement de la couche de compatibilité OpenSSL
La couche de compatibilité OpenSSL met en œuvre les étapes suivantes :
- Convertit une négociation QUIC en une négociation TLS 1.3 prise en charge par OpenSSL.
- Transmet les messages de négociation TLS à OpenSSL et récupère ceux qu’il renvoie.
- Récupère auprès d’OpenSSL les clés de chiffrement pour les niveaux de chiffrement de la négociation et de l’application.
- Transmet les paramètres de transport QUIC à OpenSSL et les récupère depuis celui-ci.
Compte tenu du niveau d’adoption actuel d’OpenSSL et de l’état de sa prise en charge officielle de QUIC+HTTP/3, nous pensons que proposer une option simple et évolutive pour activer QUIC constitue un pas dans la bonne direction. Cela favorisera également l’adoption de HTTP/3 et permettra de recueillir de précieux retours. Surtout, nous sommes convaincus que la couche de compatibilité OpenSSL nous aidera à fournir une solution plus robuste et évolutive à nos utilisateurs professionnels ainsi qu’à l’ensemble de la communauté NGINX.
Remarque: bien que nous veillions à offrir aux utilisateurs de NGINX une solution simple et évolutive grâce à la couche de compatibilité OpenSSL, ils peuvent toujours utiliser des bibliothèques tierces telles que BoringSSL, quicTLS ou LibreSSL avec NGINX. Pour déterminer la solution qui vous convient le mieux, réfléchissez à l’approche qui répond le mieux à vos besoins et à votre aisance à compiler et à gérer des bibliothèques en tant que dépendances.
Remarque sur le 0-RTT
Le 0-RTT est une fonctionnalité de QUIC qui permet à un client d’envoyer des données applicatives avant la fin de la négociation TLS. Le fonctionnement du 0-RTT repose sur la réutilisation de paramètres négociés lors d’une connexion précédente. Pour ce faire, le client mémorise les paramètres essentiels et fournit au serveur un ticket de session TLS lui permettant de récupérer les mêmes informations.
Bien que cette fonctionnalité soit un élément important de QUIC, elle n’est pas encore prise en charge par la couche de compatibilité OpenSSL. Si vous avez des cas d’utilisation spécifiques nécessitant le 0-RTT, n’hésitez pas à nous faire part de vos commentaires afin de nous aider à définir notre feuille de route.
En savoir plus sur NGINX avec QUIC+HTTP/3 et OpenSSL
Vous pouvez commencer à utiliser dès aujourd’hui la couche de compatibilité OpenSSL de NGINX avec NGINX Open Source ou en démarrant un essai gratuit de 30 jours de NGINX Plus. Nous espérons qu’elle vous sera utile et vos commentaires sont les bienvenus.
Vous trouverez davantage d’informations sur NGINX avec QUIC+HTTP/3 et OpenSSL dans les ressources ci-dessous.
- Introduction à la mise en réseau QUIC et au chiffrement dans NGINX
- Des paquets binaires sont désormais disponibles pour la version préliminaire de l’implémentation QUIC+HTTP/3 de NGINX
- Notre feuille de route pour la prise en charge de QUIC et HTTP/3 dans NGINX
- Soutenir l’open source pour un monde plus sûr : F5 NGINX annonce son parrainage de Let’s Encrypt et d’OpenSSL
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.