Déchargement SSL/TLS, cryptage et certificats avec NGINX et NGINX Plus

NGINX et NGINX Plus fournissent un certain nombre de fonctionnalités qui lui permettent de gérer la plupart des exigences SSL/TLS. Ils utilisent OpenSSL et la puissance des puces de processeur standard pour fournir des performances SSL/TLS rentables. À mesure que la puissance des puces de processeur standard continue d’augmenter et que les fournisseurs de puces ajoutent la prise en charge de l’accélération cryptographique, l’avantage de coût de l’utilisation de puces de processeur standard par rapport aux puces SSL/TLS spécialisées continue également de s’élargir.

Il existe trois principaux cas d’utilisation pour NGINX et NGINX Plus avec SSL/TLS.

Déchargement SSL/TLS

Lorsque NGINX est utilisé comme proxy, il peut décharger le traitement de décryptage SSL des serveurs back-end. Le décryptage au niveau du proxy présente de nombreux avantages :

• Amélioration des performances – L’impact le plus important sur les performances lors du décryptage SSL est la négociation initiale. Pour améliorer les performances, le serveur effectuant le déchiffrement met en cache les identifiants de session SSL et gère les tickets de session TLS. Si cela est fait au niveau du proxy, toutes les requêtes du même client peuvent utiliser les valeurs mises en cache. Si cela est fait sur les serveurs back-end, chaque fois que les requêtes du client sont envoyées à un serveur différent, le client doit s’authentifier à nouveau. L’utilisation de tickets TLS peut aider à atténuer ce problème, mais ils ne sont pas pris en charge par tous les clients et peuvent être difficiles à configurer et à gérer.
• Meilleure utilisation des serveurs back-end – Le traitement SSL/TLS est très gourmand en ressources CPU et devient de plus en plus intensif à mesure que la taille des clés augmente. En supprimant cette tâche des serveurs back-end, ils peuvent se concentrer sur ce qu’ils font le plus efficacement : diffuser du contenu.
• Routage intelligent – En déchiffrant le trafic, le proxy a accès au contenu de la requête, comme les en-têtes, l'URI, etc., et peut utiliser ces données pour acheminer les requêtes.
• Gestion des certificats – Les certificats ne doivent être achetés et installés que sur les serveurs proxy et non sur tous les serveurs principaux. Cela permet d’économiser du temps et de l’argent.
• Correctifs de sécurité – Si des vulnérabilités apparaissent dans la pile SSL/TLS, les correctifs appropriés doivent être appliqués uniquement aux serveurs proxy.

Pour plus de détails, consultez la section Terminaison SSL NGINX dans le Guide d'administration NGINX Plus.

Cryptage SSL/TLS vers les serveurs d'origine

Il peut arriver que vous ayez besoin de NGINX pour crypter le trafic qu'il envoie aux serveurs back-end. Ces requêtes peuvent arriver au serveur NGINX sous forme de texte brut ou sous forme de trafic chiffré que NGINX doit déchiffrer afin de prendre une décision de routage.  L'utilisation d'un pool de connexions keepalive aux serveurs backend minimise le nombre de connexions SSL/TLS et maximise ainsi les performances SSL/TLS. Cela se fait très simplement en configurant NGINX pour qu'il utilise un proxy sur « https » afin qu'il crypte automatiquement le trafic qui n'est pas déjà crypté.

Chiffrement de bout en bout

Étant donné que NGINX peut effectuer à la fois le déchiffrement et le chiffrement, vous pouvez obtenir un chiffrement de bout en bout de toutes les requêtes, NGINX prenant toujours les décisions de routage de couche 7. Dans ce cas, les clients communiquent avec NGINX via HTTPS, et il décrypte les requêtes puis les recrypte avant de les envoyer aux serveurs backend. Cela peut être souhaitable lorsque le serveur proxy n'est pas colocalisé dans un centre de données avec les serveurs principaux. Alors que de plus en plus de serveurs sont déplacés vers le cloud, il devient de plus en plus nécessaire d'utiliser HTTPS entre un proxy et les serveurs back-end.

