[Logo]
[Titre]

[Retour]

Archive for the ‘cryptographie’ Category

Sabordage de TrueCrypt – suite

Vendredi, avril 10th, 2015

Suite de Sabordage de TrueCrypt.

Bonne nouvelle. Les résultats de la deuxième partie de audit de l’outil TrueCrypt (7.1a) sont rendus publics. Et il n’y a ni faille majeure, ni porte dérobée.
Il n’y a donc pas d’urgence à le remplacer pour le moment.

CF : https://truecrypt.ch/wp-content/uploads/2015/04/TrueCrypt_Phase_II_NCC_OCAP_final.pdf

TrueCrypt_Phase_II_NCC_OCAP_final

Tunnel TLS pour ldap

Dimanche, juillet 13th, 2014

Il y a semble-t-il un bugg récent assez gênant sur la libraire GnuTLS sous Debian 7. Suite à une mauvaise implémentation semble-t-il au niveau de la négociation des algorithmes de chiffrement, il est impossible de générer ou d’utiliser des certificats pour les programmes qui utilisent cette librairie. Et c’est le cas notamment de slapd, le serveur d’annuaire LDAP (OpenLDAP) sous UNIX.

Le problème aurait pu passer presque inaperçu… mais il y eu heartbleed…Et il se trouve donc qu’un certain nombre d’admins systèmes ont dû changer très rapidement les certificats de leurs serveurs, et ont dû tomber sur ce problème.

Il devient ainsi impossible de relier un serveur de messagerie ou un serveur web avec un annuaire LDAP utilisant OpenLDAP. J’ai notamment le problème avec mon serveur postfix

Il est possible de ne pas utiliser la connexion à l’annuaire via TLS. C’est potentiellement un gros problème de sécurité en fonction des différents réseaux que vont traverser ces flux. Bref, ont n’a plus de sécurité sur un flux qui contient toute l’authentification du réseau. C’est assez moyen.

Il est aussi possible de mettre en place une solution de remplacement avec stunnel. Cela revient en fait à faire manuellement la connexion et le tunnel sécurisé par TLS. En plus, on peut conserver les mêmes certificats que le démon slapd.

Côté serveur

Il faut commencer par désactiver l’utilisation du port tcp/636. Pour cela, il faut modifier une ligne dans le fichier /etc/default/slapd :
SLAPD_SERVICES="ldap://127.0.0.1:389/"

Redémarrer le démon slapd.

Ensuite,on concatène le certificat et sa clé dans un seul fichier :
cat /etc/ssl/private/slapd.key /etc/ssl/certs/slapd.crt > /etc/ssl/private/slapd-all.crt

Enfin, on crée le bout du tunnel côté serveur, en réutilisant le certificat :
stunnel -d 636 -r 127.0.0.1:389 -p /etc/ssl/private/slapd-all.crt

Côté client

Le client, c’est le service qui utilise l’annuaire LDAP, par exemple postfix.

On crée le bout du tunnel côté client :
stunnel -c -d 6389 -r ldap.serveur.net:636

Enfin, on dit au client, en l’occurrence postfix, d’utiliser le tunnel. Modifier le fichier /etc/postfix/main.cf (ou équivalent) :
account_server_host = ldap://localhost:6389/

Et on redémarre postfix

CF : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921

(suite…)

Sabordage de TrueCrypt

Samedi, juin 14th, 2014

Depuis le 28 mai, TrueCrypt, le logiciel de chiffrement de disque dur, est mort. C’est ce que dit la page officielle. Il est conseillé au visiteur d’utiliser Bitlocker à la place.

Ce sabordage est étrange en plein audit de sécurité et alors que les premiers retours sont prometteurs. En l’absence d’informations supplémentaires, les spéculations sont à l’honneur. Cela fait maintenant plus de 2 semaines et on en sait pas plus en fait. C’est assez inquiétant quand même de voir un produit de sécurité majeur disparaître du jour au lendemain sans plus d’explication. Pour Lavabit on sait pourquoi, au moins.
En fait, à part la disparition d’un logiciel comme OpenSSL, il serait difficile d’imaginer pire. Et ceci malgré les récents problèmes graves d’OpenSSL. Bien qu’il y ai des produits concurrents, c’est assez catastrophique.

Il reste aux utilisateurs de TrueCrypt à migrer rapidement vers un concurrent ou un des forks qui va émerger et je l’espère s’imposer.
Moi, de mon côté, je ne suis pas concerné parce que je ne l’utilise pas. Je préfère cryptsetup. LUKS, que la force soit avec toi…

Heartbleed

Dimanche, avril 13th, 2014

