Heartbleed signifie-t-il de nouveaux certificats pour chaque serveur SSL?
Si vous n'avez pas entendu parler du Heartbleed Bug , c'est quelque chose à regarder immédiatement. Cela signifie essentiellement qu'un attaquant peut exploiter une vulnérabilité dans de nombreuses versions d'OpenSSL pour pouvoir accéder à la clé privée d'un serveur . Ce n'est pas une menace théorique, c'est une menace démontrable et reproductible. Voir le lien ci-dessus pour plus d'informations.
Je pense que la plupart des organisations se posent la question suivante:
Chaque entreprise doit-elle désormais créer de nouvelles paires de clés publiques/privées et demander à son autorité de certification d'invalider les paires de clés signées d'origine?
Cela signifie beaucoup plus que de nouveaux certificats (ou plutôt de nouvelles paires de clés) pour chaque serveur affecté. Cela signifie également:
- Patcher les systèmes affectés sur OpenSSL 1.0.1g
- Révocation des anciennes paires de clés qui viennent d'être remplacées
- Changer tous les mots de passe
- Invalidation de toutes les clés de session et cookies
- Évaluer le contenu réel géré par les serveurs vulnérables qui aurait pu être divulgué et réagir en conséquence.
- Évaluer toute autre information qui aurait pu être révélée, comme les adresses mémoire et les mesures de sécurité
Résumé de heartbleed.com (accent sur le mien):
Quel est le matériel de clé primaire qui a fui et comment le récupérer?
Ce sont les joyaux de la couronne, les clés de cryptage elles-mêmes . Des clés secrètes qui ont fui permettent à l'attaquant de décrypter tout trafic passé et futur vers les services protégés et d'usurper l'identité du service à volonté. Toute protection accordée par le chiffrement et les signatures dans les certificats X.509 peut être contournée. La récupération de cette fuite nécessite de corriger la vulnérabilité, de révoquer les clés compromises et de réémettre et redistribuer de nouvelles clés. Même en faisant tout cela, le trafic intercepté par l'attaquant dans le passé restera toujours vulnérable au déchiffrement. Tout cela doit être fait par les propriétaires des services.
Qu'est-ce que le matériel de clé secondaire qui a fui et comment le récupérer?
Ce sont par exemple les informations d'identification de l'utilisateur (noms d'utilisateur et mots de passe) utilisées dans les services vulnérables. La récupération de ces fuites nécessite d'abord que les propriétaires du service rétablissent la confiance dans le service conformément aux étapes décrites ci-dessus. Après cela, les utilisateurs peuvent commencer à changer leurs mots de passe et les clés de cryptage possibles selon les instructions des propriétaires des services qui ont été compromis. Toutes les clés de session et les cookies de session doivent être invalides et considérés comme compromis.
Qu'est-ce qu'un contenu protégé divulgué et comment le récupérer?
Il s'agit du contenu réel géré par les services vulnérables . Il peut s'agir de détails personnels ou financiers, de communications privées telles que des e-mails ou des messages instantanés, des documents ou tout autre élément qui mérite d'être protégé par cryptage. Seuls les propriétaires des services pourront estimer la probabilité de ce qui a été divulgué et ils doivent en informer leurs utilisateurs en conséquence. La chose la plus importante est de restaurer la confiance envers le matériel de clé primaire et secondaire comme décrit ci-dessus. Seulement cela permet une utilisation sûre des services compromis à l'avenir.
Qu'est-ce qu'une garantie fuite et comment récupérer?
Les garanties fuites sont d'autres détails qui ont été exposés à l'attaquant dans le contenu de la mémoire qui a fui. Ceux-ci peuvent contenir des détails techniques tels que des adresses mémoire et des mesures de sécurité telles que des canaris utilisés pour se protéger contre les attaques par débordement. Ceux-ci n'ont qu'une valeur contemporaine et perdront leur valeur pour l'attaquant lorsque OpenSSL aura été mis à niveau vers une version fixe.
Il s'agit du pire des cas, comme décrit par Codenomicon qui a créé le site Web cité.
La description de la vulnérabilité "brute" est:
Une vérification des limites manquantes dans la gestion de l'extension de pulsation TLS peut être utilisée pour révéler jusqu'à 64 Ko de mémoire à un client ou un serveur connecté. ( OpenSSL )
Je ne dis pas qu'ils sont allés trop loin, c'est IS très très mauvais, mais:
- Vérifiez votre version d'OpenSSL (toutes les versions ne sont pas affectées).
Encore mieux, testez-le:
openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safeOu utilisez http://filippo.io/Heartbleed/
Ensuite, si vous utilisiez Perfect Forward Secrecy (PFS), les données échangées ne peuvent pas être déchiffrées, sauf si un MITM a été effectué.
Pour effectuer une attaque MITM, le pirate informatique devait connaître la vulnérabilité et l'exploiter avec succès. Un attaquant peut essayer d'accéder à des morceaux aléatoires de mémoire de 64ko sans être remarqué, ce faisant, il devrait pouvoir finir par récupérer une partie de la mémoire où la clé privée est stockée.
Pour répondre à la question, si vous êtes vulnérable au bug Heartbleed. Oui, vous devez changer vos clés privées et certificats. Et si vous voulez être prudent, vérifiez environ 2 ans de fichiers journaux pour vous assurer que personne n'a utilisé Heartbleed sur votre site ou effectuez simplement et en toute sécurité les opérations déjà mentionnées.
Le problème de l'utilisation d'un nouveau certificat/clé SSL pour tous les serveurs est souvent surestimé. Vous devez assumer
- Il existe un pirate qui connaît le Heartbleed avant que vous ayez corrigé l'opensl
- Il/elle souhaite pirater vos serveurs, pas d'autres sites Web populaires
- Il/elle a la possibilité d'extraire la clé privée de la mémoire du serveur 64K, il/elle devrait être un hacker très sophistiqué
- Il/elle peut intercepter le réseau local (utilisateur/serveur) et capable de décrypter le trafic
Compte tenu de toutes les conditions, vous jugez que vous devez mettre à jour le certificat/clé SSL.
Je ne vous dis pas ne devrait pas, je dis juste parfois des gens dans l'interweb écoutant aveuglément les autres et disant que si vous ne le faites pas, votre site sera piraté à 100%, c'est juste du FUD , A MON HUMBLE AVIS
Si la personne collecte ces 64 000 éléments de données jusqu'à ce qu'elle capture enfin la clé privée, elle peut alors déchiffrer tout ce qu'elle a collecté (et en collecter davantage). C'est ainsi qu'un attaquant peut récupérer des noms d'utilisateur et des mots de passe sans être un MITM. Si la personne peut obtenir la clé privée, le reste est assez facile.