mercredi 5 septembre 2012

TLDs compatibles IPV6

Suite a un message aperçu sur Twitter, un petit script de survey sur la compatibilité IPv6 des NS des TLD (annoncée, pas testée):

#!/bin/bash

for tld in `curl http://data.iana.org/TLD/tlds-alpha-by-domain.txt |grep -v '#'`
do
    echo -n "$tld"
    YES=0
    NO=0
    TOTAL=0
    for dns in `dig +short -t ns $tld`
    do
        let TOTAL++
        if
            dig -t aaaa $dns 2>&1 |grep "ANSWER: 0" >/dev/null
        then 
            let NO++
        else 
            let YES++
        fi
    done
    echo " $YES $NO $TOTAL"
done

Quelques résultats:

Nombre de TLD: 315
TLD sans aucun NS avec AAAA: 47
TLD avec AAAA pour tous les NS: 55
TLD avec AAAA pour certains NS: 213


mercredi 11 juillet 2012

Merci la poste

Sans oublier que le facteur a encore eu la flemme de monter 3 étages a pied, et a préféré se dire que personne n'etait la et laisser un avis de passage.


dimanche 8 avril 2012

Passage d'une zone en DNSSEC avec BIND et Gentoo

DNSSEC c'est le bien. Il a le potentiel de protéger vos communications bien mieux que le fiasco anarchique et surévalué des autorités de certification actuelles.

Or jusqu'à il y a peu de temps, Gandi offre enfin la possibilité d'annoncer ses clefs en amont, et d'avoir ainsi "the real thing". Ce n'est pas trop compliqué a faire.

D'abord, vérifier que net-dns/bind et net-dns/bind-tools sont a jour. (9.7 était problématique chez moi)

Créer un répertoire pour les clefs, puis générer deux clefs pour chaque zone (une ZSK et une KSK):

mkdir /etc/bind/keys
dnssec-keygen -K /etc/bind/keys -a RSASHA256 -b 2048 -f KSK xolus.net
dnssec-keygen -K /etc/bind/keys -a RSASHA256 -b 2048 xolus.net

On se retrouve avec quatre nouveaux fichiers, les parties privées (.private) et publiques (.key) de la ZSK et de la KSK. Les fichiers .key sont au format standard RR de BIND. La KSK est celle ayant un enregistrement de type DNSKEY 257.

On ajoute les deux clefs à la zone:

cat /etc/bind/keys/Kxolus.net*.key >>/etc/bind/pri/xolus.net.zone

Par la suite, et a chaque modification de la zone, il faudra la resigner avec

cd /etc/bind
dnssec-signzone -K keys -o xolus.net pri/xolus.net.zone

Ceci crée un nouveau fichier de zone, xolus.net.zone.signed, qui inclut une signature pour chaque record de la zone. Reste a éditer /etc/bind/named.conf pour utiliser le fichier ".signed" à la place. On recharge ensuite BIND avec
rndc reload

puis on valide la signature d'une entrée au hasard, avec dig:

dig +sigchase +trusted-key=<(grep -v ';' /etc/bind/keys/Kxolus.net.+008+28711.key) -t aaaa xolus.net
Ici on a utilisé la KSK comme racine de confiance. dig est pénible et s'étrangle sur les commentaires placés par défaut dans les fichiers par dnssec-keygen. Si cela fonctionne, vous pouvez maintenant envoyer votre KSK à votre registrar qui se chargera d'ajouterles DS correspondants à la zone. Pour la vraie vérification, commençons par récupérer la clef racine:
dig -t DNSKEY . |grep " 257 " >>/etc/trusted-key.key
Cette récupération est insécure, mais vous pouvez vérifier que la clef correspond à
.                       IN      DNSKEY  257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0Ez
rAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=
Au demeurant, elle devrait déja être présente en dur dans /etc/bind/bind.keys, alors vérifiez que ça correspond. Une fois la clef racine dans /etc/trusted-key.key, un
dig +sigchase -t AAAA xolus.net
Devrait réussir si la validation en amont a fonctionné. La zone est maintenant DNSSEC-enabled. Reste maintenant a activer DNSSEC du côté du resolver local. Avec BIND on ajoute simplement
dnssec-validation auto;

dans named.conf.

Reste encore a couvrir les zones dynamiques, et le mécanisme d'auto-signature intégré a BIND.

jeudi 15 mars 2012

shatag v0.3