La tempête commence à passer pour OpenSSL et sa récente faille critique. C’est pour rappel un programme généraliste pour tout ce qui est chiffrement, y compris les certificats X509, les tunnels SSL et assimilés. On peut voir un peu partout sur internet les implications de cette faille nommée Heartbleed.

Un site web et un logo sont dédiés à cette faille :

heartbleed
http://heartbleed.com/

Évidemment, c’est un gros problème pour une grande partie des serveurs sur Internet, et pas que pour les serveurs web. Tous les services qui sécurisent leurs communications avec TLS sont potentiellement impactés, et surtout tous ceux qui utilisent la librairie OpenSSL. Cela inclut des serveurs web (https) mais aussi la messagerie (smtp, imaps, pop3s), la messagerie instantanée (xmpp), etc…
Le plus rude pour un administrateur d’un serveur concerné, c’est que rien n’apparaît dans les logs (journaux). Tout au plus peut-on voir les tentatives avec un IDS ou une analyse fine du trafic réseau.

Pour résumer l’ambiance, rien de mieux que la citation :

« Si vous gardez votre sang-froid alors que tout le monde panique autour de vous, peut-être avez-vous mal évalué la situation »
Stéphane Bortzmeyer (site)

Aujourd’hui, un serveur concerné par la faille et non à jour est un serveur vulnérable.

Et les machines utilisateurs ?
Elle sont concernées aussi. OpenSSL est inclus dans beaucoup de logiciels pour gérer facilement le chiffrement. La faille marche aussi en sens inverse, depuis un serveur malveillant.

Pour ma pomme, mon principal serveur utilise une version un peu plus ancienne de OpenSSL, packagée. Cette version reçoit régulièrement des correctifs mais n’est pas impactée par Heartbleed. Ça passe pour cette fois même si je suis bon pour devoir mettre à jour tout mon serveur prochainement…
J’utilise aussi OpenSSL pour le projet nebule et le projet sylabe. Les fonctions internes de chiffrement et signature ne sont pas concernées. L’accès aux serveurs, via https, est concerné pour certains robots de test de sylabe. Ils n’ont pas été utilisés pendant la semaine de tempête.

Quels utilisateurs sont potentiellement concernés ?
En fait, tous les utilisateurs qui ont utilisés un compte sur un serveur utilisant OpenSSL avec la faille.
Il suffit pour les admins de regarder les logs des connexions côté public et de prévenir tous les utilisateurs qui se sont connectés pendant la période de temps critique. Mais une société commerciale a-t-elle vraiment envie de diffuser à ses utilisateurs que ses serveurs ne sont pas forcément aussi sûrs que ça !?
Doit-on prendre comme début de période de temps la date de diffusion publique de la faille ? Ou doit-on prendre la date d’ajout de la faille (volontaire ou pas), 2012 ? On passe de la semaine aux deux dernières années. On passe des dernières connexions à tous les utilisateurs. L’impacte n’est pas le même.
Et puis ce n’est pas aussi simple que ça. Si le chiffrement des connexions est séparé des serveurs web, si on a des frontaux dédiés aux tunnels TLS, seuls ceux-ci sont concernés. Il n’est dans ce cas pas utile de faire changer les mots de passes des utilisateurs.
Certaines grosses sociétés américaines ont été prévenues un peu en avance de la diffusion pour être à jour au bon moment. Il ne s’agirait pas que des services critiques comme Google ou Facebook ne soient bloqués, les banques peuvent attendre ;-)

Il pourrait être tentant pour certains admins de changer de solution de chiffrement. Oui, mais laquelle choisir? GnuTLS? Celle de Microsoft? Une solution propriétaire payante?
Je ne suis pas sûr du tout qu’échanger un programme avec les sources publiques par un programme aux sources fermées (programme privateur) soit une bonne solution. Quelque soit la qualité de certains programmes de M$, en logiciels de sécurité, il n’est pas très bien vu de ne pas disposer des sources. Quelle confiance peut-on apporter à un programme qui ne peut être librement audité par tout le monde. Je passe sur les récentes affaires révélées par Mr Snowden. La sécurité par l’obscurité, c’est comme ça que cela s’appelle, est très souvent employée pour cacher les choses mal programmées.
Ceci dit, la diversité à aussi du bon. Mixer les technologies et implémentations permet de ne pas se retrouver avec tous ses serveurs à poil en même temps en cas de coup dur comme Heartbleed
GnuTLS a eu des problèmes récemment, SecureTransport de Apple aussi. Les problèmes ne sont donc pas spécifiques aux logiciels à code ouvert.
Ce n’est pas la première fois que l’on a ce genre de problème, et ce ne sera pas la dernière.

