web-dev-qa-db-fra.com

Quels chiffres dois-je utiliser dans mon serveur Web après avoir configuré mon certificat SSL?

Il y a beaucoup grandes questions qui demandent quel est le meilleur certificat à utiliser pour un site Web; mais une fois le certificat acheté, il y a aussi la possibilité de choisir ou de modifier la liste des Chiffres.

Bien que chaque fournisseur puisse appeler ce paramètre quelque chose de légèrement différent, je crois comprendre que la liste de chiffrement est utilisée pour négocier des protocoles de chiffrement entre le client et le serveur.

  1. Quelles sont les bases du choix d'une liste de chiffrement pour mon site Web? Si les valeurs par défaut doivent être modifiées Où les "débutants" devraient-ils aller pour obtenir des conseils fiables?

  2. L'une des recommandations traditionnelles a-t-elle changé depuis l'attaque BEAST de septembre 2011 ou CRIME de 2012?

  3. Quelqu'un tient-il une liste de chiffres pris en charge par OS/Vendor/et la version? Est-il exact de dire que quelque chose comme ça serait utile?

  4. Certains certificats sont-ils incompatibles ou non préférés avec certains chiffres?

  5. Où puis-je en savoir plus? Plus précisément, comment puis-je obtenir une capacité superficielle de comparer les chiffrements sans avoir à reprendre certains cours de mathématiques postsecondaires?

cryptographyencryptiontlswebservercertificates
30
goodguys_activate

Dans SSL/TLS , la suite de chiffrement sélectionne un ensemble d'algorithmes, pour plusieurs tâches: accord de clé, chiffrement symétrique, vérification d'intégrité.

Le type de certificat influe sur le choix de l'accord de clé. Deux paramètres doivent être pris en compte: le type de clé et l'utilisation de la clé:

  • Avec une clé RSA, vous pouvez nominalement utiliser la suite de chiffrement "RSA" et "DHE_RSA". Mais si le certificat de serveur a une extension d'utilisation de clé qui inclut pas le drapeau "keyEncipherment", alors vous êtes nominalement limité à "DHE_RSA".
  • Avec une clé DSA, vous ne pouvez utiliser qu'une suite de chiffrement "DHE_DSS".
  • Avec une clé Diffie-Hellman, vous ne pouvez utiliser qu'un seul de "DH_RSA" ou "DH_DSS", selon le type de clé de l'autorité de certification émettrice.

La plupart des certificats de serveur SSL ont une clé RSA qui n'est pas limitée par une extension d'utilisation de clé, vous pouvez donc utiliser les types de clés "RSA" et "DHE_RSA".

"DHE" signifie "Diffie-Hellman Ephemeral". Cela permet Perfect Forward Secrecy . PFS signifie que si un attaquant vole la clé privée du serveur (celle qui est stockée dans un fichier, donc vraisemblablement vulnérable au vol ultérieur), il ne pourra toujours pas décrypter les transactions enregistrées passées. Il s'agit d'une propriété souhaitable, en particulier lorsque vous souhaitez que votre système soit en bon état lors d'un audit.

Pour le contrôle d'intégrité , vous ne devez pas utiliser MD5 et, si possible, éviter également SHA-1. Aucune des faiblesses actuellement connues de MD5 et SHA-1 n'affecte la sécurité de TLS (sauf peut-être lorsqu'il est utilisé dans un certificat, mais c'est le CA, pas vous). Néanmoins, l'utilisation de MD5 (ou, dans une moindre mesure, de SHA-1) est mauvaise pour les relations publiques. MD5 est "cassé". Si vous utilisez MD5, vous devrez peut-être vous justifier. Personne ne remettrait en question le choix du SHA-256. Le consensus général est que SHA-1 est "tolérable" pour des raisons héritées.