Après une longue session de codage intensif, j'ai le plaisir d'annoncer la sortie de la v0.3 de shatag (https://bitbucket.org/maugier/shatag.) Les nouvelles fonctionnalités sont:
  • un démon utilisant inotify pour recalculer les tags automatiquement
  • un client et un serveur HTTP avec un protocole restful léger
  • des backends modulables, ce qui permet le fonctionnement (inefficace) sur les OS sans extended attributes.

(Pour rappel, c'est un logiciel qui permet de garder trace des hashes sha256 des fichiers présents sur un filesystem, et de les comparer.)

mercredi 15 février 2012

Ron was wrong, Whit is right

Seems like we are creating quite a bit of noise with our recent survey on public key cryptography.

So, here is a little FAQ addressing the nonsense popping out in random comments of random sites on the net.

Q: But this is just the Debian bug !
A: No it isn't. It's more like a whole class of similar but unrelated bugs.

Q: OMG RSA is broken !
A: We haven't broken RSA. We have demonstrated the existence of flawed RNG implementations. You are still safe if you use a proper implementation.

Q: They claim it can be done, but they haven't, it's like these collision stuff / Saying that these keys offer no security is an overreaction
A: Yes, we have. We had the factorizations of 27k RSA moduli taken from SSL certificates not belonging to us. If/when a collection of these weak key leaks, all the tools needed to make this a practical eavesdropping attack already exist as free software.

Q: Heniger, Halderman et al. have twice as many broken keys, and have identified the source of the flaw. Most of them do not belong to real websites and pose no threat to the general public.
A: We seem to have just as many broken keys. Some numbers in the paper are based off an old dataset, and were left as-is as they are still representative of the situation. And we did know many (but not all) of them belonged to VPNs and other network devices, but didn't want to disclose it too early, for obvious reasons. It is true that popular https websites may not be at immediate risk for the general public; it is still, however, a serious matter of concern.

https://www.eff.org/deeplinks/2012/02/researchers-ssl-observatory-cryptographic-vulnerabilities

http://eprint.iacr.org/2012/064.pdf

jeudi 19 janvier 2012

Sunrise bloquent-ils le SSH en sortie ?

***UPDATE***: Le filtrage semble avoir disparu. La panne coïncidait avec une mise en maintenance de leur site web, y'avait-il un rapport ? Quoi qu'il en soit, merci Sunrise :)

Ceci est un appel à témoins pour les clients Sunrise possédant des smartphones.

Depuis hier, mon téléphone est mystérieusement incapable de se connecter en SSH à mes serveurs habituels via la connexion mobile 3G:

 - Si je déplace le serveur SSH sur un port alternatif, ça marche 
 - Si le téléphone est en wifi, ça marche
 - Le problème affecte 3 machines différentes, sur des réseaux complètement différents
 - Le problème n'apparait sur aucun de mes autres équipements clients

 Je crois qu'on peut conclure que le problème vient de leur réseau, délibéré ou pas.

Si j'observe les tentatives de connexion avec tcpdump, je recois le premier syn, en revanche le synack en retour semble ne jamais atteindre mon téléphone. J'observe 3-4 tentatives de connexion, après quoi le client ssh sur le téléphone abandonne.

Quelqu'un a-il observé un comportement similaire ? Je contacterai leur service technique demain pour savoir si c'est délibéré.

jeudi 17 novembre 2011

Vote électronique: Critique, Réponses, Coïncidences

La Critique

  Le jeudi 20 octobre 2011, le journal 24 heures publiait en courrier des lecteurs (page 26) une lettre signée de "P. Santschi, ancien député au grand conseil et ancien directeur du centre de calcul de l'EPFL". M. Santschi y évoque un système de vote électronique développé au sein du canton de Genève, et mentionne l'absence de garantie cryptographique du secret de vote. Il fait également référence a l'affaire des chevaux de troie utilisés sans cadre légal précis par la police pour traquer la criminalité en ligne. Il évoque, mais sans les préciser, les dangers posés par la combinaison de ces deux technologies.

 Ces dangers méritent un éclaircissement. L'opposition à l'utilisation des chevaux de troie ne se justifie pas, comme certains voudraient le faire croire, par un désir de préserver la vie privée. Elle provient d'une part de l'absence d'un cadre légal clair qui devrait être de mise, comme il en est pour les autres prérogatives des services de police; et d'autre de considérations purement techniques liés a la qualité douteuse des logiciels utilisés.

Il a en effet été révélé que le cheval de troie utilisé par la police allemande, insuffisamment sécurisé, laissait les ordinateurs ouverts a l'abus de tous. Imaginez qu'un enquêteur de police, plutôt que de procéder a la fouille du domicile d'un suspect, fracture systématiquement toutes les serrures et les laisse en l'état, pour faciliter les fouilles ultérieures. Imaginez qu'un cambrioleur en profite pour entrer dans ce domicile, y voler tous les objets de valeur, et y cacher son stock de drogue. Y voyez-vous un problème ?

L'observation de M. Santschi soulève donc un problème intéressant et souligne l'importance de la création de bases légales claires, et d'une assurance sur la qualité des outils utilisés par les enquêteurs.

La remarque concernant le non respect du secret de vote est un problème à part, et qui mériterait un article en lui-même.

Les Réponse

Suite à cette lettre, le 24 heures publie, le 31 octobre 2011, toujours dans son courrier des lecteurs (page 27) trois réponses à la lettre de M. Santschi.

Le site de 24 heures ne répond pas, mais les réponses sont encore dans le cache de google:

http://webcache.googleusercontent.com/search?q=cache:KoOBKA6nVsoJ:archives.24heures.ch/VQ/LAUSANNE/-/article-2011-10-3706/a-propos-de-la-lettre-de-lecteur-de-m+claude+bonard+ours+vaudois&hl=fr&client=firefox-a&gl=ch&strip=1

La première, signée Sonia Lardi, de Genthod, titrée "Difficile de le prendre au sérieux", rejette la critique de M. Santschi sur l'absence de secret de vote. A juste titre, Mme Lardi rappelle que les méthodes de vote papier dépendent aussi de la confiance envers l'administration, et qu'il n'y a pas lieu de critiquer un vote électronique qui offre une sécurité aussi bonne que le vote traditionnel.

Cet argument est incomplet, car il ne prend en considération que le risque d'une action malveillante de la part d'un agent de l'administration, sans considérer la portée de ce risque. Or en gestion du risque, il est nécessaire de quantifier ces deux aspects. La portée d'une action malveillante est beaucoup plus grande avec le vote électronique: si des scrutateurs entrent en collusion pendant le dépouillement pour modifier le compte des bulletins, ils pourront au pire falsifier les résultats d'une circonscription, sans compter le risque d'une recompte. Un informaticien malveillant ayant le contrôle total du système pourra, lui, aisément altérer le vote entier. Il est donc faux de comparer ainsi la sécurité du vote électronique et du vote traditionnel: il est normal d'exiger d'un vote électronique, dont les conséquences sont beaucoup plus graves en cas de faille, une réduction du risque d'attaque, tout comme on doit soumettre (en théorie) les centrales nucléaires à des controles techniques plus stricts que ceux d'une chaudière individuelle.

Si Mme Lardi se fourvoie dans son raisonnement, elle a au moins le mérite d'apporter un argument concret a l'encontre de la lettre de M. Santschi. Ce n'est pas le cas des deux suivants.

La deuxième lettre est signée Claude Bonard, de Vernier. Celle-ci met les griefs de M. Santschi envers le système de vote genevois sur le compte d'une rivalité entre cantons, sans plus argumenter.

La troisième, signée Michel Chevallier, de Mies, intitulé "Quelle bêtise !", reproche à M. Santschi de décrédibiliser l'EPFL et le Conseil National en signant de ces titres ce que M. Chevallier considère comme, je cite, "une ânerie pareille", là encore sans argumenter,.


Les Coïncidences

Cette troisième lettre m'a interpellé parce que le nom de son auteur ne m'est pas inconnu. En effet, l'article du Flash Informatique de Juin 2011 (http://flashinformatique.epfl.ch/spip.php?article2314) qui décrit l'architecture du système de vote genevois, est signé du même nom. Coïncidence ?

(Au passage, mon avis personnel, en tant qu'ingénieur diplômé EPF et candidat doctoral en cryptographie, est que ce design présente plusieurs erreurs grossières: transmission de la partie privée d'une clef asymétrique sur le réseau, création d'une table pour inverser un hash, utilisation redondante de chiffrement, et mixage inopérant) Espérons que les schémas présentés soient faux et ne soient pas le reflet du fonctionnement actuel du système.)

Une recherche sur internet nous apprend qu'une Mme Sonia Lardi a travaillé auprès de la Chancellerie d'Etat. On apprend également qu'un Claude Bonard aurait occupé le poste de secrétaire général de la Chancellerie d'Etat de 2000 à 2010.

Coïncidences ?
 
Also check me out on Mastodon