Une solution, séparer la fonction de chiffrement TLS sur des serveurs dédiés. Le bout des tunnels sécurisés s’arrêtent aux portes des serveurs web, sur des machines spécialisées. Dans ce cas, seules les connexions en cours, leurs clés de sessions, sont vulnérables.
Les certificats de ces serveurs frontaux TLS sont aussi potentiellement compromis, donc à changer, sauf si ceux-ci sont stockés sur des cartes dédiées (pas en mémoire).
C’est d’ailleurs une bonne pratique pour tous les serveurs, et pas seulement les frontaux web : séparer les services entres eux et les applications sur des serveurs différents. Les séparer sur des machines physiques différentes et des réseaux physiques différents si leurs criticités sont différentes. Mais comme toujours, ça demande du temps, des compétences et du pognon.

L’autre solution, si tu es concerné :

  1. mettre à jour les serveurs et les postes clients ;
  2. changer les certificats des serveurs ;
  3. changer les mots de passes des utilisateurs.

Une question reste en suspend. Est-ce une 0-days ?
Va-t-on découvrir que certains l’utilisaient depuis quelques temps ? La NSA par exemple ? Rien n’est jamais définitivement écrit.

Station Linux et serveur Windows – suite 2008

Mardi, avril 8th, 2014

Voici la suite de l’article sur les Station Linux et serveur Windows.

Le même script fonctionne avec un serveur M$ Windows au niveau fonctionnel 2008R2.

Tout est passé du premier coup :
– la génération d’un ticket Kerberos ;
– l’ajout de la machine dans l’AD ;
– la consultation du LDAP.

Pour rappel, la station est sous Ubuntu Linux 13.10 .

FreeBSD – Disque chiffré et boot sur clé USB

Vendredi, mars 14th, 2014

liAttention – Documentation partielle !
Cette exercice a été abandonné en cours d’installation.
Partial installation.

Après la Clé USB bootable chiffrée sous OpenBSD, le Disque chiffré et boot sur clé USB sous Linux et le Système bootable chiffré sur deux clés USB interdépendantes (et suite) sous Linux, voici le disque chiffré et boot sur clé USB sous FreeBSD.
Objectifs :
1. Chiffrer l’intégralité du disque dur ;
2. Placer le nécessaire pour le démarrage uniquement sur une clé USB amovible ;
3. Permettre le démarrage du système sans saisir de mot de passe.

Basé sur le tutoriel :
http://namor.userpage.fu-berlin.de/howto_fbsd9_encrypted_ufs.html

L’exercice est réalisé avec le DVD1 de FreeBSD V10.0 RELEASE amd64.

(suite…)

Station Linux et serveur Windows

Mardi, mars 4th, 2014

Nous allons réaliser ici la première étape pour intégrer des stations Linux dans un domaine Microsoft Active Directory de niveau fonctionnel 2003. L’intégration dans un domaine AD de niveau 2008 et plus sera abordé une prochaine fois.

Conditions de départ de l’expérience :

  • Station : Ubuntu Linux 13.10, installation de base 64bits sans paquet supplémentaire.
  • Serveur : Microsoft Windows 2003 R2, domaine Active Directory activé, niveau de fonctionnalité 2003.
  • Domaine : MONRESEAU.NET

La documentation ci-dessous s’appuie beaucoup sur l’article ‘koo.fi blog – Ubuntu 12.04 Active Directory Authentication‘.

Plan :

  1. Station – Installer et configurer Kerberos
  2. Station – Installer et configurer Samba
  3. Station – Création du fichier Keytab
  4. Station – Régénération automatique du ticket Kerberos
  5. Station – Installer et configurer LDAP
  6. Serveur – Configurer les comptes utilisateurs AD
  7. Station – Configurer NSS
  8. Station – Configurer PAM
  9. Fin
  10. Liens
  11. Annexes

Sur la station, toutes les commandes sont lancées en tant que root ou, mieux, via sudo.

(suite…)

Système bootable chiffré sur deux clés USB interdépendantes – suite

Mercredi, novembre 27th, 2013

Il y a plusieurs choses qui peuvent être améliorées dans le système bootable chiffré sur deux clés USB interdépendantes.

C’est un peu technique et aucune solution complète n’est fournie. Si vous voulez les mettre en place, il va falloir gratter par vous même. (suite…)

Système bootable chiffré sur deux clés USB interdépendantes

Vendredi, novembre 8th, 2013

Voici une base de système qui nécessite deux clés USB pour pouvoir fonctionner. Si l’une manque, le système ne peut démarrer et, plus important encore, les données sont indéchiffrables.

