Forum Linux.général [HeartBleed] Quels certificats mettre à jour ?

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
4
27
avr.
2014

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é (…)

Taxonomie des attaques Heartbleed

Posté par  . Édité par Benoît Sibaud, ZeroHeure, Florent Zara et Xavier Teyssier. Modéré par Florent Zara. Licence CC By‑SA.
Étiquettes :
27
23
avr.
2014
Sécurité

Pour ceux qui se demandent encore si ils doivent vraiment changer leurs mots de passe suite à l'affaire Heartbleed, qui veulent comprendre pourquoi il ne fallait pas le faire trop tôt, ou qui n'ont pas vérifié si leur navigateur détecte les certificats révoqués, l'article Taxonomie des attaques Heartbleed recense et explique schématiquement les diverses attaques rendues possibles par le bug, y compris contre les logiciels clients (reverse heartbleed), Tor et les VPN.

logo Heartbleed

« Heartbleed » est une des pires failles qui soient arrivées à la sécurité sur Internet. À cause d'elle, les pirates ont pu ou peuvent obtenir des données confidentielles sans avoir besoin d'intercepter les échanges. Après les premières réactions centrées sur la mise à jour des serveurs web vulnérables, la révocation des certificats et le renouvellement des mots de passe, il a fallu quelques jours de plus pour comprendre que la faille Heartbleed affecte également les logiciels clients, les échanges SSL/TLS autres que HTTPS, et une multitude d'appareils embarqués qui ne recevront jamais de mise à jour logicielle.

Plus de détails dans la suite de la dépêche.

Journal journal bookmark : vers un fork d'OpenSSL ?

Posté par  . Licence CC By‑SA.
Étiquettes :
55
15
avr.
2014

Bonjour Nal,

je t'écris pour te faire part d'un possible fork d'OpenSSL par les développeurs d'OpenBSD qui ont démarré depuis quelques jours un nettoyage complet.

Entre autres :

  • suppression des fonctionnalités heartbeat qui ont conduit au bug de la semaine dernière;
  • suppression de beaucoup de code cryptographique en trop;
  • suppression de wrappers autour de fonctions standard, en particulier pour malloc qui entravait des techniques de mitigation d'exploit

et autres nettoyages divers (cf premier lien), ce qui vu de loin (…)

Journal Heartbleed : petit best of des journalistes

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
70
11
avr.
2014

Aaah, pas facile d'écrire un article sur un sujet aussi technique que le récent bug sur OpenSSL, baptisé Heartbleed, quand on est journaliste généraliste. Forcément, ça donne des erreurs et approximations dans l'article final, ce qui ne manque pas de nous font osciller entre le rire gras et le désespoir, nous, techniciens. Petit tour d'horizon du best of des journalistes sur Heartbleed.

Avant de commencer, notons que je passerai sur les trop nombreuses occurrences de l'adjectif crypté et ses variantes (…)

Nouvelle vulnérabilité dans l’implémentation OpenSSL

Posté par  . Édité par Davy Defaud, Benoît Sibaud, Lucas Bonnet, Bruno Michel et claudex. Modéré par Ontologia. Licence CC By‑SA.
Étiquettes :
86
8
avr.
2014
Sécurité

Une vulnérabilité dans l’implémentation de l’extension heartbeat (RFC 6520) d’OpenSSL a été découverte conjointement par une équipe de chercheurs en sécurité (Riku, Antti and Matti) à Codenomicon et Neel Mehta de Google Securité. On retrouve ici un vieux bogue des familles : le read overrun.

OpenSSL 1.0.1, jusqu’à 1.0.1f inclus, et OpenSSL 1.0.2-beta1 sont affectés. Ce sont les versions utilisées dans la plupart des distributions.

Cette dernière permet la lecture de 64 Kio dans la mémoire des clients et serveurs affectés (mais l’attaque peut être rejouée à chaque heartbeat), autorisant la lecture de données comme les clés privées et, bien sûr, les données échangées une fois ces dernières retrouvées (et ce, même en mode hors ligne s’il n’y avait pas de forward secrecy utilisé).

Il est difficile, voire impossible, de faire une détection post‐mortem d’infiltration, l’attaque ne laissant pas d’entrée suspecte dans le journal système.

Passer à OpenSSL 1.0.1g, redémarrer tous les services utilisant libssl et remplacer l’intégralité de ses certificats (la clef privée étant vulnérable) est donc nécessaire.

Journal Openssl: de battre mon coeur s'est arrété

Posté par  . Licence CC By‑SA.
Étiquettes :
36
8
avr.
2014

Bonjour nal,

Si je prends la plume si précipitamment aujourd'hui, c'est parce qu'il est urgent de t'avertir d'une faille critique dans le code d'une librairie qui t'es chère. En effet, un dépassement de tampon dans l'implémentation Openssl de l'extension "heartbeat" du protocole TLS a été découvert. Je suppose que tu as le coeur brisé par cette nouvelle, mais je t'en supplie, ton sang ne doit faire qu'un tour, et tu dois migrer vers une version sûre, comme la 1.0.1.g.

Journal Quelles solutions adopter pour améliorer un parc existant ? La suite !

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
30
1
fév.
2012

Deux ans plus tard, voici (enfin) un retour sur les choix que j'ai fais rapport à ce que j'indiquais ici.

  • Concernant l'accès aux données: j'ai opté pour le système de fichiers réparti et à tolérance de pannes MooseFS. C'est GPL, stable (il manque toutesfois une vraie recette pour la HA en ce qui concerne le serveur de métadonnées), extrêmement simple à configurer et faire évoluer. L'autre avantage, c'est que vous y accédez comme n'importe quel système de fichiers (…)