Bonjour à tous,
j'ai suivi avec intérêt l'affaire HeartBleed, mais je n'arrive pas à savoir concrètement quels sont les certificats que je dois mettre à jour sur mes postes clients et sur mes serveurs.
J'utilise la distribution Debian 7.0 Wheezy, mise-à-jour régulièrement.
Cependant, dans mon répertoire /etc/ssl/certs, la quasi totalité de mes certificats datent de 2010 à 2013 !!!
Puis-je les détruire sans craindre de ne plus accéder à certains services ?
Par ailleurs, puis-je détruire sans soucis le fichier /etc/ssl/private/ssl-cert-snakeoil.key ?
Côté SSH,j'imagine que je dois régénérer mes fichiers :
- /etc/ssh/ssh_host_rsa_key;
- /etc/ssh/ssh_host_dsa_key;
- /etc/ssh/ssh_host_ecdsa_key.
Mais, est-ce suffisant pour sécuriser SSH ?
Pour Apache2, la régénération du fichier /etc/apache2/ssl/apache.pem suffit-elle si c'est le seul fichier utilisé par mes hôtes virtuels ?
Y-a-t'il globalement d'autres certificats à mettre à jour que ceux de /etc/ssl et /etc/ssh ?
Voilà, si vous pouvez m'éclairer sur ces différents points ?
Merci.
# SSH != SSL
Posté par gouttegd . Évalué à 7.
Déjà, les clefs SSH ne sont pas concernées par Heartbleed. Heartbleed est une faille dans l’implémentation du protocole TLS, qui n’a rien à voir avec SSH (même si des notions de cryptographie sous-jacentes aux deux protocoles sont communes).
OpenSSH utilise une partie de OpenSSL (libcrypto, justement pour les fonctions cryptographiques), mais pas celle impliquée dans la faille Heartbleed.
De quels certificats parles-tu ? Si tu parles des certificats racines fournis avec ta distribution (paquet
ca-certificatessous Debian), ce ne sont pas tes certificats et ce n’est pas à toi de les renouveller, mais aux autorités de certifications qui les ont émis. Et encore, les certificats racines ne sont vraisemblablement même pas concernés non plus, parce que j’ose espérer que les autorités de certification conservent les clefs privés de ces certificats à l’abri sur des machines qui ne sont pas directement accessible depuis l’Internet (enfin, ça, c’est si les CA prenaient leur job au sérieux).Les certificats que tu dois révoquer et remplacer sont ceux que tu as généré, fait signer (ou signé toi-même) et utilisé pour protéger n’importe quel service utilisant TLS.
[^] # Re: SSH != SSL
Posté par libresurf (site web personnel, Mastodon) . Évalué à 2.
Merci gouttegd pour cette réponse très instructive.
Je n'avais en effet pas compris que SSH n'était pas impliqué par la faille Heartbleed. C'est déjà ça en moins à mettre à jour.
En effet, la plupart des certificats du répertoire /etc/ssl/certs proviennent du parquet ca-certificates. Donc à priori d'après ce que tu rapportes, pas besoin de s'en soucier.
Si seuls les certificats SSL que j'ai générés sont à révoquer, la tache n'est pas si terrible que ça. Je pensais que le problème était plus global et qu'il fallait également mettre à jour l'ensemble des certificats présents sur mes postes et serveurs.
Merci encore.
[^] # Re: SSH != SSL
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Il n'y a que les clefs privés, voir les mots de passe qui craignent vraiment, pas la partie publique…
Si ta machine était sur le net ET avait un serveur utilisant TLS (je ne sais pas si SSLv3 était touché), alors toute zone mémoire a pu être touchés DONT la clef SSH et les mots de passe.
Donc, oui, tu peux avoir a changer la clef SSH de certains serveurs. Après, il faut voir parce que si tu as mis à jour rapidement, je ne suis pas sur que les petits aient été attaqués. Par exemple, dans mon université, il a pour le moment été décidé de ne pas ré-initialiser les 40000 mot de passe ! Cela peut être plus facile à dire qu'à faire.
[^] # Re: SSH != SSL
Posté par gouttegd . Évalué à 4.
Toute zone mémoire appartenant au(x) processus utilisant OpenSSL. La faille ne remet pas en cause l’isolation des processus (qui est assurée par le noyau, pas par OpenSSL), elle ne permet pas de se promener dans la mémoire d’un processus autre que celui qui reçoit le paquet TLS Heartbeat.
Même en étant très paranoïaque, je ne peux imaginer aucune raison de craindre que les clefs privées SSH se retrouvent dans la mémoire des processus utilisant TLS (serveurs web, serveurs de courrier, etc.).
Là d’accord, mais encore une fois, uniquement ceux qui transitent par le serveur TLS (mot de passe de connexion à la partie privée d’un site web par exemple, ou à un compte mail). Les mots de passe SSH sont hors de portée.
[^] # Re: SSH != SSL
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
J'ai été un peu rapide effectivement… car je pensais mdp au début utilisé sur les intranets https… Heureusement, ici on est protégé par la mémoire qui n'est plus partagé par défaut depuis le 80286 il me semble.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.