TLS: désactiver le chiffrement par opposition à ne pas le répertorier

Question

Dans la liste de chiffrement TSL1.2 ci-dessous, pourquoi désactiver explicitement RC4 au lieu de simplement le supprimer de la liste des chiffrements.

ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!RC4 

Quels sont les problèmes provoqués? Tout ce que je devrais faire attention en ce qui concerne la communication SSL client/serveur?

Answer 1

Oui, vous n'avez pas besoin de !RC4 ou même de -RC4, car aucun de vos termes n'ajoute de suites de chiffrement RC4.

Pour être du bon côté, vous pouvez ajouter ou -aNULL!aNULL parce que vos termes ne ajouter de nombreuses suites anonymes. En pratique, la plupart ou la totalité des systèmes auxquels vous vous connectez ne négocient de toute façon aucune suite anonyme, mais il est préférable de s'assurer qu'ils ne le peuvent pas.

Je suppose que par SSL, vous voulez dire le (s) protocole (s) TLS, de préférence au moins la version 1.1. Parce que TLS (à travers 1.2 au moins) est basé sur et très similaire à SSL3 beaucoup de logiciels et de documentation continue à utiliser l'ancien nom, mais vous devez être sûr que vous n'utilisez jamais le protocole SSL3 qui est maintenant sérieusement endommagé par POODLE. pour éviter TLS1.0 qui a le défaut exposé-IV qui a été exploité par BEAST bien que la plupart des piles atténuent maintenant BEAST adéquatement en utilisant 1/n (ou parfois 0/n) la division d'enregistrement. Et le GCM ciphersuites vous préfèrent (en les mettant en premier) ne fonctionnent que dans TLS1.2 (ou 1.3 si et quand il est finalisé et mis en œuvre).

Autres considérations plus générales:

• si vous êtes le serveur, posséder et configurer au moins un type (RSA, DSA, ECDSA) de privatekey qui est suffisamment forte, générée correctement et protégé contre non autorisé divulgation, et une chaîne de certificats correspondante d'une autorité de certification que le ou les clients feront confiance, en utilisant des signatures suffisamment fortes (actuellement sha256 ou mieux avec RSA-2048 DSA-2048 ECC-224 ou mieux), et pour la plupart des protocoles d'application (comme HTTPS) contenant le (s) nom (s) d'hôte correct (s). Étant donné que RSA est l'algorithme le plus souvent certifié par les autorités de certification, le seul qui peut couvrir tous les termes clés que vous avez eu la peine d'ajouter, et le seul couvert par les instructions copiées sur des milliards de sites Web par des personnes t les comprendre et donc ne peut pas les améliorer, vous voulez probablement RSA.

• Si vous êtes le client, vérifiez la chaîne de certificats du serveur par rapport aux autorités de certification fiables et, le cas échéant, au nom d'hôte. Notez qu'OpenSSL toujours (à moins qu'il ne soit surchargé) effectue la vérification crypto standard (signature) et la syntaxe (BC KU EKU policy etc) dans un truststore fourni (racines ou éventuellement ancres), mais le client via 1.0.2 ne vérifie pas le nom d'hôte pour vous , et 1.1.0 ne le fait que si vous le configurez explicitement. OpenSSL ne vérifie pas les CRL par défaut et ne les récupère pas, ne récupère pas OCSP, et AFAICS ne vérifie même pas encore OCSP agrafé, donc devrait ajouter au moins certains d'entre eux, mais je ne pense pas que beaucoup de développeurs faire. Dans les rares cas où l'authentification client alias client cert [ificate] est utilisée, miroir: le client qui souhaite ou accepte de s'authentifier doit posséder et utiliser une chaîne privée et une chaîne de certificats appropriées, et le serveur doit le vérifier mais généralement pas hostname et certainement pas en utilisant l'agrafage.Si vous êtes le serveur, configurez des paramètres DHE (appelés tmp_dh) suffisamment forts et générés correctement - 2048 bits est maintenant la norme, à moins que vous ayez à faire face à des clients obsolètes (comme Java 7) qui ne peuvent pas gérer il; et en fonction des paramètres ECDHE de la version OpenSSL (appelés tmp_ecdh) - P-256 ou P-384 est généralement le meilleur. 1.0.2+ peut et doit être configuré pour choisir ECDHE basé sur ClientHello 'auto'matically; ci-dessous pour ECDHE, et dans toutes les versions pour DHE, si vous ne configurez pas les paramètres, les ciphersuites associées ne seront pas utilisées même si vous les avez configurées comme préférées. Si vous êtes un client, essayez de vérifier ce qui précède, bien qu'il soit trop difficile de vérifier quoi que ce soit sur les paramètres DHE autres que la taille brute sans information de génération (SSL/TLS non intégrée à la bande). Dans le cas très rare des paramètres EC «explicites» (non nommés) pour ECDHE, la vérification est trop difficile, mais pour les courbes nommées et en particulier les communes (P-256 et P-384 bénis par l'ancienne Suite B), vous pouvez compter sur la communauté (ouverte) ayant concentré son attention sur eux. N'utilisez pas la compression SSL/TLS si vous envoyez des données sensibles (comme des cookies) dans le même enregistrement que des données influencées par l'attaquant. Beaucoup de piles jamais permettent la compression SSL/TLS, puisque la compression au niveau de l'application peut généralement mieux fonctionner et moins cher pour les applications qui en ont besoin, par exemple. HTTP [S].