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.
LibreSSL 2 est bien lancé
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.
Forum Linux.général LDAP over TLS - unsupported extended operation
Bonjour,
J'ai suivi la création du certificat depuis la page d'openldap (ici: http://www.openldap.org/faq/data/cache/185.html )
J'ai aussi générer un certificat cacert et j'obtient le même résultat.
Lorsque je fais un
root@DB:/etc/ldap# ldapsearch -ZZ
ldap_start_tls: Protocol error (2)
additional info: unsupported extended operation
alors qu'un :
root@DB:~# ldapsearch
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
(…)
Sortie de SFLphone 1.4.0 - Softphone libre pour GNU/Linux
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.
« Triple poignée de main », faille dans le protocole TLS
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.
Journal OpenSSL est mort, vive (le futur) LibreSSL
Salut les jeunes,
Vous n'êtes pas sans savoir qu'OpenSSL, la librairie plus ou moins standard implémentant les protocoles SSL/TLS, a récemment fait beaucoup parler d'elle pour un bug extrêmement grave. La librairie n'en était pas à son premier coup, elle a déjà fait parler d'elle à plusieurs reprises par le passé par sa piètre qualité (j'ai pas vu moi-même, je ne fais que rapporter ce que j'entends sur la toile).
Nouvelle vulnérabilité dans l’implémentation OpenSSL
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 ?
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 (…)
Du chiffrement et de la sécurité sur LinuxFr.org (statut au 24/11/2013)
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
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 (…)
Certificat SSL/TLS pour serveur web, HTTPS et problèmes associés
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)
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 (…)
Faille dans SSL 3.0 et TLS 1.0
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 ajoute le support de DTLS
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.