Pour le cryptage symétrique , vous avez le choix entre (principalement) RC4, 3DES et AES (pour ce dernier, la version 256 bits est exagérée; AES- 128 est déjà très bien). Les points suivants peuvent être soulignés:

  • RC4 et 3DES seront pris en charge partout. Les clients les plus âgés peuvent ne pas prendre en charge AES (par exemple, Internet Explorer 6.0 ne semble pas être en mesure de négocier des suites de chiffrement basées sur AES).

  • Il existe des faiblesses connues dans RC4. Aucun n'est fatal immédiatement. La situation est quelque peu similaire à celle de SHA-1: académiquement "cassée", mais ce n'est pas un problème pour le moment. C'est toujours une bonne raison de ne pas utiliser RC4 si cela peut être évité.

  • 3DES est un chiffrement par blocs 64 bits. Cela implique certaines faiblesses (académiques) lorsque vous chiffrez plus de quelques gigaoctets en une seule session.

  • 3DES peut être lourd sur votre CPU. Sur un Intel i7 à 2,7 GHz, OpenSSL atteint une vitesse de cryptage de 180 Mo/s avec AES-128 (il pourrait faire beaucoup mieux s'il utilisait instructions AES-NI ) mais seulement 25 Mo/s avec 3DES. 25 Mo/s est toujours bon (c'est 2,5 fois ce qu'un lien à 100 Mbits/s peut gérer, et en utilisant un seul cœur) mais peut ne pas être négligeable, selon votre situation.

  • L'attaque BEAST est une ancienne faiblesse académique dont il a récemment été démontré qu'elle était applicable dans la pratique. Il nécessite que l'attaquant espionne le lien et exécute du code hostile sur le client (et que ce code doit communiquer avec le système d'espionnage externe); les auteurs de BEAST ont réussi à l'exécuter lorsque le code interne hostile utilise Java ou Javascript. La solution générique est de passer à TLS 1.1 ou 1.2, qui sont immunisés. De plus, cela ne concerne que les chiffres de bloc en mode CBC; RC4 est immunisé.

  • Dans une prise de contact SSL/TLS, le client annonce ses suites de chiffrement prises en charge (les suites préférées viennent en premier), puis le serveur choisit la suite qui sera utilisée. C'est traditionnel que le serveur respecte les préférences du client - c'est-à-dire qu'il choisit la première suite de la liste envoyée par le client que le serveur peut gérer. Mais un serveur pourrait imposer son propre ordre de préférences.

  • DHE implique une consommation CPU légèrement plus élevée sur le serveur (mais cela ne fera pas de différence notable à moins que vous établissiez plusieurs centaines de nouvelles sessions SSL par seconde).

  • Il n'y a pas de suite de chiffrement DHE qui utilise RC4.

Résumé: cela m'amène à la liste préférée suivante de suites de chiffrement. Si l'attaque BEAST peut s'appliquer à vous (c'est-à-dire que le client est un navigateur Web), utilisez ceci:

  • Si la session utilise SSL-3.0 ou TLS-1.0, essayez d'utiliser TLS_RSA_WITH_RC4_128_SHA.
  • Si le client prend en charge TLS 1.1+, ou s'il ne prend pas en charge TLS_RSA_WITH_RC4_128_SHA, ou si vous considérez que PFS est plus important pour vous que les attaques actives de type BEAST (par exemple, vous êtes le plus préoccupé par la confidentialité à long terme, pas par les violations immédiates), alors utilisez TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (repli sur TLS_DHE_RSA_WITH_AES_128_CBC_SHA si le client ne prend pas en charge SHA-256).
  • Si les suites de chiffrement DHE ne sont pas prises en charge par le client, utilisez la suite non DHE correspondante.
  • La solution de remplacement générique est TLS_RSA_WITH_3DES_EDE_CBC_SHA qui devrait fonctionner partout.

Notez que les choix ci-dessus supposent que vous pouvez modifier la sélection de suite en fonction de la version du protocole négocié, qui peut ou non être une option disponible pour votre serveur SSL particulier.

Si BEAST ne s'applique pas à vous (le client n'exécutera pas de code hostile), supprimez complètement le support RC4; se concentrer sur AES-128 et SHA-256; repli sur 3DES et SHA-1, respectivement; utilisez DHE si disponible.

29
Thomas Pornin

J'aime la suite de chiffrement proposée par Mozilla (en janvier 2014):

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

