Quand un site passe sous HTTPS, beaucoup s’arrêtent à l’obtention du certificat SSL et au fameux cadenas dans le navigateur. Pourtant, la vraie différence entre un serveur « juste chiffré » et un serveur réellement robuste se joue dans quelques lignes de configuration Nginx : choix des protocoles TLS, directive ssl_ciphers, gestion des tickets de session et des paramètres Diffie-Hellman.
Depuis la généralisation de TLS 1.3 et la dépréciation officielle de TLS 1.0/1.1, laisser la configuration par défaut revient souvent à rouvrir des portes que l’on croyait fermées depuis longtemps.
Pour une PME, un hébergeur ou une équipe produit, la question n’est plus seulement « mon site est-il en HTTPS ? », mais « ma pile TLS résiste-t-elle aux scanners automatiques, aux faiblesses connues et aux audits A+ type SSL Labs ? ». Un serveur Nginx fraîchement installé accepte parfois encore des méthodes HTTP inutiles, expose sa version, et s’appuie sur des réglages OpenSSL génériques.
Le durcissement (« hardening ») consiste à reprendre la main : forcer TLS 1.2 et 1.3, bannir les suites faibles, ajouter des en-têtes de sécurité, limiter les méthodes et serrer les timeouts. Le tout sans casser les navigateurs clients raisonnablement récents, ni les applications mobiles en production. L’enjeu est double : réduire la surface d’attaque, mais aussi prouver à un client, à un DSI ou à un auditeur que le serveur ne se contente pas de suivre la mode du chiffrement, il applique un protocole sécurisé cohérent avec 2026.
- Forcer TLS 1.2 et TLS 1.3 et désactiver TLS 1.0/1.1 pour rester aligné sur les recommandations actuelles.
- Contrôler ssl_ciphers dans Nginx avec un profil de durcissement type Mozilla Intermediate.
- Désactiver les tickets de session et générer des paramètres Diffie-Hellman solides si DHE est utilisé.
- Ajouter HSTS et les en-têtes de sécurité pour bloquer un ensemble d’attaques côté navigateur.
- Tester systématiquement la configuration HTTPS avec testssl.sh, SSL Labs et openssl s_client.
Pourquoi la configuration TLS 1.3 dans Nginx ne peut plus se limiter à activer HTTPS
La plupart des équipes se rendent compte de la question TLS quand un scanner remonte un « TLS 1.0 still enabled » ou un « weak cipher suite detected ». C’est exactement ce qui est arrivé à une coopérative agricole qui exposait ses dashboards IoT via Nginx.
Le trafic passait bien en HTTPS, mais le test de conformité PCI a pointé la présence de TLS 1.0 et de suites non GCM. Résultat : obligation de corriger dans l’urgence, en pleine période de récolte, alors que tout cela aurait pu être réglé calmement lors de l’installation initiale.
Les protocoles TLS 1.0 (1999) et TLS 1.1 (2006) traînent une longue liste de faiblesses documentées : attaques BEAST, POODLE, Lucky13, pour ne citer que les plus connues. Depuis la RFC 8996, ces versions sont officiellement dépréciées. Les grandes plateformes de paiement ont d’ailleurs acté leur désactivation dès 2018, dans le cadre de PCI DSS. Garder ces protocoles activés aujourd’hui, c’est un peu comme laisser un vieux modem analogique branché sur le réseau interne : ce n’est pas forcément exploité tous les jours, mais quand quelqu’un se donne la peine de chercher, l’exposition est bien là.
Du côté client, la bascule est déjà faite. Les versions modernes de Chrome, Firefox, Edge et Safari ont coupé TLS 1.0/1.1 depuis plusieurs années. Les derniers environnements qui s’y accrochent sont des systèmes vieillissants : vieilles versions d’Android, Internet Explorer, runtimes Java non mis à jour. Sur la plupart des sites, ces clients représentent bien moins de 1 % du trafic. Continuer à supporter cette frange marginale en sacrifiant la sécurité générale n’a plus beaucoup de sens, sauf cas métier très particulier et assumé.
La bonne pratique consiste donc à limiter Nginx à TLS 1.2 et TLS 1.3. TLS 1.2 reste le socle compatible avec un large parc de clients, tant que les ssl_ciphers se limitent aux suites modernes (AES-GCM, CHACHA20-POLY1305 avec ECDHE ou DHE). TLS 1.3, standardisé en 2018, change la donne : négociation plus courte, moins de paramètres, forward secrecy généralisée et surtout disparition de tous les chiffrement hérités type CBC vulnérables. Nginx s’aligne sur cette logique en gérant les suites TLS 1.3 via la bibliothèque OpenSSL, sans passer par la directive ssl_ciphers.
D’ailleurs, la mise à jour de Nginx elle-même devient un élément du durcissement. Un bug comme CVE-2026-1642, qui a touché la gestion TLS upstream, rappelle que la couche HTTPS ne se limite pas au choix du protocole, mais dépend aussi de la version exacte du serveur. Une commande simple comme nginx -v permet de vérifier en un coup d’œil si la version utilisée intègre les correctifs récents. Couplée à quelques commandes Linux de base, cette vérification fait gagner du temps lors d’un audit ou d’un incident.
Le vrai enjeu pour une équipe technique consiste à sortir du « ça marche en HTTPS » pour aller vers « ce serveur applique un profil TLS documenté, reproductible et testé ». C’est cette bascule qui prépare la suite : générique de durcissement Nginx, en-têtes, limitations, et éventuellement WAF ou load balancing. Une fois cette étape comprise, la directive ssl_ciphers cesse d’être une ligne obscure pour devenir un levier de pilotage fin de la surface d’attaque.
De TLS 1.2 à TLS 1.3 : ce que Nginx gère différemment dans la négociation
Entre TLS 1.2 et TLS 1.3, la différence la plus visible côté architecture reste le nombre d’allers-retours nécessaires pour établir une session : deux tours pour TLS 1.2, un seul pour TLS 1.3. Sur une usine connectée avec des capteurs qui dialoguent fréquemment avec une API Nginx, cette réduction du handshake se traduit par moins de latence, moins de CPU passé à négocier et plus de capacité disponible pour traiter la logique métier.
Un second changement tient dans la place laissée à la configuration locale. Sous TLS 1.2, la liste des ssl_ciphers a encore un impact direct sur la sécurité effective. Laisser un « HIGH:!aNULL:!MD5 » générique s’appuie sur la sélection d’OpenSSL, ce qui n’est pas toujours idéal. Sous TLS 1.3, en revanche, les suites négociées sont standardisées (AES_256_GCM, AES_128_GCM, CHACHA20_POLY1305) et la plupart des implémentations n’autorisent plus les compromis historiques.
Au passage, l’activation de TLS 1.3 dans Nginx impose un socle technique minimal : version de Nginx suffisante, OpenSSL au moins en 1.1.1, parfois des options de compilation spécifiques sur des distributions anciennes. Une commande comme openssl version, combinée à nginx -V, permet de vérifier très vite si l’environnement supporte réellement le protocole annoncé dans la documentation.
La morale pour un responsable d’infrastructure est simple : la ligne ssl_protocols dans un fichier Nginx ne suffit pas si la couche OpenSSL sous-jacente n’est pas à jour. Autant vérifier et mettre à niveau avant de se lancer dans un durcissement plus large.
Configurer ssl_protocols et ssl_ciphers dans Nginx pour un durcissement TLS 1.2 / 1.3
Le cœur du sujet se trouve dans deux directives Nginx : ssl_protocols et ssl_ciphers. La première borne les versions de TLS que le serveur accepte, la seconde limite les suites cryptographiques autorisées pour les protocoles qui dépendent encore de cette liste (TLS 1.2 en pratique). Une approche pragmatique consiste à s’aligner sur le profil Intermediate publié par Mozilla, qui offre un compromis solide entre sécurité et compatibilité clients.
Concrètement, dans un fichier d’inclusion du type /etc/nginx/snippets/security-hardening.conf, on retrouve une ligne ssl_protocols TLSv1.2 TLSv1.3;. Cette simple déclaration coupe net TLS 1.0 et 1.1, tout en laissant passer les navigateurs et API capables de parler TLS 1.2 ou 1.3. Les cas d’usage purement internes très récents peuvent aller plus loin en choisissant uniquement TLSv1.3, mais cela exclut encore quelques clients industriels et piles embarquées qui ne sont pas toutes au niveau.
La directive ssl_ciphers se remplit alors avec une liste explicite de suites, par exemple ECDHE-ECDSA-AES128-GCM-SHA256 ou ECDHE-RSA-CHACHA20-POLY1305. L’important n’est pas de mémoriser chaque acronyme, mais de comprendre la structure : ECDHE ou DHE pour la négociation de clé, AES-GCM ou CHACHA20-POLY1305 pour le chiffrement authentifié, SHA256 ou SHA384 pour l’empreinte. L’absence de suites CBC dans cette liste n’est pas un hasard, c’est ce qui évite une bonne partie des attaques historiques.
On voit souvent la question de ssl_prefer_server_ciphers. Dans un monde où seules des suites robustes sont proposées, laisser cette option à off et donc laisser le client choisir le chiffrement lui convient souvent mieux. Les navigateurs modernes savent exploiter les accélérations matérielles de leurs plateformes. Un smartphone avec un CPU ARM récent négociera volontiers CHACHA20 plus économique, là où un serveur x86 avec AES-NI préférera AES-GCM. Forcer la préférence du serveur n’apporte pas forcément de gain lorsqu’on a déjà filtré tous les choix douteux.
Les paramètres Diffie-Hellman (directive ssl_dhparam) restent utiles si des suites DHE sont gardées dans la liste pour compatibilité. Un fichier généré avec openssl dhparam -out /etc/nginx/dhparam.pem 2048 suffit pour remonter au-dessus des valeurs par défaut vieillissantes. Pour des environnements entièrement modernes, rester sur ECDHE et retirer les suites DHE simplifie encore la configuration.
Pour les équipes qui préfèrent une base de départ générée, l’outil en ligne de Mozilla SSL Configuration Generator produit une configuration adaptée à la version exacte de Nginx et d’OpenSSL. L’important reste de ne pas coller le résultat aveuglément, mais de le relire, de le tester, et de vérifier sa cohérence avec le reste du durcissement Nginx déjà en place.
| Profil TLS Nginx | Protocoles activés | Clients typiques | Usage recommandé |
|---|---|---|---|
| Modern | TLS 1.3 uniquement | Navigateurs récents, API mobiles à jour | Services internes, applications B2B modernes |
| Intermediate | TLS 1.2 et TLS 1.3 | Parc hétérogène, Android 4.4 et plus | Sites publics, portails clients, API exposées |
| Legacy | TLS 1.0 / 1.1 / 1.2 / 1.3 | Environnements très anciens, IE sur vieux Windows | Cas contraints uniquement, segmentés et surveillés |
Pour une PME qui héberge plusieurs sites sur un même VPS, l’astuce pratique consiste à regrouper tout ce durcissement TLS dans un snippet unique, puis à l’inclure dans chaque bloc server qui expose du HTTPS. Cela évite l’erreur fréquente du « site principal bien durci, sous-domaine API laissé par défaut ». Un simple include /etc/nginx/snippets/security-hardening.conf; dans chaque vhost garantit une base cohérente, quitte à ajuster ensuite quelques détails par site.
Dernier point trop souvent oublié : chaque changement de cipher ou de protocole doit être suivi d’un test. Un passage par un outil comme ce guide de test de configuration Nginx aide à valider que la syntaxe est correcte, avant même de lancer un reload système. Ensuite, des requêtes openssl s_client ou testssl.sh vérifient ce que le serveur accepte réellement, pas seulement ce que le fichier de configuration prétend afficher.
HSTS, en-têtes de sécurité et HTTPS : compléter le travail de chiffrement
Une fois la négociation TLS durcie, beaucoup de serveurs Nginx continuent malgré tout à accepter des connexions HTTP en clair, au moins pour la première requête. Un attaquant qui se trouve sur le même réseau que l’utilisateur peut alors intercepter cette requête et tenter un downgrade, ou injecter du contenu avant la redirection vers HTTPS. C’est justement ce que les navigateurs cherchent à éviter avec l’en-tête HSTS (HTTP Strict Transport Security).
Un simple add_header Strict-Transport-Security « max-age=63072000; includeSubDomains » always; indique au navigateur de considérer que le domaine ne doit plus jamais être joint qu’en HTTPS pendant la période définie. Tant que max-age n’est pas expiré, toute tentative de connexion en HTTP est remplacée localement par une connexion sécurisée. Ce mécanisme casse une bonne partie des attaques de type « SSL stripping », encore parfois observées sur des Wi-Fi publics peu filtrés.
Autour de HSTS, quatre autres en-têtes méritent systématiquement leur place dans une configuration Nginx qui se veut sérieuse : X-Content-Type-Options pour empêcher le sniffing de types MIME, X-Frame-Options pour limiter l’inclusion en iframe, une Content-Security-Policy raisonnablement stricte pour contrôler les sources de scripts et de contenus, et enfin une Referrer-Policy pour maîtriser ce que le navigateur divulgue lorsqu’il navigue vers un tiers.
Un exemple concret de CSP pourrait ressembler à « default-src ‘self’; script-src ‘self’; img-src ‘self’ data:; » sur un site vitrine classique. Sur une application plus riche qui charge des scripts depuis un CDN, il faudra ajouter ce domaine explicitement. Au début, l’en-tête génère souvent des avertissements dans la console développeur du navigateur, ce qui permet de l’ajuster progressivement au lieu de lâcher d’emblée une politique trop permissive.
Dans les usines ou les plateformes IoT, ces en-têtes prennent une dimension particulière : ils limitent les dégâts si un script ou une bibliothèque front-end se retrouve compromis. Là où le serveur Nginx empêche l’écoute et le détournement du trafic via TLS, les en-têtes empêchent la page elle-même de devenir une porte d’entrée pour du code malveillant exécuté côté navigateur.
Une attention particulière doit être portée aux interactions entre les blocs server et les blocs location dans Nginx. Dès qu’un bloc location définit ses propres add_header, Nginx oublie ceux définis au niveau supérieur, sauf si l’on exploite les mécanismes d’héritage prévus dans les versions récentes ou si l’on répète le snippet dans chaque bloc concerné. Sans cette vigilance, il n’est pas rare de découvrir qu’une API ou un sous-chemin critiques sont servis sans aucun des en-têtes de sécurité laborieusement mis en place ailleurs.
Limitation des méthodes HTTP et protection des zones sensibles
Une configuration HTTPS bien chiffrée n’empêche pas un attaquant de jouer avec les méthodes HTTP disponibles. Sur un serveur Nginx, laisser passer TRACE, PUT ou DELETE sur des ressources qui n’en ont aucun usage revient à proposer une série de leviers supplémentaires. TRACE permet notamment des attaques de type XST (cross-site tracing) où les cookies et tokens sont renvoyés tels quels dans la réponse, ce qui n’a guère d’intérêt pour un site sérieux.
Limiter les méthodes au strict nécessaire se fait simplement avec limit_except dans les blocs location. Autoriser uniquement GET et POST (HEAD étant implicitement accepté avec GET) couvre 95 % des usages courants. Les autres méthodes renvoient alors un 403 ou 405, ce qui a un effet dissuasif intéressant sur les scanners automatisés qui testent un large éventail de verbes HTTP dans l’espoir de tomber sur une configuration laxiste.
Les sections d’administration et les tableaux de bord méritent, en plus, des restrictions d’accès par IP ou par VPN. Les directives allow et deny de Nginx, bien utilisées, ajoutent une barrière supplémentaire qui vient compléter l’authentification applicative. Cela ne remplace pas un contrôle d’accès solide côté application, mais réduit les dégâts si un mot de passe admin fuite quelque part.
En pratique, cette combinaison de HTTPS durci, d’en-têtes soignés, de méthodes limitées et d’ACL simples suffit à transformer un serveur Nginx de base en point d’entrée beaucoup plus difficile à exploiter. Ce n’est pas la panacée, mais c’est un socle robuste sur lequel on peut ensuite brancher un WAF, des règles de rate limiting ou une architecture de load balancer Nginx plus avancée.
Sessions TLS, tickets, paramètres DH : les détails qui comptent pour la sécurité HTTPS
Une fois les protocoles et les suites de chiffrement calés, la configuration TLS de Nginx repose encore sur trois blocs de réglages souvent sous-estimés : la gestion des sessions, les tickets, et les paramètres Diffie-Hellman lorsque des suites DHE sont encore présentes. Chacun de ces points a un impact direct sur la réutilisation des connexions, la confidentialité dans le temps et la résistance à des compromissions futures.
Les directives ssl_session_timeout et ssl_session_cache déterminent la durée et la portée de la réutilisation de sessions TLS déjà établies. Une valeur raisonnable comme une journée de validité, avec un cache partagé de quelques dizaines de mégaoctets, suffit pour la plupart des serveurs qui n’ont pas des millions de connexions simultanées. L’objectif est de limiter le coût de la négociation TLS tout en évitant que des sessions restent vivantes indéfiniment.
La directive ssl_session_tickets attire plus d’attention dans un contexte de durcissement sérieux. Quand les tickets sont activés, le serveur chiffre les informations de session avec une clé de ticket globale. Si, par malheur, cette clé venait à être compromise, un attaquant pourrait déchiffrer les sessions passées restées en mémoire. Dans un environnement à un ou deux serveurs, désactiver les tickets au profit du cache de session local rend ce scénario beaucoup moins intéressant pour un attaquant, tout en gardant un bon niveau de performance.
Les paramètres Diffie-Hellman, gérés via ssl_dhparam, restent utiles si l’on conserve des suites DHE à côté des ECDHE. Générer un fichier de 2 048 bits demande quelques minutes, mais cette étape n’a à être effectuée qu’une seule fois par serveur. À l’inverse, négliger ces paramètres et rester sur des valeurs par défaut vieillissantes peut se retrouver pointé en rouge par des tests comme SSL Labs ou testssl.sh.
Pour la plupart des équipes, un modèle simple fonctionne bien : ECDHE comme choix principal, DHE conservé seulement si l’on a la preuve qu’un client légitime en a besoin, ssl_session_tickets off, un cache de session modéré et un fichier dhparam généré et documenté dans la CMDB ou l’outil de gestion de configuration utilisé. Ce schéma est facilement industrialisable et ne dépend pas d’astuces spécifiques à une distribution donnée.
Buffers, timeouts et gestion des requêtes lentes en HTTPS
La sécurisation TLS ne concerne pas uniquement le chiffrement, mais aussi la manière dont Nginx accepte et traite les requêtes, en particulier sous HTTPS où chaque connexion consomme un peu plus de ressources. Des attaques de type « slow loris » ou des POST extrêmement lents peuvent saturer les workers si les timeouts restent trop généreux et les buffers trop larges.
Des directives comme client_max_body_size, client_body_buffer_size, large_client_header_buffers et les trois timeouts client_header_timeout, client_body_timeout, send_timeout permettent de borner l’impact de chaque connexion. Fixer une limite par défaut à 10 Mo pour le corps de requête suffit largement pour les formulaires classiques et évite de laisser un attaquant tenter un upload gigantesque sans filtre.
Réduire légèrement les temps d’attente pour les en-têtes et le corps (une trentaine de secondes par exemple) coupe court aux connexions qui se trainent volontairement. Cela ne dispense pas d’un pare-feu ou de solutions de mitigation DDoS en amont pour les attaques plus massives, mais protège efficacement contre une bonne partie des scripts opportunistes qui s’en prennent aux configurations Nginx par défaut.
Avec ces réglages, un serveur Nginx correctement dimensionné et HTTPS durci encaisse beaucoup mieux les pics de trafic ou les tentatives de « test de charge » improvisés venant de l’extérieur. Ce n’est pas spectaculaire, mais c’est souvent cette absence d’effet de bord qui fait la différence lors d’une montée en charge réelle.
Tester, auditer et faire évoluer sa configuration Nginx ssl_ciphers dans le temps
Un des pièges les plus fréquents en matière de SSL/TLS consiste à considérer la configuration comme un exercice ponctuel. En pratique, la surface d’attaque autour de TLS évolue : nouvelles failles théoriques, recommandations mises à jour, et surtout changements fréquents dans les politiques des navigateurs et des plateformes de paiement. Un serveur Nginx qui affichait fièrement un A+ sur SSL Labs il y a trois ans peut se retrouver rétrogradé à B ou C sans aucun changement local, uniquement parce que les critères ont été resserrés.
Pour garder la main, il devient utile de ritualiser le test. Un script périodique qui lance testssl.sh sur les principaux domaines, un passage régulier par SSL Labs, et quelques commandes openssl s_client ciblées suffisent à détecter les dérives : réactivation accidentelle de TLS 1.0 sur un vhost, ajout d’une suite de chiffrement faible par copie d’un exemple ancien, ou oubli d’un en-tête HSTS sur un nouveau sous-domaine. L’idée n’est pas de transformer chaque semaine en audit complet, mais d’intégrer ces vérifications dans la routine d’exploitation.
Les tableaux de bord d’observabilité aident aussi. Sur un cluster Nginx qui fait office de reverse proxy pour plusieurs applications, suivre la répartition des versions de TLS négociées donne une bonne idée de l’état du parc client. Quand la part de TLS 1.2 descend en dessous d’un certain seuil, la question de basculer vers un profil « Modern » uniquement TLS 1.3 se pose naturellement, sans dogme, simplement parce que les chiffres l’y invitent.
Une autre dimension à surveiller reste la version des bibliothèques cryptographiques. Un nginx -V qui révèle encore un OpenSSL ancien mérite une mise à jour planifiée, même si tout semble fonctionner. Les annonces de CVE récentes montrent que la robustesse du chiffrement dépend autant de la mathématique sous-jacente que de l’implémentation concrète. Réduire l’écart entre sa version de production et la version supportée par la distribution reste une bonne pratique simple et peu coûteuse.
Enfin, pour les environnements plus structurés, documenter les choix TLS comme n’importe quel autre paramètre d’architecture évite les décisions impulsives. Expliquer pourquoi tel profil ssl_ciphers a été retenu, sur quels critères métiers certains clients legacy ont été conservés ou exclus, et comment sont gérées les évolutions futures, permet de répondre sans stress à un audit, à une demande de client grand compte ou à une nouvelle exigence réglementaire.
Cas pratique : une PME qui passe de « HTTPS par défaut » à « HTTPS durci »
Imaginons une petite entreprise de mécanique de précision qui expose à ses clients un portail de suivi de commandes, hébergé sur un VPS avec Nginx. Au départ, le prestataire a activé le HTTPS avec Let’s Encrypt, mais a laissé la configuration TLS par défaut. Lors d’un appel d’offres avec un industriel plus gros, un audit de sécurité est demandé, et le rapport remonte : présence de TLS 1.0, absence de HSTS, en-têtes de protection manquants.
Le chantier se déroule alors en plusieurs étapes simples. D’abord, création d’un snippet de durcissement regroupant ssl_protocols TLSv1.2 TLSv1.3, la liste de ssl_ciphers modernisée, session_tickets désactivés, dhparam généré, et en-têtes HSTS et X-Content-Type-Options, X-Frame-Options, CSP, Referrer-Policy, Permissions-Policy ajoutés. Ensuite, inclusion de ce fichier dans tous les blocs server qui gèrent du HTTPS. Enfin, série de tests avec openssl s_client, testssl.sh et SSL Labs pour valider le résultat.
Dans un second temps, l’équipe IT limite les méthodes HTTP à GET et POST sur l’ensemble du portail, réserve l’accès à l’administration à un range d’adresses IP du VPN, et ajuste client_max_body_size en fonction de la taille maximale des fichiers attendus. Au bout de quelques jours de monitoring, aucune plainte côté utilisateur, mais un grade A+ sur SSL Labs et un rapport d’audit révisé en conséquence.
Le coût du chantier a tenu en deux demi-journées de travail concentré, plus quelques échanges avec l’éditeur de la solution web utilisée. Le gain, lui, se mesure en sérénité : plus de remarques récurrentes sur la « faiblesse du HTTPS », et un portail qui tient mieux la charge lors de pics de consultation. C’est souvent ce type de trajectoire discrète qui illustre le mieux la valeur d’un durcissement bien pensé.
Pourquoi garder TLS 1.2 si TLS 1.3 est plus récent et plus sûr ?
TLS 1.3 apporte des avancées importantes, mais tous les clients ne le supportent pas encore, notamment dans certains environnements embarqués ou industriels. Conserver TLS 1.2 avec des suites de chiffrement modernes permet de couvrir ces clients tout en restant solide sur le plan de la sécurité. Le profil Intermediate (TLS 1.2 + 1.3) reste aujourd’hui le choix le plus équilibré pour un serveur Nginx exposé à un large public.
La directive ssl_ciphers a-t-elle encore un impact avec TLS 1.3 ?
Oui, mais uniquement pour les protocoles qui utilisent encore cette liste, comme TLS 1.2. En TLS 1.3, les suites sont définies au niveau d’OpenSSL et ne se pilotent plus via ssl_ciphers dans Nginx. Cela reste néanmoins essentiel de filtrer les suites pour TLS 1.2 afin d’éliminer les chiffrements faibles ou obsolètes.
Désactiver les tickets de session TLS dégrade-t-il les performances ?
Sur un petit nombre de serveurs, l’impact reste limité. Le cache de session Nginx permet déjà de réduire le coût des handshakes sans recourir à des tickets réutilisables chiffrés avec une clé globale. Les tickets deviennent surtout intéressants sur de gros parcs distribués, mais au prix d’une gestion plus délicate des clés. Pour une PME, ssl_session_tickets off reste souvent le compromis le plus sain.
Comment vérifier rapidement que TLS 1.0 et 1.1 sont bien désactivés sur Nginx ?
Une méthode simple consiste à utiliser openssl s_client en forçant la version du protocole. Par exemple, openssl s_client -connect domaine:443 -tls1 ou -tls1_1 doit échouer, tandis que -tls1_2 et -tls1_3 doivent réussir. Un outil comme testssl.sh donne ensuite une vue plus complète des protocoles et des suites réellement acceptés par le serveur.
Faut-il activer HSTS preload pour tous les sites en HTTPS ?
Le preload HSTS inscrit le domaine dans une liste embarquée dans les navigateurs, ce qui force l’usage de HTTPS dès la première connexion. C’est puissant, mais difficile à revenir en arrière. Il n’est pertinent que si tous les sous-domaines actuels et futurs sont capables de servir du HTTPS en continu. Dans le doute, mieux vaut commencer par HSTS sans preload et évaluer ensuite l’impact avant de franchir le pas.