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

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 Tout le monde a bien activé TLS sur ses serveurs SMTP ?

33
20
fév.
2014

Parce que cela va être obligatoire en France, a annoncé le premier ministre aujourd'hui (dans un premier temps, uniquement pour les services de l'État et pour les FAI). Donc, pour aider les bons français à suivre ces excellentes directives, je suggère de mettre dans les commentaires des liens vers les meilleurs tutoriels sur la configuration et le test (toujours oublié, le test) de TLS sur Postfix, exim, etc.

Merci de ne mettre que des tutoriels récents (en deux coups de (...)

LinuxFr.org Du chiffrement et de la sécurité sur LinuxFr.org (statut au 24/11/2013)

Posté par (page perso) . Édité par Nils Ratusznik et NeoX. Modéré par patrick_g. Licence CC by-sa
47
25
nov.
2013
LinuxFr.org

En ces temps de PRISM/NSA et autres grandes oreilles, et aussi parce que c'est techniquement intéressant, nous essayons d'avoir sur LinuxFr.org des configurations pertinentes au niveau sécurité (pour nos serveurs et pour vos données genre adresses de courriel). Vous trouverez ci-dessous un petit statut de l'existant et les pistes d'améliorations, et nous sommes bien entendu ouverts à vos propositions sur le sujet.

Au sommaire, d'abord un descriptif de ce qui est commun à nos différents serveurs, puis les spécificités de chacun et quelques questionnements pour ouvrir le sujet.

Journal Google veut réduire la latence sur Internet avec QUIC

47
1
juil.
2013
Ce journal a été promu en dépêche : Google veut réduire la latence sur Internet avec QUIC.

Vous vous souvenez peut être de SPDY, le protocole de Google (déjà évoqué dans ce journal) visant à remplacer HTTP. Google souhaite désormais s'attaquer à la couche en dessous, à savoir TCP, et a pour dans ce sens dévoilé QUIC (Quick UDP Internet Connections) qui se base sur les acquis obtenus lors du développement de SDPY.

Le principal problème auquel veut répondre Google est la latence. S'il est certain que la bande passante va s'améliorer au (...)

LinuxFr.org Certificat SSL/TLS pour serveur web, HTTPS et problèmes associés

Posté par (page perso) . Édité par Bruno Michel. Modéré par Nils Ratusznik. Licence CC by-sa
37
6
juin
2013
LinuxFr.org

Les serveurs utilisent des certificats TLS (ex SSL) pour permettre des échanges chiffrés avec les navigateurs (éviter les écoutes, les modifications, protéger la vie privée, sécuriser des échanges financiers, permettre de vérifier que le serveur est le bon, etc.). Et donc soit on auto-certifie son propre certificat, soit on passe par une autorité de certification (ou une chaîne d'autorités).

Côté client, les autorités acceptées sont gérées soit par le navigateur (Firefox, Chrome, Opéra, un navigateur basé sur java…) et c'est alors spécifique au navigateur , soit le navigateur délègue ça au système (rekonq, konqueror, iceweasel…) et c'est alors spécifique au système.

LinuxFr.org utilise un même certificat sur les différents domaines gérés, dont les serveurs de production et de test, le serveur cache des images, ainsi que le gestionnaire de listes de diffusion. Ce certificat doit être mis à jour sous peu (le 7 juin). Et comme à chaque mise à jour, les mêmes questions vont revenir, c'est donc l'occasion de faire le point sur le sujet (dans la seconde partie de la dépêche).

Journal Vulnérabilités sérieuses dans des dizaines d'applis utilisant TLS (ex-SSL)

33
8
déc.
2012

The Most Dangerous Code in the World : Validating SSL Certificates in Non-Browser Software par Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh et Vitaly Shmatikov

Une excellente étude sur les vulnérabilités des applications utilisant TLS (autrefois nommé SSL), à l’exclusion des navigateurs Web. Des tas d’applications parfois peu connues et discrètes (par exemple pour réaliser la mise à jour des logiciels d’un système) utilisent, comme les navigateurs Web, TLS pour se protéger contre un méchant qui essaierait (...)

Sécurité Faille dans SSL 3.0 et TLS 1.0

Posté par (page perso) . Modéré par patrick_g. Licence CC by-sa
49
25
sept.
2011
Sécurité

Une faille de sécurité dans le protocole SSL 3.0 (et inférieur) et TLS 1.0 a été découverte. Ces protocoles garantissent l’accès chiffré aux serveurs Web. Il n’y a donc plus aucun site Web qui est à l’abri d’une attaque « man in the middle ».

Concrètement, l’attaque consiste à injecter du texte connu dans une page Web (via du JavaScript introduit dans une publicité vérolée, par exemple). Après, il suffit d’écouter la conversion (il faut quand même une session de 30 minutes pour l’exploit actuel) pour découvrir la clef AES. L’exploit permet donc de déchiffrer la page, mais aussi les cookies, et donc de s’identifier sur le site visé.

La faille concerne la version 1.0 de TLS et est corrigée dans la version 1.1, sortie en 2006. En outre, OpenSSL propose un contournement depuis 2004 ; il consiste à injecter des données aléatoires dans la transaction. Malheureusement, les navigateurs utilisent principalement NSS plutôt qu’OpenSSL, et même si sur le serveur on peut forcer l’utilisation de TLS 1.1 ou 1.2, très peu de navigateurs Web les supportent, ce qui freine le déploiement sur les serveurs. Actuellement, seuls IE 9 et Opera en sont capables !

Il faut cependant noter que ces failles sont connues depuis longtemps, c’est ce qui avait mené au correctif dans OpenSSL et à la création de TLS 1.1. Mais c’est la première fois qu’une attaque est publiée, validant ces propositions.

Quelques conseils de navigation :

  • utiliser l’extension Firefox noscript ;
  • actuellement, là où l’attaque pourra faire le plus de dégât, est sur les webmails ou sur les systèmes de paiement tels que Paypal (ben oui, si quelqu’un pirate ma connexion sur LinuxFr.org, ce ne sera pas très grave, car j’utilise différents mots de passe). Privilégiez donc les clients de messagerie électronique comme mutt ou Thunderbird, en désactivant le HTML.

Merci à Altor pour son aide lors de la rédaction de cette dépêche.

C et C++ GnuTLS ajoute le support de DTLS

Posté par . Modéré par Xavier Teyssier. Licence CC by-sa
38
12
avr.
2011
C et C++

GnuTLS est une bibliothèque logicielle libre diffusée sous la licence LGPL 2.1 et plus et écrite en C et C++. GnuTLS implémente les protocoles réseau SSL 3.0, TLS 1.0, TLS 1.1 et TLS 1.2. Ceux-là même utilisés par tous les navigateurs web quand vous surfez en HTTPS.
Une version majeure est en cours de développement, elle ajoute une implémentation du protocole DTLS et améliore la compatibilité avec OpenSSL.