J'ai publié il y a quelques mois un tuto pour mettre en place "facilement" un serveur XMPP/Jabber avec Prosody et du SSL/TLS plutôt bien configuré sous Debian, j'ai eu pas mal de retours positifs depuis et je pense qu'il pourrait intéresser d'autres personnes.

Suite à la découverte des failles sur OpenSSL, les développeurs d’OpenBSD ont publié les premières versions de leur fork LibreSSL : d’abord la 2.0.0 le 11 juillet 2014, puis la 2.1.0 le 12 octobre et la 2.1.1 le 16 octobre. Elles sont disponibles sur leur site FTP.
Les buts sont de moderniser la base de code, améliorer la sécurité, et appliquer les bonnes pratiques de développement (modernizing the codebase, improving security, and applying best practice development processes).

Plusieurs projets ont déjà cherché à remplacer OpenSSL. Par exemple, LibreSSL est censé fonctionner sous GNU/Linux, Solaris, Mac OS X ou FreeBSD.

L’équipe de développement de SFLphone, client de téléphonie sur internet (User Agent SIP/IAX2), pour GNU/Linux vient d'annoncer la sortie de la nouvelle version 1.4.0. En 2005, Savoir-faire Linux lance le projet de développement d'un softphone : SFLphone. SFLphone est une application libre de téléphonie par Internet, sous licence publique générale GNU version 3, conçue pour fonctionner sur les systèmes d'exploitation GNU/Linux. Elle a été pensée pour les entreprises mais peut être utilisée par tous.

Ce logiciel dispose de fonctionnalités très performantes en téléphonie IP, comme le support des conférences, plusieurs codecs haute définition, et la prise en charge des principaux protocoles de chiffrement des communications (TLS, SRTP/ZRTP). Il permet aussi de diffuser en temps réel plusieurs types de flux vidéo ou de fichiers image et d’activer le partage d’écran en cours d’appel. Il représente aujourd'hui une alternative de plus en plus crédible à Skype.

Après les deux failles mettant en cause l’utilisation d’instructions goto (l’une chez Apple, l’autre chez GNUTLS) et la faille Heartbleed, une vulnérabilité a encore été découverte : Triple Handshake («Triple poignée de main»), aussi appelée 3Shake.

Contrairement aux autres failles, celle-ci ne concerne pas l’implémentation mais le protocole. Cela signifie qu’elle touche potentiellement toutes les implémentations et que la correction définitive de cette faille nécessiterait une modification dans le protocole. En pratique, les corrections ont été effectuées en faisant des vérifications supplémentaires ou en éliminant certains algorithmes de chiffrement.

Logo par @Raed667
Concrètement, cette faille exploite les différents types de poignées de main (handshake, procédure qui permet d’établir les différents paramètres de communication entre deux machines, étape particulièrement importante pour un protocole de sécurité) afin de se faire passer pour une autre machine et d’effectuer une attaque de l’homme du milieu.

La faille est cependant considérée moins grave que Heartbleed, en partie parce qu’elle est compliquée, s’attaque à une configuration assez spécifique et nécessite une position privilégiée entre deux machines.

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.

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.

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).

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.

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.