SSL /TLS Meilleures pratiques pour 2023

En 2023, sécuriser votre site web avec un SSL /TLS le certificat n'est plus facultatif, même pour les entreprises qui ne traitent pas directement les informations sensibles des clients sur le Web. Les moteurs de recherche comme Google utilisent la sécurité du site comme signal de classement SEO, et les navigateurs Web populaires comme Chrome alertent les utilisateurs sur les sites Web qui n'utilisent pas HTTPS:

Cependant, la perspective de configurer vos serveurs Web et applications pour utiliser le SSL /TLS protocole correctement peut sembler décourageant, car il y a beaucoup de choix de configuration et de conception obscurs à faire. Ce guide fournit un aperçu rapide des principaux points à garder à l'esprit lors de la configuration de SSL /TLS pour votre site Web, tout en mettant l'accent à la fois sur la sécurité et les performances. Il reste encore beaucoup à couvrir avec les bases, nous l'avons donc décomposé en une série d'étapes.

Choisissez une autorité de certification fiable (CA)

Vos certificats sont aussi fiables que l'autorité de certification qui les émet. Toutes les autorités de certification de confiance du public sont soumises à des audits tiers rigoureux pour maintenir leur position dans les principaux programmes de certificat racine du système d'exploitation et du navigateur, mais certaines sont plus aptes à maintenir ce statut que d'autres. Recherchez un CA qui (comme SSL.com):

• Fait l'essentiel de ses activités dans le domaine de la confiance publique PKI. Ces entreprises ont le plus à perdre si de mauvaises pratiques de sécurité sont mises en évidence, et tout à gagner à suivre l'évolution des normes de l'industrie.
• Répond de manière efficace et efficiente aux découvertes de vulnérabilités affectant la sécurité et la confidentialité des utilisateurs, comme le secteur entropie du numéro de série édition du début de 2019. Recherche dans les forums de l'industrie comme mozilla.dev.politique.de.sécurité peut vous donner une bonne idée de la façon dont une autorité de certification particulière réagit à l'adversité.
• Propose des produits et services utiles, tels que les certificats Extended Validation (EV), la délivrance de certificats en masse / automatisée via un API au sein de l’ Protocole ACME, des services simples de gestion et de surveillance du cycle de vie des certificats, et support pour l'intégration avec une liste complète de solutions tierces.
• A la réputation d'un excellent service client et d'un excellent support technique. Assurer la sécurité du site Web de votre entreprise à 100% du temps est important et vous devez être en mesure de faire appel à un véritable expert au téléphone lorsque les choses tournent mal.

Autorisation de l'autorité de certification (CAA)

Autorisation de l'autorité de certification (CAA) est une norme visant à protéger les sites Web en désignant des autorités de certification spécifiques autorisées à émettre des certificats pour un nom de domaine. Une fois que vous avez choisi une autorité de certification, vous devriez envisager configuration des enregistrements CAA pour l’autoriser.

Générez et sécurisez vos clés privées

La SSL /TLS protocole utilise une paire de clés pour authentifier les identités et crypter les informations envoyées sur Internet. L'un d'eux (le Clé publique) est destiné à une large diffusion et l'autre (le Clé privée) doit être conservé de la manière la plus sûre possible. Ces clés sont créées ensemble lorsque vous générez un demande de signature de certificat (CSR). Voici quelques conseils à garder à l'esprit concernant vos clés privées:

• Utilisez des clés privées fortes: Les clés plus grandes sont plus difficiles à casser, mais nécessitent plus de temps de calcul. Actuellement, au moins une clé RSA 2048 bits ou une clé ECDSA 256 bits est recommandée, et la plupart des sites Web peuvent atteindre une bonne sécurité tout en optimisant les performances et l'expérience utilisateur avec ces valeurs.
  
  Remarque: pour un aperçu de ces deux algorithmes, veuillez consulter l'article de SSL.com, Comparaison ECDSA vs RSA.
• Protégez vos clés privées:
  • Générez vos propres clés privées dans un environnement sécurisé et de confiance (de préférence sur le serveur sur lequel elles seront déployées ou sur un appareil compatible FIPS ou Critères Communs). Jamais autoriser une autorité de certification (ou toute autre personne) à générer des clés privées en votre nom. Une autorité de certification publique réputée, telle que SSL.com, ne proposera jamais de générer ou de gérer vos clés privées à moins qu'elles ne soient générées dans un jeton matériel sécurisé ou HSM et ne soient pas exportables.
  • Ne donnez accès aux clés privées que si nécessaire. Générer de nouvelles clés et révoquer tous les certificats des anciennes clés lorsque les employés disposant d'un accès par clé privée quittent l'entreprise.
  • Renouvelez les certificats aussi souvent que possible (au moins une fois par an, ce serait bien), de préférence en utilisant à chaque fois une clé privée fraîchement générée. Des outils d'automatisation comme le Protocole ACME sont utiles pour planifier des renouvellements fréquents de certificats.
  • Si une clé privée a été (ou aurait pu être) compromise, révoquer tous les certificats pour cette clé, générez une nouvelle paire de clés et émettez un nouveau certificat pour la nouvelle paire de clés.

