GuiGui's Show

DANE :
  - Théorie : https://tools.ietf.org/html/rfc6698
  - Théorie/pratique : http://www.bortzmeyer.org/6698.html

Je trouve DANE très intéressant et prometteur donc je suis ça de loin depuis environ 1 an et demi. Pour l'instant, le plus gros problème, c'est l'absence de support de la part des navigateurs web, des serveurs de mails, des clients mails, des serveurs XMPP, ... bref, de tout ce qui manipule du TLS. Ensuite, le plus gros problème sera l'encore faible déploiement de DNSSEC (pré-requis de DANE).

Il y a 1 an environ, j'ai réalisé une maquette. Il y avait beaucoup d'outils disponibles pour créer des enregistrements, les valider plus ou moins partiellement et surtout, beaucoup d'outils (notamment des extensions Firefox) qui ne fonctionnaient pas. Difficile de créer une maquette réaliste, ce qui m'a conduit à lâcher l'affaire (je veux produire une maquette réaliste en vu d'un déploiement futur, voir comment se compte les vrais logiciels, toussa).

Il y a 6 mois environ, j'apprenais que la version 2.11.0 de Postfix apporte le support de DANE. Et je prévoyais un test grandeur nature dans ma TODO.

C'est aujourd'hui fait. Un bête postfix installé depuis les backports tentera d'envoyer un mail à un serveur mail situé dans un domaine signé qui a un enregistrement TLSA pour le certificat x509 utilisé par le serveur de mail de ce domaine.

L'installation d'un serveur mail à l'arrache ne pose pas problème, le bypass de la politique de sécurité réseau (pas de port 25 en sortie) se fait avec un VPN ARN, la création d'un enregistrement de type TLSA en utilisant openssl (voir l'article de Stéphane Bortzmeyer) pour générer le rdata ne pose pas problème, ...

Ce qui pose problème, c'est OpenDNSSEC qui refuse de re-signer la zone : « error parsing RR at line 27 (Syntax error, could not parse the RR's rdata) ». Solution : http://lists.opendnssec.org/pipermail/opendnssec-user/2012-December/002310.html -> « OpenDNSSEC depends on LDNS for supported RRtypes. You should link against ldns 1.6.16 if you want to do TLSA. ». Or, dans Debian Stable, c'est la version 1.6.13 so game over. Non, hors de question que je mette à jour mon OpenDNSSEC à partir des backports, j'ai déjà donné. :)

Utiliser un type inconnu (« TYPE52 ») ne permet pas de tromper OpenDNSSEC. ÉDIT DU 14/11/2016 À 12H15 : Parce qu'il ne suffit pas de changer le type, il faut aussi encoder le RDATA dans un format bien défini. Voir la section 5 du RFC 3597 (https://www.rfc-editor.org/rfc/rfc3597.txt ). FIN DE L'ÉDIT.

Mettre à jour seulement libdns1 casse une dépendance entre le signer (composant d'OpenDNSSEC) et cette librairie et le signer ne peut plus être lancé : « /usr/sbin/ods-signerd: symbol lookup error: /usr/sbin/ods-signerd: undefined symbol: strlcpy ».

Impossible de signer "ailleurs" avec le signer de BIND, par exemple puisque les parties privées des clés sont enfermées dans le SoftHSM. Alors oui, j'aurais pu installer un OpenDNSSEC récent "ailleurs" et exporter le contenu du SoftHSM ... mais non merci. :)

Je remets donc le test de DANE en conditions réelles dans ma TODO. :)

Bref : DANE en production, ce n'est pas encore pour tout de suite : manque de support dans les versions stables et packagées des logiciels + manque de support dans OpenDNSSEC.

C'est comme https://www.ssllabs.com/ mais pour tester le support TLS d'un serveur Jabber (c2s et s2s). C'est lent et limité à deux tests (un c2s, un s2s) par heure mais ça fait le job.

Sur mon serveur perso, les seuls problèmes remontés sont : absence d'enregistrement TLSA (en même temps il n'y a aucun serveur ni client jabber qui supporte DANE ...), certificat auto-signé, ssl v3 autorisé et des ciphers faibles autorisés.