Le schéma de principe :

20131108 cryptsetup sur 2 cles usb

L’exemple est réalisé à partir de Debian Linux 7.0, mais ça n’a pas de raison de ne pas fonctionner avec d’autres distributions. Ça marche aussi avec Ubuntu Linux par exemple. Il faut obligatoirement que cryptsetup soit disponible sur la distri. Il faut de préférence que l’on puisse mettre en place le chiffrement dès l’installation du système. Il faut aussi de préférence que le système soit installable directement sur clé USB et sur une partition chiffrée. Si ces deux dernières conditions ne sont pas remplies, l’exercice est réalisable mais il est beaucoup plus complexe à mettre en place.

(suite…)

How to Remain Secure Against the NSA – traduction

Dimanche, septembre 22nd, 2013

En visitant le blog de Bruce Schneier, je suis tombé sur un long et intéressant article : How to Remain Secure Against the NSA
Le contenu de cet article me semble important par rapport à toutes sortes de spéculations sur le cassage d’algorithmes cryptographiques suite aux révélations d’Edward Snowden. Je vais me concentrer sur les 5 points, traduits ici :

  1. Caché dans le réseau. Implémentez des services cachés. Utilisez TOR pour protéger votre anonymat. Oui, la NSA cible les utilisateurs de TOR, mais cela est efficace sur eux. Moins vous serez à découvert, plus vous serez en sécurité.
  2. Chiffrez vous communications. Utilisez TLS. Utilisez IPsec. Encore une fois, bien qu’il soit vrai que la NSA cible les communications chiffées (et ils connaissent peut-être des failles spécifiques contre ces protocoles), vous serez bien mieux protégés que si vous communiquez en clair.
  3. Prenez pour acquis que, bien que votre ordinateur puisse être compromis, cela nécessite du travail et représente un risque pour la NSA (donc il ne l’est probablement pas). Si vous avez quelque chose de vraiment important, utilisez un transfert par un moyen déconnecté. Depuis que j’ai commencé à travailler avec les documents de Mr Snowden, j’ai acheté un nouvel ordinateur qui n’a jamais été connecté à internet. Si je veux transfèrer un fichier, je chiffre le fichier sur l’ordinateur sécurisé puis l’emène à pied jusqu’à mon ordinateur sur internet, sur une clé USB. Pour déchiffre quelque chose, j’inverse le processus. Cela ne doit pas être infaible, mais suffisement bon.
  4. Soyez méfiants envers les logiciels de chiffrement commerciaux, spécialement des grands éditeurs. Mon avis, c’est que la plupart des produits de chiffrement des grandes entreprises US ont des portes dérobées pour la NSA, et il est probable que les entreprises étrangères fassent de même. Il est prudent de considérer que les équipements étrangers aient aussi des portes dérobées pour une puissance étrangère. Il est plus facile pour la NSA de placer une porte dérobée dans un logiciel à sources fermées que dans un autre aux sources ouvertes. Les systèmes reposants sur un important secret sont vulnérables à la NSA, que ce soit pour leurs activités légales ou plus clandestines.
  5. Essayez d’utiliser des algorithmes de chiffrements dans le domaine public qui nécessitent d’être compatibles avec d’autres implémentations. Par exemple, il est plus difficile pour la NSA de placer une porte dérobée dans TLS que dans BitLocker. Parce que tous les implémentations de TLS doivent être compatibles entre elles alors que BitLocker ne doit être compatible qu’avec lui-même, donnant à la NSA plus de libertés pour aporter des changements. Et parce que BitLocker est propriétaire, il est beaucoup moins probable que ces changements soient découverts. Préférez la cryptographie symétrique plutôt que la cryptographie à clé publique. Préférez les systèmes conventionnels à logarithmes discrets plutôt que les systèmes à courbes elliptiques. Ces derniers ont des constantes que la NSA influence dès qu’elle le peut.

Petite remarque sur ce qui semble une incohérence. Il cite au point 4 d’essayer d’utiliser des logiciels à sources ouvertes. Et il dit utiliser plus bas un ordinateur sous M$ Windows : « And I’m still primarily on Windows, unfortunately. Linux would be safer. »
L’aveu est franc. Je pense que l’explication est simple, il se sent plus à même de sécuriser un système qu’il connaît bien plutôt qu’un système inconnu. Ça se défend.

D’autres développements sont fait plus spécifiquement sur le blog de nebule

Liens :
https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html
http://blog.nebule.org/?p=1206

TOR et le PRISM

Jeudi, août 22nd, 2013