Configurez votre serveur

À la surface, installer un SSL /TLS certificat peut sembler une opération simple; Cependant, de nombreuses décisions de configuration doivent encore être prises pour garantir que votre serveur Web est rapide et sécurisé et que les utilisateurs finaux bénéficient d'une expérience fluide, sans erreurs de navigateur ni avertissements. Voici quelques pointeurs de configuration pour vous aider à vous mettre sur la bonne voie lors de la configuration de SSL /TLS sur vos serveurs:

• Assurez-vous que tous les noms d'hôte sont couverts: Votre certificat couvre-t-il le nom de domaine de votre site avec et sans le www préfixe? y a t-il Autre nom de sujet (SAN) pour chaque nom de domaine que le certificat est destiné à protéger?
• Installer des chaînes de certificats complètes: SSL d'entité finale /TLS les certificats sont généralement signés par des certificats intermédiaires plutôt que par la clé racine d'une autorité de certification. Assurez-vous que tous les certificats intermédiaires sont installés sur votre serveur Web pour fournir aux navigateurs une chemin de certification et évitez les avertissements de confiance et les erreurs pour les utilisateurs finaux. Votre CA sera en mesure de vous fournir tous les intermédiaires nécessaires; Les clients de SSL.com peuvent utiliser notre Téléchargement de certificat intermédiaire pour récupérer des ensembles intermédiaires pour de nombreuses plates-formes de serveur.
• Utiliser SSL actuel /TLS Protocoles (TLS 1.2 ou 1.3): Fin 2018, tous les principaux éditeurs de navigateurs ont annoncé leur intention de déprécier TLS 1.0 et 1.1 d'ici la première moitié de 2020. Google obsolète TLS v1.0 et v1.1 dans Chrome 72 (publié le 30 janvier 2919). Les versions 84 de Chrome (publiées le 14 juillet 2020) et supérieures présentent un avertissement interstitiel pour ces protocoles, et la prise en charge devait être entièrement supprimé en mai 2021. Prise en charge généralisée des navigateurs SSL /TLS les versions, telles que SSL v3, ont disparu depuis longtemps. Tandis que TLS 1.2 est actuellement la version la plus utilisée du SSL /TLS protocole, TLS 1.3 (la dernière version) est déjà supporté dans les versions actuelles de la plupart des principaux navigateurs Web.
• Utilisez une courte liste de suites de chiffrement sécurisé: Choisissez uniquement des suites de chiffrement qui offrent un cryptage d'au moins 128 bits, ou plus fort si possible. L’Institut national des normes et de la technologie (NIST) recommande également que tous les TLS les implémentations s'éloignent des suites de chiffrement contenant le chiffrement DES (ou ses variantes) pour celles utilisant AES. Enfin, n'utiliser qu'un petit sous-ensemble de suites de chiffrement potentiellement acceptables minimise la surface d'attaque pour les vulnérabilités non encore découvertes. L'annexe des SSL.com Guide de TLS Conformité aux normes fournit des exemples de configurations pour les plates-formes de serveurs Web les plus populaires, en utilisant TLS 1.2.
  
  Remarque: L'utilisation de chiffres non sécurisés et obsolètes (tels que RC4) peut entraîner des erreurs de sécurité du navigateur, telles que ERR_SSL_VERSION_OR_CIPHER_MISMATCH dans Google Chrome.
• Utiliser le secret avancé (FS): Aussi connu sous le nom Perfect Forward Secret (PFS), FS garantit qu'une clé privée compromise ne compromettra pas également les clés de session antérieures. Pour activer FS:
  • Configurer TLS 1.2 pour utiliser l'algorithme d'échange de clés EDIE (Elliptic Curve Diffie-Hellman) (avec DHE comme solution de rechange) et évitez si possible l'échange de clés RSA.
  • Utilisez TLS 1.3. TLS 1.3 offre un secret pour tous TLS sessions via le Diffie-Hellman éphémère (EDH ou DHE) protocole d'échange de clés.
• Activer TLS Reprise de la session: De la même manière que l'utilisation de keepalives pour maintenir des connexions TCP persistantes, TLS la reprise de session permet à votre serveur Web de garder une trace du SSL /TLS sessions et les reprendre, en contournant la charge de calcul de la négociation des clés de session.
• Considérez l'agrafage OCSP: Agrafage OCSP permet aux serveurs Web de fournir des informations de révocation en cache directement au client, ce qui signifie qu'un navigateur n'aura pas à contacter un serveur OCSP pour vérifier si le certificat d'un site Web a été révoqué. En éliminant cette demande, l'agrafage OCSP offre une réelle amélioration des performances. Pour plus d'informations, veuillez lire notre article, Optimisation du chargement des pages: agrafage OCSP.