source: https://wiki.mozilla.org/Security/Server_Side_TLS

il essaie d'équilibrer performance et sécurité. Cependant, comme recommandé mon Microsoft , je resterais loin de RC4

2
VP.

Où sont les correctifs et à quoi pourraient-ils ressembler? Le seul correctif serait que tous les navigateurs sur toutes les plates-formes pertinentes obtiennent TLS 1.1 ou 1.2 implémenté. Cependant, je ne pense pas que cela se produira pour les plates-formes héritées comme.

Donc pour l'instant, je ne voyais que RC4 comme une solution de contournement, car la plupart des développeurs SW ont manqué de mettre en œuvre les dernières normes TLS dans le passé et maintenant nous sommes pris dans la situation telle quelle.

2
Jui

Mise à jour 2016 via SSL Labs:

Vous devez vous fier principalement aux suites AEAD qui fournissent une authentification forte et un échange de clés, un secret de retransmission et un cryptage d'au moins 128 bits. Certaines autres suites plus faibles peuvent toujours être prises en charge, à condition qu'elles ne soient négociées qu'avec des clients plus anciens qui ne prennent rien en charge de mieux.

Il existe plusieurs primitives cryptographiques obsolètes à éviter:

Les suites Diffie-Hellman anonymes (ADH) ne fournissent pas d'authentification.

  • Les suites de chiffrement NULL ne fournissent aucun chiffrement.
  • Les suites de chiffrement d'exportation ne sont pas sécurisées lorsqu'elles sont négociées dans une connexion, mais elles peuvent également être utilisées contre un serveur qui préfère des suites plus fortes (l'attaque FREAK).
  • Les suites à chiffrement faible (généralement de 40 et 56 bits) utilisent un chiffrement qui peut facilement être brisé.
  • RC4 n'est pas sécurisé.
  • 3DES est lent et faible.

Utilisez la configuration de suite suivante, conçue pour les clés RSA et ECDSA, comme point de départ:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256
EDH-RSA-DES-CBC3-SHA

Remarque Cet exemple de configuration utilise des noms de suite non standard requis par OpenSSL. Pour le déploiement dans d'autres environnements (par exemple, IIS), vous devrez utiliser les noms de suite TLS standard.

Référence: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites

1
bhushan5640

Voyons d'abord les chiffres qui ne tiennent pas compte de l'attaque BEAST.

Je recommande d'utiliser uniquement des chiffrements "actuels" avec des touches fortes, et de ne pas prendre en charge les chiffrements historiques que personne n'utilise de toute façon. Donc pas de RC4 par exemple. De plus, je recommanderais contre les chiffres au niveau des exportations, ceux-ci ont des clés très faibles pour que le gouvernement américain puisse les briser. Bien que je pense que l'exportation de crypto de qualité supérieure n'est plus illégale, le concept existe toujours dans votre configuration de serveur. Enfin, évitez les algorithmes de hachage qui ont de gros problèmes, comme MD5.

Maintenant, l'attaque BEAST .. apparemment, AES en mode CBC tel qu'utilisé dans TLS 1.0 est vulnérable à une attaque de récupération de texte en clair choisie. mail.google.com s'est défendu contre cela en passant rapidement au 128 bits RC4 cette semaine. Si vous êtes très préoccupé par cette attaque dans les 2 semaines à venir (comme le serait google), vous pouvez appliquer la même solution de contournement. Dans d'autres cas, j'attendrais simplement un correctif et configurerais vos chiffres sans tenir compte de cette attaque.

0
chris

Vous pouvez trouver une configuration intéressante pour Apache2 et une forte sélection d'algorithme SSL ici:

Générateur de configuration SSL Mozilla https://mozilla.github.io/server-side-tls/ssl-config-generator/

La recommandation 2019.02 pour les navigateurs modernes est la suivante:

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305: ECDHE-ECDSA-AES12A-SH6-GCS -AES128-GCM-SHA256: ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384: ECDHE-ECDSA-AES128-SHA256: ECDHE-RSA-AES128-SHA256

lisible:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
0
amprantino