Parlons de la config ejabberd. Pour le détails des directives de configuration, c'est par ici : http://www.process-one.net/docs/ejabberd/guide_en.html#listened-module
  - Pour activer/désactiver le support de certains protocoles (ssl v2/v3 TLS v1/1.1/1.2), c'est la directive globale « s2s_protocol_options » et la directive locale au bloc « ejabberd_c2s » nommée « protocol_options ». Ça arrive dans la version 14.05 donc ce n'est pas encore dans Debian Stable. Source : http://chatlogs.jabber.ru/ejabberd@conference.jabber.ru/2014/05/24.html. Apparemment, le séparateur si plusieurs options devrait être « | ». Actuellement, ssl v2 est désactivé, tout le reste est activé.

  - Pour changer la liste des ciphers utilisés, c'est la directive globale « s2s_ciphers » et la directive locale au bloc « ejabberd_c2s » nommée « ciphers ». Ça arrive dans la version 13.12 donc ce n'est pas encore dans Debian Stable. Source : http://www.ejabberd.im/ejabberd-13.12 et http://chatlogs.jabber.ru/ejabberd@conference.jabber.ru/2014/05/24.html. La valeur est un classique commun à ce type de réglage dans les autres softs : openssl ciphers.

  - Pour info, il y a eu un renommage donc la version 14.05 (Ubuntu style) c'est bien après 2.1.X :)

Une des explications du terme datalove. L'autre étant : http://datalove.me/ (pages principles et about). Oui, la deuxième est une prolongation de la première.

Je connais quelques commandes OpenSSL en intégralité mais je suis incapable de me souvenir de celle permettant d'obtenir le fingerprint d'un certificat x509 :

openssl x509 -in certif.crt -fingerprint -noout -sha1

-sha1 peut être remplacé par -sha256

Comment monter un proxy RADIUS. Pour les lignes de conf' qui juste fonctionnent pour un cas banal (pas de multi/failover/cluster/autre), c'est par là : http://uk-corp.org/Books/OReilly%20Books/radius/html/radius-chp-6-sect-2.html

Ne pas oublier :
  - de changer le délimiteur si pas banal (différent de '@' ou '/' quoi). Exemple : « realmpercent » dans la section « authorize » du sites-enabled/default + prise en charge dans le module realm.

  - d'ajouter le proxy RADIUS comme client dans le clients.conf du RADIUS final (vers lequel les requêtes seront forwardées)

  - de vérifier l'activation du mode proxy dans le fichier radiusd.conf :
    « proxy_requests  = yes
       $INCLUDE proxy.conf »

  - de vérifier les options disponibles comme nostrip (ne pas supprimer le realm dans la requête forwardée).

Hahahaha la loi pour faire bonne figure mais qui, dans les faits, ne servira à rien et ne changera rien :
- Les employés de prestataires d'une agence de renseignement ne sont pas couverts. Et une taupe fonctionnaire, j'ai du mal à imaginer qu'on lui confie d'autres missions voire même qu'on ne le pousse pas à la démission après ses révélations.

- La révélation n'est autorisée que vers certaines personnes (« au directeur ou à l'inspecteur général de son agence (CIA, NSA, etc), au directeur national du Renseignement, ou aux parlementaires membres des commissions du Renseignement ») qui pourront sûrement ignorer le problème (fermer les yeux) sans être sanctionné.

- Les révélations peuvent porter uniquement sur des thématiques précises (« des violations des lois fédérales, des utilisations frauduleuses de fonds ou toute activité mettant en danger le public. »). Le lanceur d'alertes devra donc prouver que ses révélations entrent bien dans ces thématiques, j'en suis sûr. Les révélations Snowden font-elles partie d'activités mettant en danger le public ? C'est subjectif tout ça ...

Ok, -f, mysql -f -u <user> -p <table> < dump.sql pour importer un dump foireux ou utiliser un script de création de base foireux qui crée deux fois des colonnes et des index ... MySQL affiche les erreurs rencontrées mais elles ne sont plus bloquantes.

Les pages 4 et 5 sont intéressantes.

Je croyais que les ports au format SFP sur un équipement réseau servaient uniquement à sortir sur des GBIC et donc de la fibre. J'ignorais qu'il existe des câbles cuivre en 10G Ethernet au format SFP. Moins coûteux que les liaisons optiques pour une courte distance (intra-baie, baie accolée, ...). Et puis j'en ai vu en prod' ... Illustration : http://www.sfpex.com/image/cache/data/pd/EX-SFP-10GE-DAC-1M-500x500.jpg

Recensement d'une partie des attaques par réflexion+amplification DNS. Interface bien conçue.

Dans la même veine mais manuel (donc moins (ré)actif) : http://dnsamplificationattacks.blogspot.fr/2014/05/domain-magasbslrpgcom.html

Ça fait un moment que je n'avais pas utilisé dig pour vérifier la bonne configuration d'un transfert de zone + TSIG.

J'avais oublié la syntaxe :
dig @<master> <nom_zone> axfr -y '<algo>:<nom_clé>:<base64_clé>'

L'algo est facultatif si hmac-md5 est utilisé (ce qui est mal !).

Source : ftp://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/man.dig.html ;)