Utiliser les meilleures pratiques pour la conception d'applications Web

Concevoir vos applications Web en tenant compte de la sécurité est tout aussi important que de configurer correctement votre serveur. Ce sont les points les plus importants pour vous assurer que vos utilisateurs ne sont pas exposés à l'homme au milieu attaques et que votre application bénéficie des avantages SEO associés aux bonnes pratiques de sécurité:

• Éliminer le contenu mixte: Les fichiers JavaScript, les images et les fichiers CSS doivent TOUTE être accessible avec SSL /TLS. Comme indiqué dans l'article de SSL.com, HTTPS Everywhere, servant contenu mixte n'est plus un moyen acceptable d'augmenter les performances du site Web et peut entraîner des avertissements de sécurité du navigateur et des problèmes de référencement.
• Utilisez des cookies sécurisés: Réglage Secure l'indicateur dans les cookies imposera la transmission sur des canaux sécurisés (par exemple HTTPS). Vous pouvez également empêcher JavaScript côté client d'accéder aux cookies via le HttpOnly drapeau et restreindre l'utilisation intersite des cookies avec le SameSite drapeau.
• Évaluez le code tiers: Assurez-vous de bien comprendre les risques potentiels liés à l'utilisation de bibliothèques tierces sur votre site Web, tels que la possibilité d'introduire par inadvertance des vulnérabilités ou du code malveillant. Vérifiez toujours la fiabilité des tiers au mieux de vos capacités et établissez un lien vers tous les codes tiers avec HTTPS. Enfin, assurez-vous que votre avantage de tout élément tiers sur votre site Web en vaut la peine.

Vérifiez votre travail avec les outils de diagnostic

Après avoir configuré SSL /TLS sur votre serveur et votre site Web ou en effectuant des modifications de configuration, il est important de vous assurer que tout est correctement configuré et que votre système est sécurisé. De nombreux outils de diagnostic sont disponibles pour vérifier le SSL /TLS. Par exemple, SSL Shopper's Vérificateur SSL vous fera savoir si votre certificat est correctement installé, quand il expirera et affichera le certificat chaîne de confiance.

D'autres outils et applications en ligne sont disponibles pour analyser votre site en vérifiant les problèmes de sécurité tels que le contenu mixte. Vous pouvez également vérifier le contenu mixte avec un navigateur Web en utilisant ses outils de développement intégrés:

Quels que soient les outils que vous choisissez, il est également important de définir un calendrier pour vérifier votre SSL /TLS installation et configuration. Votre CA peut également être en mesure de vous aider. Par exemple, pour plus de commodité pour nos clients, SSL.com fournit des notifications automatisées d'expiration imminente du certificat.

Mettre en œuvre la sécurité de transport stricte HTTP (HSTS)

