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

Rick NelsonVice-président régional, ingénierie des solutions

NGINX et NGINX Plus offrent un certain nombre de fonctionnalités qui leur permettent de répondre à la plupart des exigences SSL/TLS. Ils s’appuient sur OpenSSL et sur la puissance des processeurs standard pour fournir des performances SSL/TLS à moindre coût. À mesure que la puissance des processeurs standard augmente et que les fabricants de puces intègrent la prise en charge de l’accélération cryptographique, l’avantage économique des processeurs standard par rapport aux puces SSL/TLS spécialisées continue également de se renforcer.

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

Déchargement SSL/TLS

Lorsque NGINX est utilisé comme proxy, il peut décharger les serveurs backend du traitement du déchiffrement SSL. Le déchiffrement au niveau du proxy présente plusieurs avantages :

• Amélioration des performances – Lors du déchiffrement SSL, c’est la négociation initiale qui pénalise le plus les performances. Pour améliorer celles-ci, le serveur chargé du déchiffrement met en cache les identifiants de session SSL et gère les tickets de session TLS. Si cette opération est effectuée au niveau du proxy, toutes les requêtes provenant d’un même client peuvent utiliser les valeurs mises en cache. Si elle est effectuée sur les serveurs backend, le client doit s’authentifier à nouveau chaque fois que ses requêtes sont dirigées vers un autre serveur. L’utilisation de tickets TLS peut contribuer à atténuer ce problème, mais ceux-ci ne sont pas pris en charge par tous les clients et peuvent être difficiles à configurer et à gérer.
• Meilleure utilisation des serveurs backend – Le traitement SSL/TLS sollicite fortement le processeur, et cette charge augmente à mesure que la taille des clés s’accroît. Décharger les serveurs backend de ce traitement leur permet de se concentrer sur ce qu’ils font le mieux : diffuser du contenu.
• Routage intelligent – En déchiffrant le trafic, le proxy accède au contenu de la requête, notamment aux en-têtes, à l’URI, etc., et peut utiliser ces données pour acheminer les requêtes.
• Gestion des certificats – Les certificats doivent uniquement être achetés et installés sur les serveurs proxy, et non sur tous les serveurs backend. 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 « Terminaison SSL NGINX » dans le Guide d’administration de NGINX Plus.

Chiffrement SSL/TLS vers les serveurs d’origine

Dans certains cas, vous pouvez avoir besoin que NGINX chiffre le trafic qu’il envoie aux serveurs backend. Ces requêtes peuvent parvenir au serveur NGINX en texte clair 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 persistantes aux serveurs backend réduit le nombre de négociations SSL/TLS et optimise ainsi les performances SSL/TLS. Pour ce faire, il suffit de configurer NGINX afin qu’il transmette les requêtes via « https » et chiffre ainsi automatiquement le trafic qui ne l’est pas déjà.

Chiffrement de bout en bout

Comme NGINX peut assurer à la fois le déchiffrement et le chiffrement, vous pouvez bénéficier d’un chiffrement de bout en bout pour toutes les requêtes, tout en permettant à NGINX de prendre des décisions de routage au niveau de la couche 7. Dans ce cas, les clients communiquent avec NGINX via HTTPS. NGINX déchiffre les requêtes, puis les chiffre à nouveau avant de les transmettre aux serveurs backend. Cette configuration peut être souhaitable lorsque le serveur proxy ne se trouve pas dans le même centre de données que les serveurs backend. À mesure que de plus en plus de serveurs migrent vers le cloud, l’utilisation de HTTPS entre un proxy et les serveurs backend devient de plus en plus nécessaire.

Certificats clients

NGINX peut gérer les certificats clients SSL/TLS et être configuré pour les rendre facultatifs ou obligatoires. Les certificats clients permettent de restreindre l’accès à vos systèmes aux seuls clients préalablement approuvés, sans exiger de mot de passe. Vous pouvez gérer les certificats en ajoutant les certificats révoqués à une liste de révocation de certificats (CRL), que NGINX consulte pour déterminer si un certificat client est toujours valide.

Fonctionnalités de sécurité supplémentaires

Un certain nombre d’autres fonctionnalités permettent de prendre en charge ces cas d’usage, notamment (sans toutefois s’y limiter) les suivantes :

• Certificats multiples – Une seule instance NGINX peut prendre en charge de nombreux certificats pour différents domaines et évoluer jusqu’à gérer des centaines de milliers de certificats. Il est courant qu’une instance NGINX desserve de nombreuses adresses IP et de nombreux domaines, chaque domaine nécessitant son propre certificat.
• Agrafage OCSP – Lorsque cette fonctionnalité est activée, NGINX inclut une réponse OCSP horodatée et signée par l’autorité de certification, que le client peut utiliser pour vérifier le certificat du serveur, évitant ainsi la baisse de performances liée à une communication directe avec le serveur OCSP.
• Chiffres de chiffrement SSL/TLS – Vous pouvez spécifier les chiffres de chiffrement à activer.
• 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 AC (autorité de certification), mais 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 reliant le certificat du site web à un certificat racine de confiance.
• Optimisations du serveur HTTPS – NGINX peut être réglé de manière à optimiser ses performances SSL/TLS en configurant le nombre de processus de travail, en utilisant des connexions persistantes et en recourant à un cache de sessions SSL/TLS.

Pour plus de détails, consultez ces ressources :

• Terminaison SSL NGINX dans le Guide d’administration de NGINX Plus
• Configuration des serveurs HTTPS sur nginx.org
• ngx_http_ssl_module documentation de référence sur nginx.org

Exemples

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

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

upstream backends {
    server 192.168.100.100:80;
    server 192.168.100.101:80;
}

server {
    listen      80;
    server_name www.example.com;

    location / {
        proxy_pass http://backends;
    }
}

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

upstream backends {
    server 192.168.100.100:80;
    server 192.168.100.101:80;
}

server {
    listen              80;
    listen              443 ssl; # 'ssl' parameter tells NGINX to decrypt the traffic
    server_name         www.example.com;
    ssl_certificate www.example.com.crt; # The certificate file
    ssl_certificate_key www.example.com.key; # The private key file
  

    location / {
        proxy_pass http://backends;
    }
}

Ou, si vous recevez plutôt le trafic via HTTP et l’envoyez aux serveurs backend via HTTPS :

upstream backends {
    server 192.168.100.100:443;
    server 192.168.100.101:443;
}

server {
    listen      80;
    server_name www.example.com;

    location / {
        proxy_pass https://backends; # 'https' prefix tells NGINX to encrypt the traffic
    }
}

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

À propos de l’auteur

Rick NelsonVice-président régional, ingénierie des solutions

Autres articles de Rick Nelson