298 private links
Voilà un bon programme en place ! Merci Mozilla. :-)
Très bon article expliquant en détails la distribution GNU/Linux "TAILS", acronyme pour “The Amnesic and Incognito Live System”.
Via Le Journal du Hacker https://www.journalduhacker.net/s/ktdvdy/d_couverte_du_syst_me_d_exploitation_tails
Mise à jour d’OpenSSL, avec les versions 1.0.2h et 1.0.1t, depuis le 3 mai.
Liste des différentes failles : https://openssl.org/news/secadv/20160503.txt
« Ces informations piratées concerneraient des passeports et des empreintes digitales, enregistrées pour vérifier l’identité des votants. » « 15,8 millions d’empreintes digitales publiées »
Oh mais ouuuuiiii, c’est vraaaiiii, c’est sécuriséééééé, les empreintes digitaaaaaales, les empreintes biométriiiiques, tout çaaaaa.
… Sérieusement, non, les empreintes biométriques, c’est nul, POINT !
- La "sécurité" du TouchID de l’iPhone 5S d’Apple est cassée (au moment de sa sortie) https://links.thican.net/?cmCDag
- Tutoriel pour falsifier une empreinte digitale https://links.thican.net/?cBgS7g
- Et enfin, des explications concernant la piètre qualité d’une authentification basée sur des données biologiques https://links.thican.net/?DzNvdg
Puisque j’oublie souvent, voilà une méthode simple pour générer un champ SSHFP :
ssh-keygen -r <fqdn> -f <file>
en remplaçant "<fqdn>" par votre nom de domaine avec le nom de votre machine, comme "foo.example.com", et "<file>" par le chemin vers le fichier.
Pour recréer à partir d’OpenSSL https://unix.stackexchange.com/questions/121880/how-do-i-generate-sshfp-records#133957
Un nouveau coup dure pour l’anonymat.
Toutefois, je comprends le conseil de l’ANSSI, mais ce n’est pas une solution acceptable.
Pour infos, la liste des nœuds de sortie est disponible ici :
https://check.torproject.org/exit-addresses
Un petit rappel concernant DKIM, un protocole qui permet de vérifier l’authenticité d’un courriel.
TL;DR: NE PAS utiliser des clefs de moins de 1024 bits.
Toutefois, ma question concernait une taille de clef plus longue, comme 2048 ou 4096 comme utilisées pour les certificats TLS, si ça risque de poser problème avec les tailles des requêtes DNS.
Oh non …
Cette mise à jour d’OpenSSL supprime des fonctionnalités et ainsi des symboles dans les binaires. Du coup, l’ensemble, voire la totalité des programmes utilisant OpenSSL deviennent cassés, et doivent être recompilés.
En même temps, cette mise à jour corrige de nombreuses failles et bulletins de sécurité, il ne faut pas l’ignorer.
https://www.openssl.org/news/secadv/20160301.txt
Voici le lien vers le message d’annonce de cette nouvelle version, qui indique que SSLv2 est supprimé, en plus d’être désactivé (euh ?).
https://marc.ttias.be/openssl-announce/2016-03/msg00002.php
EDIT 23:09+01:00: un article en français, parlant de l'attaque DROWN (Decrypting RSA using Obsolete and Weakened eNcryption) http://www.numerama.com/tech/149306-drown-un-tiers-des-serveurs-https-est-vulnerable-a-une-nouvelle-faille-critique.html
Avec un site Web, et un outil :
https://drownattack.com/
https://github.com/nimia/public_drown_scanner
Plus d’articles :
http://www.zdnet.com/article/dont-let-your-openssl-secured-web-sites-drown/
EDIT 2015-03-05 : Article de Bortzmeyer https://www.bortzmeyer.org/drown.html
Des conseils pour stocker correctement, de nos jours, les mots de passe, dans différents langages.
(Via SebSauvage http://sebsauvage.net/links/?50sqeQ)
Note : billet très technique, je n'ai pas forcément les connaissances pour bien l'appréhender.
Un message concernant les risques possibles à utiliser l'outil Address Sanitizer (ASan https://en.wikipedia.org/wiki/AddressSanitizer) dans un environnement de production, comme une élévation de privilège puisque ce dernier peut exécuter du code binaire avec setuid sans vérifier les variables d’environnement.
Un brouillon concernant TLSv1.3.
D'ailleurs, pour pouvoir profiter de Forward-Secrety, il suffit de retirer le chiffrement RSA pour l'échange de clefs symétriques, avec "!kRSA", comme ceci (liste fonctionnant avec OpenSSL en version 1.0.2f actuellement) :
HIGH:!kRSA:!DHE:!DH:!SSLv3:!SSLv2:!RC4:!aNULL:!eNULL:!EXPORT:!3DES:!DES:!SHA1:!MD5
Pour retirer le chiffrement AES128, il suffit de rajouter ":!AES128" à la liste, mais les navigateurs actuels ne fonctionnent pas sans.
Oh … Aïe, quoi. Ça a l'air plus que sérieux …
C'est étrange, ça rappelle énormément la faille GHOST, en janvier 2015, soit un an : https://links.thican.net/?Y8L6Ag
Plus de liens :
- en français sur le site Web Developpez.com : http://www.developpez.com/actu/96101/Une-autre-faille-critique-de-securite-a-ete-decouverte-dans-glibc-et-rend-les-machines-sous-Linux-vulnerables-a-l-execution-d-un-code-a-distance/
- https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
- en français sur Linuxfr.org https://linuxfr.org/users/bortzmeyer/journaux/faille-de-securite-dans-la-gnu-libc-avec-les-requetes-dns
« Après analyse scientifique, seuls 11 coups de feu sont attribués aux terroristes contre près de 1500 du côté de la police d'élite. »
« Pire encore : certains policiers sont blessés par leurs propres collègues. Même le chien policier, Diesel, aurait été tué par erreur. »
Hé ben, pas brillant ; pire même, vu les honneurs qui ont été fait médiatiquement, alors que de nombreux doutes planaient déjà aux lendemains de cet assaut.
Un site qui regroupe une liste de configurations concernant le chiffrement (SSL/TLS) pour différents services.
Voici un document au format PDF pour aider à la mise en place et configuration du système DNSSEC avec le logiciel BIND9.
Copie : https://thican.net/~thican/bind_dnssec-guide.pdf
Voir aussi le manuel de référence d'administration de BIND9 (version 9.10.2) : ftp://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.pdf
(copie : https://thican.net/~thican/bind_Bv9ARM.pdf)
Ce petit billet me sert principalement de garde-mémoire, je ne vais donc pas détailler ce qu'est le champ TLSA et son but ; ceci est détaillé dans la RFC6698 “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA” (https://tools.ietf.org/html/rfc6698)
Principalement, ce qui nous intéresse, c’est de fournir soit l’empreinte de la clef, soit l’empreinte du certificat ; c’est ce que définit le champ "Selector" (section 2.1.2).
Remarque : j’ai considéré par défaut que nous sommes dans le cas d’un "DANE-EE: Domain Issued Certificate", valeur "3" du champ "Certificate Usage" (section 2.1.1).
-
Si vous souhaitez uniquement donner l’empreinte de votre clef (valeur "1" dans le "Selector Field"), utilisez les valeurs "3 1 1" et "3 1 2" respectivement pour les hashs SHA256 et SHA512 ;
Ensuite, vous pouvez au choix déterminer les hashs (SHA256 et SHA512) à partir de la clef privée (n’oubliez pas l’option -pubout, voir openssl pkey(1))
openssl pkey -outform DER -pubout -in "/path/to/private.key" | openssl dgst -sha256
openssl pkey -outform DER -pubout -in "/path/to/private.key" | openssl dgst -sha512
OU, en alternative, déterminer les hashs (SHA256 et SHA512) à partir d'un certificat (c’est ainsi de cette façon qu’un tiers peut vérifier)
openssl x509 -noout -pubkey -in "/path/to/certificat_file.pem" | openssl pkey -outform DER -pubin | openssl dgst -sha256
openssl x509 -noout -pubkey -in "/path/to/certificat_file.pem" | openssl pkey -outform DER -pubin | openssl dgst -sha512 -
Par contre, si vous souhaitez fournir l’empreinte complète du certificat, utilisez les valeurs "3 0 1" et "3 0 2" respectivement, et exécutez :
openssl x509 -noout -fingerprint -in "/path/to/certificat_file.pem" -sha256
openssl x509 -noout -fingerprint -in "/path/to/certificat_file.pem" -sha512
Ensuite, créer une entrée DNS dans votre zone, en suivant la sémantique suivante :
<port>.<protocole>.<nomdedomaine> IN TLSA <X Y Z> <hash>
Par exemple, pour avoir le hash du certificat pour le service HTTPS, donc le protocole TCP qui répond au port 443, sur la machine foo.example.com, le résultat est "_443._tcp.foo.example.com." (ne pas oublier le dernier point à la fin).
Et pour les valeurs <X Y Z> :
X → https://tools.ietf.org/html/rfc6698#section-2.1.1 : la valeur "3" indique que ce sont des informations avec le certificat le plus proche.
Y → https://tools.ietf.org/html/rfc6698#section-2.1.2 : exporter la clef est plus simple, de ce que j’ai compris.
Z → https://tools.ietf.org/html/rfc6698#section-2.1.3 : "1" pour le hash SHA256, "2" pour le hash SHA512.
Concernant le hash, n'oubliez pas de supprimer les doubles-points (par exemple : echo $hash | tr -d ':')
Sources :
Autre outil (mais en anglais) concernant les noms de domaine, en particulier pour la mise en place du DNSSEC.
Très pratique pour détecter les erreurs.
L'information apparue ce jeudi 19 mars indique la présence d'une douzaine de failles corrigées, et de nouvelles versions dites à jour :
1.0.2a, 1.0.1m, 1.0.0r et 0.9.8zf