Les divulgations autour du programme PRISM font se poser des questions à beaucoup de monde. Une des solutions préconisée est d’utiliser des outils de chiffrement et/ou d’anonymisation.

On savait déjà que l’anonymisation de données avait des limites. Des études au USA ont permit de retrouver les identités de personnes à partir de données anonymisées de la sécurité sociale. Le big data présente toutes les caractéristiques pour permettre des corrélations aboutissant au rattachement de données isolées à des personnes.

Mais intéressons-nous au réseau TOR. Ce réseau de re-routage et d’anonymisation a été conçu aux USA. Il est aujourd’hui encore maintenu par une fondation américaine.

La page de Wikipédia sur TOR parle d’une possibilité d’attaque dite Time Pattern, c’est à dire une attaque sur l’empreinte temporel des flux réseaux passants par des nœuds TOR. En effet, un nœud qui reçoit un paquet réseau TOR essaye comme un routeur de le renvoyer au plus vite vers le nœud suivant, et ainsi de suite jusqu’au serveur destinataire. La façon (temporel) qu’une machine a de « parler » sur le réseau est donc assez bien retransmise jusqu’au serveur destinataire.

Il faut, me direz-vous, pouvoir sniffer le serveur destinataire et le poste client (si il est connu), mais sûrement aussi tous les relais TOR intermédiaires pour pouvoir remonter du serveur au client. Cette méthode permet de lever l’anonymisation.
Si il semble facile, au moins pour un gouvernement, de capturer le trafic réseau d’un serveur en particulier, il semble difficile de pouvoir faire la même chose pour tous les nœuds TOR et encore moins tous les postes clients du monde, même pour un gouvernement. La robustesse du réseau TOR repose sur cette propriété.
Le réseau TOR repose aussi sur de la cryptographie, mais uniquement pour les échanges « proches ». Et cela ne protège pas du Time Pattern.

Or, que fait PRISM ?
Et bien il fait justement cette chose qui semble difficile à faire : capturer le trafic réseau d’une grande partie des ordinateurs de l’Internet, voir peut-être tous. Et cela comprend les serveurs, les nœuds TOR et les postes clients…

Disque chiffré et boot sur clé USB

Lundi, mai 13th, 2013

Voici la documentation pour installer un système Debian Linux 7.0.0 avec un disque chiffré et un boot sur clé USB uniquement :
http://technix.starend.org/si/index.php/Serveur_-_Disque_chiffr%C3%A9_et_boot_sur_cl%C3%A9_USB

Cette documentation est réalisée suite à la réinstallation du serveur neptune.

Conclusion :

Voila, nous avons bien un serveur avec un disque intégralement chiffré et qui démarre tout seul uniquement si sa clé USB associée est branchée.

On peut partir en vacance avec la clé USB, sans elle le serveur ne redémarrera pas et les données resteront au chaud.

YubiKey ou pas

Samedi, janvier 26th, 2013

Je m’intéressais à la YubiKey de Yubico.

J’ai un peu gratté autour et publiée le résultat de cette petite étude sur le projet nebule. Le faible coût d’achat couplé à la nécessité d’ajouter partout ou je peux (…) la reconnaissance de l’authentification via le YubiCloud m’a rapidement fait comprendre que, malgré les avantages, ce n’est pas tout à fait ce que je cherchais…

Changer de mot de passe avec cryptsetup

Samedi, août 27th, 2011

J’utilise pour certaines de mes sauvegardes des containers (fichiers) chiffrés avec cryptsetup et ensuite formatés en ext3 ou vfat. Jusque là, rien que du classique si ce n’est qu’il faut au préalable faire reconnaître ce fichier ‘normal’ en question comme un fichier de type ‘bloc’ via la commande losetup

LOOP=$(sudo losetup -f)
sudo losetup $LOOP space/$CONTAINER.dsk

Là où cela devient plus complexe, c’est que le tout se trouve sur une machine à l’autre bout de la France (et potentiellement du monde) et est donc exploité via sshfs, donc comme un partage réseau en quelque sorte.

sshfs user@machine:/space space -o allow_other

(suite…)

Chiffrer le répertoire home d’un utilisateur sous Ubuntu

Vendredi, octobre 22nd, 2010

L’opération consiste à chiffrer le répertoire personnel (home) d’un utilisateur.

En quoi consiste l’opération ?
Tout simplement à protéger les données des utilisateurs d’une machine. Contrairement à de simples droits posés sur des fichiers ou des répertoires, le chiffrement de ces mêmes fichiers est bien plus sûr pour en restreindre la lecture par des personnes tierces.

(suite…)