HTTP Strict Transport Security (HSTS) est un mécanisme de politique de sécurité qui aide à protéger les sites Web contre les attaques de dégradation de protocole et le détournement de cookies. Il permet aux serveurs Web de déclarer que les navigateurs Web (ou d'autres agents utilisateurs conformes) ne doivent interagir avec lui qu'en utilisant des connexions HTTPS sécurisées, et jamais via le protocole HTTP non sécurisé. Cette politique est communiquée par le serveur à l'agent utilisateur via un champ d'en-tête de réponse HTTP nommé « Strict-Transport-Security ».

Implémenter Sécurité du transport strict HTTP (HSTS), vous devez ajouter un en-tête de réponse spécial à la configuration de votre serveur Web.

Voici un guide étape par étape:

1. Assurez-vous que votre site prend en charge HTTPS: Avant d'activer HSTS, votre site doit avoir un certificat SSL et être en mesure de diffuser du contenu via HTTPS. Si votre site n'est pas encore configuré pour HTTPS, vous devrez obtenir un certificat SSL et configurez votre serveur pour l'utiliser.

L'en-tête est toujours défini sur Strict-Transport-Security "max-age=31536000; includeSubDomains"

_{Cette ligne indique au navigateur de toujours utiliser HTTPS pour votre site pour l'année prochaine (31,536,000 XNUMX XNUMX secondes), y compris tous les sous-domaines.}

2. Testez votre configuration : Après avoir ajouté l'en-tête HSTS, vous devez tester votre site pour vous assurer qu'il fonctionne correctement. Vous pouvez le faire en visitant votre site et en utilisant les outils de développement de votre navigateur pour vérifier les en-têtes de réponse. Vous devriez voir l'en-tête Strict-Transport-Security avec la valeur que vous avez définie.
3. Envisagez d'ajouter votre site à la liste de préchargement HSTS: La liste de préchargement HSTS est une liste de sites codés en dur dans les navigateurs comme compatibles HSTS. Cela offre un niveau de protection supplémentaire, car cela garantit que la première connexion à votre site est sécurisée, même avant la réception de l'en-tête HSTS. Vous pouvez soumettre votre site à la liste de préchargement HSTS sur hstspreload.org.

Case Study: Un site d'actualités veut s'assurer que ses utilisateurs s'y connectent toujours en toute sécurité, même s'ils tapent accidentellement « http » au lieu de « https » dans l'URL. Le site Web utilise HSTS en ajoutant l'en-tête Strict-Transport-Security à sa configuration de serveur, en définissant un long max-age et en incluant tous les sous-domaines. Cela indique aux agents utilisateurs de toujours s'y connecter en utilisant HTTPS, protégeant les utilisateurs contre les attaques qui tentent de rétrograder la connexion vers HTTP et de voler leurs cookies. Le site Web se soumet également à la liste de préchargement HSTS pour une protection supplémentaire.

Implémenter l'épinglage de clé publique HTTP (HPKP)

HTTP Public Key Pinning (HPKP) était une fonction de sécurité qui permettait à un serveur Web de s'associer une clé publique cryptographique spécifique pour empêcher attaques de l'homme du milieu (MITM) avec de faux certificats.

Voici un bref aperçu de la façon dont il a été utilisé :

1. Générer des informations d'épinglage: La première étape de la mise en œuvre de HPKP consistait à générer les informations d'épinglage. Cela impliquait de créer un hachage cryptographique de la clé publique du certificat ou de la clé publique du certificat intermédiaire ou racine.
2. Configurer le serveur Web: L'étape suivante consistait à configurer le serveur Web pour inclure le Broches de clé publique HTTP en-tête dans les réponses. Cet en-tête comprenait les hachages des clés publiques (les « broches »), une durée de vie (la durée pendant laquelle le navigateur doit se souvenir des informations) et éventuellement un URI de rapport (où le navigateur enverrait des rapports sur les échecs de validation des broches).
3. Gérer les échecs de validation des broches: Si un navigateur prenant en charge HPKP recevait une chaîne de certificats qui n'incluait pas au moins une des clés publiques épinglées, il considérerait la connexion comme non approuvée. Si un URI de rapport était spécifié, le navigateur enverrait également un rapport de l'échec à cet URI.

Cependant, en raison du risque d'utilisation abusive et de la possibilité de provoquer un déni de service, HPKP a été déprécié par la plupart des navigateurs et n'est plus une pratique recommandée. Une mauvaise configuration de HPKP pourrait conduire à une situation où un site Web devient inaccessible.

Case Study : Dans le passé, une entreprise de technologie utilisait HPKP pour épingler ses clés publiques sur ses serveurs. Cela garantissait que si une autorité de certification (CA) était compromise et qu'un certificat était émis par erreur pour leur domaine, les navigateurs ne lui feraient pas confiance à moins qu'il ne dispose également d'une clé publique correspondant à l'une des clés épinglées. Cependant, ils devaient être très prudents pour éviter de perdre l'accès aux clés épinglées, ce qui rendrait leur site Web inaccessible. Ils devaient également s'assurer qu'ils avaient mis en place un processus pour faire pivoter les épingles avant leur expiration, afin d'éviter de rendre leur site inaccessible aux utilisateurs avec des informations d'épinglage en cache.

Utilisez TLS SCSV de secours pour empêcher les attaques de dégradation de protocole

TLS SCSV de repli (Valeur de suite de chiffrement de signalisation) est un mécanisme qui a été introduit pour empêcher les attaques de rétrogradation de protocole. Ces attaques se produisent lorsqu'un attaquant interfère avec le processus de configuration de la connexion et incite le client et le serveur à utiliser une version du protocole moins sécurisée que celle qu'ils prennent en charge.

Voici comment vous pouvez mettre en œuvre TLS SCSV de secours :

1. Mettez à jour le SSL de votre serveur/TLS Bibliothèque: La première étape consiste à s'assurer que le SSL/TLS supports de bibliothèque TLS SCSV de secours. Cette fonctionnalité a été introduite dans OpenSSL 1.0.1j, 1.0.0o et 0.9.8zc. Si vous utilisez un autre SSL/TLS bibliothèque, consultez sa documentation ou contactez ses développeurs.
2. Configurez votre serveur: Une fois le SSL/ de votre serveurTLS supports de bibliothèque TLS Fallback SCSV, vous devrez peut-être configurer votre serveur pour l'utiliser. Les étapes exactes dépendront de votre logiciel serveur. Par exemple, dans Apache, vous devrez peut-être ajouter ou modifier une ligne dans votre fichier de configuration comme celle-ci :

Protocole SSL Tous -SSLv2 -SSLv3

Cette ligne indique au serveur d'utiliser toutes les versions de protocole à l'exception de SSLv2 et SSLv3. Si le client et le serveur prennent tous deux en charge TLS 1.2, mais le client tente d'utiliser TLS 1.1 (peut-être à cause de l'interférence d'un attaquant), le serveur reconnaîtra cela comme une tentative de secours et rejettera la connexion.

3. Testez votre serveur: Après avoir configuré votre serveur, vous devez le tester pour vous assurer qu'il implémente correctement TLS SCSV de secours. Il existe divers outils en ligne qui peuvent vous aider, tels que SSL Labs Server Test.

Case Study: Une entreprise mondiale utilise TLS SCSV de secours pour protéger ses communications internes. Cela garantit que si un attaquant tente de forcer une rétrogradation de protocole, le serveur le reconnaîtra et rejettera la connexion, protégeant ainsi les données sensibles de l'entreprise. L'équipe informatique de la société met régulièrement à jour le SSL/TLS bibliothèques et configurations pour s'assurer qu'ils utilisent les dernières fonctionnalités de sécurité, et ils utilisent des outils en ligne pour tester leurs serveurs et confirmer qu'ils implémentent correctement TLS SCSV de secours.

Éviter les problèmes de contenu mixte

Le contenu mixte est un risque de sécurité qui se produit lorsqu'une page Web chargée via une connexion HTTPS sécurisée inclut des ressources, telles que des images, des vidéos, des feuilles de style ou des scripts, qui sont chargées via une connexion HTTP non sécurisée. Les navigateurs peuvent bloquer ce contenu mixte ou afficher un avertissement à l'utilisateur, ce qui peut nuire à la perception qu'a l'utilisateur de la sécurité du site.

Voici comment vous pouvez éviter les problèmes de contenu mixte :

1. Utiliser HTTPS pour toutes les ressources: La façon la plus simple d'éviter le contenu mixte est de s'assurer que toutes les ressources de votre site sont chargées via HTTPS. Cela inclut les images, les scripts, les feuilles de style, les iframes, les requêtes AJAX et toute autre ressource utilisée par votre site.
2. Mettre à jour le code de votre site : Si le code de votre site inclut des URL HTTP codées en dur pour les ressources, vous devrez les mettre à jour pour utiliser HTTPS à la place. Si la ressource est hébergée sur un serveur qui ne prend pas en charge HTTPS, vous devrez peut-être héberger la ressource sur votre propre serveur ou trouver une autre ressource pouvant être chargée via HTTPS.
3. Configurez votre serveur pour envoyer un en-tête Content-Security-Policy: L'en-tête HTTP Content-Security-Policy (CSP) vous permet de contrôler les ressources que votre site est autorisé à charger. En définissant un en-tête CSP qui n'autorise que les ressources HTTPS, vous pouvez vous assurer que votre site n'inclut pas accidentellement de contenu mixte.

Case Study: Un magazine en ligne garantit que tout le contenu, y compris les images et les scripts, est chargé via HTTPS. Cela empêche les attaquants de falsifier ces ressources et d'injecter potentiellement du contenu malveillant. Les développeurs Web du magazine examinent régulièrement le code du site pour s'assurer que toutes les ressources sont chargées via HTTPS, et ils configurent leur serveur pour envoyer un en-tête Content-Security-Policy strict. Ils utilisent également des outils en ligne pour analyser leur site à la recherche de problèmes de contenu mixte et résoudre ceux qu'ils trouvent.

Utiliser l'indication de nom de serveur (SNI) pour héberger plusieurs sites

Indication de nom de serveur (SNI) est une extension de la TLS protocole qui permet à un serveur de présenter plusieurs certificats sur la même adresse IP et le même numéro de port. Ceci est particulièrement utile pour les fournisseurs d'hébergement Web qui doivent héberger plusieurs sites Web sécurisés, chacun avec son propre certificat SSL, sur le même serveur.

Voici comment vous pouvez utiliser SNI :

1. Assurez-vous que votre logiciel serveur prend en charge SNI: La première étape consiste à vous assurer que votre logiciel serveur prend en charge SNI. La plupart des serveurs Web modernes, y compris Apache, Nginx et IIS, prennent en charge SNI.
2. Configurez votre serveur: L'étape suivante consiste à configurer votre serveur pour utiliser SNI. Cela implique généralement l'ajout d'un bloc de configuration distinct pour chaque site que vous souhaitez héberger sur le serveur et la spécification du certificat SSL à utiliser pour chaque site. Les étapes exactes dépendront de votre logiciel serveur.
3. Testez votre configuration: Après avoir configuré votre serveur, vous devez le tester pour vous assurer qu'il utilise correctement SNI. Vous pouvez le faire en visitant chaque site que vous hébergez sur le serveur et en vérifiant que le bon certificat SSL est utilisé.

Case Study: Un fournisseur d'hébergement utilise SNI pour servir plusieurs sites Web à partir de la même adresse IP. Cela leur permet d'utiliser efficacement leur espace d'adressage IP et de simplifier leur configuration réseau. Ils configurent leur serveur pour utiliser un certificat SSL différent pour chaque site, et ils testent régulièrement leur configuration pour s'assurer que le bon certificat est utilisé pour chaque site. Cela garantit que chaque site dispose d'une connexion sécurisée et fiable, même s'ils sont tous servis à partir de la même adresse IP.

Optimisez les performances avec la reprise de session

La reprise de session est une fonctionnalité du TLS protocole qui permet à un client et à un serveur d'utiliser les mêmes clés de chiffrement sur plusieurs sessions, réduisant ainsi la surcharge liée à l'établissement d'une nouvelle connexion sécurisée à chaque fois. Cela peut améliorer considérablement les performances, en particulier pour les applications où le client se déconnecte et se reconnecte fréquemment.

 Voici comment utiliser la reprise de session :

1. Assurez-vous que votre logiciel serveur prend en charge la reprise de session: La première étape consiste à s'assurer que votre logiciel serveur prend en charge la reprise de session. La plupart des serveurs Web modernes, y compris Apache, Nginx et IIS, prennent en charge cette fonctionnalité.
2. Configurez votre serveur: L'étape suivante consiste à configurer votre serveur pour utiliser la reprise de session. Cela implique généralement l'activation du cache de session et la définition d'une valeur de délai d'attente pour le cache. Les étapes exactes dépendront de votre logiciel serveur.
3. Testez votre configuration: Après avoir configuré votre serveur, vous devez le tester pour vous assurer qu'il utilise correctement la reprise de session. Vous pouvez le faire en établissant un TLS connexion à votre serveur, déconnexion, puis reconnexion. Si la reprise de session fonctionne correctement, la deuxième connexion devrait être plus rapide à établir que la première.

Case Study: Une application mobile utilise la reprise de session pour maintenir des connexions rapides et sécurisées. Ceci est particulièrement utile lorsque l'application est utilisée dans des zones avec une couverture réseau inégale, car cela permet à l'application de rétablir rapidement une connexion sécurisée après une interruption. Les développeurs de l'application configurent leur serveur pour utiliser la reprise de session et testent régulièrement la fonctionnalité pour s'assurer qu'elle fonctionne correctement. Cela garantit que l'application peut fournir une expérience rapide et transparente aux utilisateurs, même dans des conditions de réseau difficiles.

Assurez la validité du certificat avec l'agrafage OCSP

L'agrafage OCSP (Online Certificate Status Protocol) est une méthode permettant d'améliorer les performances de SSL/TLS tout en maintenant la sécurité de la connexion. Il permet au serveur de récupérer l'état actuel de ses propres certificats auprès de l'autorité de certification (CA), puis de fournir cet état aux clients lors de la TLS poignée de main.

Voici comment mettre en œuvre l'agrafage OCSP :

1. Assurez-vous que votre logiciel serveur prend en charge l'agrafage OCSP: La première étape consiste à vous assurer que votre logiciel serveur prend en charge l'agrafage OCSP. La plupart des serveurs Web modernes, y compris Apache, Nginx et IIS, prennent en charge cette fonctionnalité.
2. Configurez votre serveur: L'étape suivante consiste à configurer votre serveur pour utiliser l'agrafage OCSP. Cela implique généralement l'activation de la fonctionnalité dans le SSL/TLS configuration et en spécifiant un emplacement pour que le serveur stocke les réponses OCSP. Les étapes exactes dépendront de votre logiciel serveur.
3. Testez votre configuration: Après avoir configuré votre serveur, vous devez le tester pour vous assurer qu'il utilise correctement l'agrafage OCSP. Vous pouvez le faire en établissant un TLS connexion à votre serveur et en vérifiant que le serveur inclut une réponse OCSP dans le TLS poignée de main.

Case Study: Un e-commerçant utilise l'agrafage OCSP pour vérifier rapidement l'état de son certificat SSL. Cela garantit que les clients disposent toujours d'une connexion sécurisée et peuvent être sûrs que leurs données sont en sécurité. L'équipe informatique du détaillant configure son serveur pour utiliser l'agrafage OCSP et teste régulièrement la fonctionnalité pour s'assurer qu'elle fonctionne correctement. Cela permet de maintenir la confiance de leurs clients et de protéger leurs données sensibles.

Désactiver TLS Compression pour atténuer les attaques CRIME

TLS la compression est une fonctionnalité qui peut améliorer les performances de SSL/TLS en réduisant la quantité de données à envoyer sur le réseau. Cependant, cela peut également rendre la connexion vulnérable à l'attaque CRIME (Compression Ratio Info-leak Made Easy), qui peut permettre à un attaquant de déduire le contenu du trafic chiffré.

Voici comment vous pouvez désactiver TLS compression: 

1. Assurez-vous que votre logiciel serveur prend en charge la désactivation TLS Compression: La première étape consiste à s'assurer que votre logiciel serveur prend en charge la désactivation TLS compression. La plupart des serveurs Web modernes, y compris Apache, Nginx et IIS, prennent en charge cette fonctionnalité.
2. Configurez votre serveur: L'étape suivante consiste à configurer votre serveur pour désactiver TLS compression. Les étapes exactes dépendront de votre logiciel serveur. Par exemple, dans Apache, vous pouvez ajouter une ligne comme celle-ci à votre fichier de configuration :

Compression SSL désactivée

Cette ligne indique au serveur de ne pas utiliser la compression pour SSL/TLS connexions.

3. Testez votre configuration: Après avoir configuré votre serveur, vous devez le tester pour vous assurer qu'il désactive correctement TLS compression. Vous pouvez le faire en établissant un TLS connexion à votre serveur et en vérifiant que la connexion n'utilise pas la compression.

Case Study: Une institution financière désactive TLS compression sur ses serveurs pour se protéger contre l'attaque CRIME. Cela permet de garantir la confidentialité des données financières sensibles, telles que les numéros de compte et les détails des transactions. L'équipe informatique de l'établissement configure ses serveurs pour désactiver TLS compression, et ils testent régulièrement les serveurs pour s'assurer qu'ils implémentent correctement cette mesure de sécurité. Cela permet de protéger les clients de l'institution et de conserver leur confiance.

Mettre en œuvre le TLS Billets de session correctement

TLS les billets de session sont une caractéristique du TLS protocole qui peut améliorer les performances en permettant à un client et à un serveur de reprendre une session précédente sans avoir à effectuer une poignée de main complète. Cependant, ils doivent être implémentés correctement pour éviter les problèmes de sécurité potentiels.

Voici comment vous pouvez correctement mettre en œuvre TLS billets de séance :

1. Assurez-vous que votre logiciel serveur prend en charge TLS Billets de session: La première étape consiste à s'assurer que votre logiciel serveur prend en charge TLS billets de séance. La plupart des serveurs Web modernes, y compris Apache, Nginx et IIS, prennent en charge cette fonctionnalité.
2. Configurez votre serveur: L'étape suivante consiste à configurer votre serveur pour utiliser TLS billets de séance. Cela implique généralement l'activation de la fonctionnalité dans le SSL/TLS configuration. Les étapes exactes dépendront de votre logiciel serveur.
3. Utiliser des clés de ticket de session uniques: Pour éviter les problèmes de sécurité potentiels, chaque serveur doit utiliser une clé de ticket de session unique. Si vous utilisez un équilibreur de charge, vous devez le configurer pour répartir les clients en fonction de leur ticket de session, plutôt que d'autoriser les clients à utiliser un ticket de session émis par un serveur pour établir une session avec un autre serveur.
4. Rotation régulière des clés de ticket de session : Pour renforcer encore la sécurité, vous devez effectuer une rotation régulière de vos clés de ticket de session. Cela peut souvent être automatisé à l'aide de votre logiciel serveur ou d'un système de gestion de clés distinct.

Case Study: Une grande entreprise technologique avec plusieurs serveurs garantit que chaque serveur utilise une clé de ticket de session unique. Cela empêche un attaquant de pouvoir utiliser un ticket de session d'un serveur pour se faire passer pour un utilisateur sur un autre serveur. L'équipe informatique de l'entreprise configure ses serveurs pour utiliser TLS tickets de session, et ils ont mis en place un système pour faire tourner régulièrement les clés des tickets de session. Ils configurent également leur équilibreur de charge pour distribuer les clients en fonction de leur ticket de session, améliorant encore la sécurité de leur système.

Activer la renégociation sécurisée

La renégociation sécurisée est une fonctionnalité de SSL/TLS protocoles qui permettent au client ou au serveur de demander un nouveau TLS poignée de main au milieu d'une session. Cela peut être utile pour diverses raisons, telles que l'actualisation des clés de chiffrement ou la modification du niveau de chiffrement. Cependant, s'il n'est pas géré de manière sécurisée, il peut être exploité par un attaquant pour injecter du texte en clair dans la communication chiffrée.

Voici comment activer la renégociation sécurisée :

2. Assurez-vous que votre logiciel serveur prend en charge la renégociation sécurisée: La première étape consiste à s'assurer que votre logiciel serveur prend en charge la renégociation sécurisée. La plupart des serveurs Web modernes, y compris Apache, Nginx et IIS, prennent en charge cette fonctionnalité.
3. Configurez votre serveur: L'étape suivante consiste à configurer votre serveur pour utiliser la renégociation sécurisée. Cela implique généralement l'activation de la fonctionnalité dans le SSL/TLS configuration. Les étapes exactes dépendront de votre logiciel serveur.
4. Testez votre configuration: Après avoir configuré votre serveur, vous devez le tester pour vous assurer qu'il utilise correctement la renégociation sécurisée. Vous pouvez le faire en établissant un TLS connexion à votre serveur, puis tentez de renégocier la connexion.

Case Study: Une plateforme de médias sociaux permet une renégociation sécurisée pour protéger les données des utilisateurs. Cela empêche un attaquant de pouvoir injecter du contenu malveillant dans la communication chiffrée entre l'utilisateur et le serveur. L'équipe informatique de la plateforme configure ses serveurs pour utiliser la renégociation sécurisée et teste régulièrement les serveurs pour s'assurer qu'ils mettent correctement en œuvre cette mesure de sécurité. Cela permet de protéger les utilisateurs de la plateforme et de maintenir leur confiance.

Désactiver la renégociation initiée par le client pour empêcher les attaques DoS

La renégociation initiée par le client est une fonctionnalité de SSL/TLS protocoles qui permettent au client de demander un nouveau TLS poignée de main au milieu d'une session. Cependant, si un attaquant peut forcer un serveur à renégocier en permanence des sessions, il peut consommer des ressources excessives et potentiellement conduire à une attaque par déni de service (DoS).

Voici comment vous pouvez désactiver la renégociation initiée par le client :

1. Assurez-vous que votre logiciel serveur prend en charge la désactivation de la renégociation initiée par le client: La première étape consiste à s'assurer que votre logiciel serveur prend en charge la désactivation de la renégociation initiée par le client. La plupart des serveurs Web modernes, y compris Apache, Nginx et IIS, prennent en charge cette fonctionnalité.
2. Configurez votre serveur: L'étape suivante consiste à configurer votre serveur pour désactiver la renégociation initiée par le client. Cela implique généralement l'ajout d'une directive au SSL/TLS configuration. Les étapes exactes dépendront de votre logiciel serveur.
3. Testez votre configuration: Après avoir configuré votre serveur, vous devez le tester pour vous assurer qu'il désactive correctement la renégociation initiée par le client. Vous pouvez le faire en établissant un TLS connexion à votre serveur, puis tentez de renégocier la connexion. Si le serveur refuse correctement la demande de renégociation, alors il est correctement configuré.

Case Study: Une plate-forme de jeu en ligne désactive la renégociation initiée par le client pour se protéger contre d'éventuelles attaques DoS. Cela permet de garantir que la plate-forme reste disponible pour les utilisateurs, même face à des attaques potentielles. L'équipe informatique de la plate-forme configure ses serveurs pour désactiver la renégociation initiée par le client et teste régulièrement les serveurs pour s'assurer qu'ils mettent correctement en œuvre cette mesure de sécurité. Cela permet de protéger les utilisateurs de la plateforme et de maintenir leur confiance.

Restez à l'affût des nouvelles vulnérabilités

La sécurité Web est une cible en constante évolution et vous devez toujours être à l'affût de la prochaine attaque et appliquer rapidement des correctifs de sécurité sur votre serveur. Cela signifie lire et rester au courant de ce qui se profile à l'horizon en matière de sécurité de l'information, ainsi que se tenir au courant des mises à jour logicielles, en particulier les plus critiques. Site Web de SSL.com (où vous lisez ceci en ce moment) est une excellente source pour rester à jour sur SSL /TLS et la sécurité de l'information.

Mais qu'en est-il…?

Si vous souhaitez en savoir plus sur l'un des sujets abordés dans ce guide et en savoir plus sur les nouveaux problèmes et technologies à mesure qu'ils surviennent, vous pouvez commencer par parcourir et rechercher SSL.com. Base de connaissances, que nous tenons à jour chaque semaine avec les nouveaux développements dans le domaine du SSL /TLS et PKI. Vous pouvez également vous sentir libre de contacter notre personnel d'assistance à tout moment par e-mail à Support@SSL.com, au téléphone au 1-877-SSL-Secure, ou en cliquant sur le lien de chat en bas à droite de cette page.

Obtenez des conseils d'experts sur les certificats SSL.
Remplissez le formulaire pour une consultation.