Certificats clients

NGINX peut gérer les certificats clients SSL/TLS et peut être configuré pour les rendre facultatifs ou obligatoires . Les certificats clients sont un moyen de restreindre l'accès à vos systèmes aux seuls clients pré-approuvés sans nécessiter de mot de passe, et vous pouvez contrôler les certificats en ajoutant des certificats révoqués à une liste de révocation de certificats (CRL), que NGINX vérifie pour déterminer si un certificat client est toujours valide.

Fonctionnalités de sécurité supplémentaires

Il existe un certain nombre d'autres fonctionnalités qui aident à prendre en charge ces cas d'utilisation, notamment (mais sans s'y limiter) les suivantes :

• Certificats multiples – Une seule instance NGINX peut prendre en charge de nombreux certificats pour différents domaines et peut évoluer jusqu'à prendre en charge des centaines de milliers de certificats. Il s’agit d’un cas d’utilisation courant d’avoir une instance NGINX servant de nombreuses adresses IP et domaines, chaque domaine nécessitant son propre certificat.
• Agrafage OCSP – Lorsque cette option est activée, NGINX inclut une réponse OCSP horodatée signée par l'autorité de certification que le client peut utiliser pour vérifier le certificat du serveur, évitant ainsi la pénalité de performances liée au contact direct avec le serveur OCSP.
• Chiffres SSL/TLS – Vous pouvez spécifier quels chiffrements sont activés.
• Protocoles SSL/TLS – Vous pouvez spécifier les protocoles activés, notamment SSLv2, SSLv3, TLSv1, TLSv1.1 et TLSv1.2.
• Certificats chaînés – NGINX prend en charge les chaînes de certificats , utilisées lorsque le certificat du site Web n'est pas signé directement par le certificat racine d'une CA (Certificate Authority), mais plutôt par une série de certificats intermédiaires. Le serveur Web présente une « chaîne de certificats » contenant les certificats intermédiaires, afin que le client Web puisse vérifier la chaîne de confiance qui relie le certificat du site Web à un certificat racine de confiance.
• Optimisations du serveur HTTPS – NGINX peut être réglé pour maximiser ses performances SSL/TLS en configurant le nombre de processus de travail, en utilisant des connexions keepalive et en utilisant un cache de session SSL/TLS.

Pour plus de détails, consultez ces ressources :

• Résiliation SSL NGINX dans le guide d'administration NGINX Plus
• Configuration des serveurs HTTPS sur nginx.org
• Documentation de référence de ngx_http_ssl_module sur nginx.org

Exemples

Voici quelques exemples de fonctionnalités de sécurité de NGINX. Ces exemples supposent une compréhension de base de la configuration NGINX.

La configuration suivante gère le trafic HTTP pour www.example.com et le transmet à un groupe en amont :

backends en amont {
serveur 192.168.100.100:80;
serveur 192.168.100.101:80;
}

serveur {
écoute 80;
nom_serveur www.exemple.com;

emplacement / {
pass_proxy http://backends;
}
}

Ajoutez maintenant la prise en charge HTTPS, afin que NGINX déchiffre le trafic à l'aide du certificat et de la clé privée et communique avec les serveurs back-end via HTTP :

backends en amont { server 192.168.100.100:80; server 192.168.100.101:80; } server { listen 80; listen 443 ssl ; # Le paramètre 'ssl' indique à NGINX de décrypter le trafic server_name www.example.com; ssl_certificate www.example.com.crt ; # Le fichier de certificat ssl_certificate_key www.example.com.key ; # L'emplacement du fichier de clé privée / { proxy_pass http://backends; } }

Ou si vous recevez plutôt du trafic via HTTP et l'envoyez aux serveurs backend via HTTPS :

backends en amont { serveur 192.168.100.100:443; serveur 192.168.100.101:443; } serveur { écoute 80; nom_serveur www.exemple.com; emplacement / { proxy_pass https ://backends; # Le préfixe 'https' indique à NGINX de crypter le trafic } }

Pour essayer NGINX Plus, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation.