Mot-clé - cryptographie

Fil des billets

mardi 10 mars 2015

Se maintenir au top de la sécurité SSL/TLS en faisant le ménage sur sa suite de chiffrements (cipher suite)

Le monde de la sécurité informatique est en perpétuelle évolution et les chiffrements jugés solides à un instant T ne le sont plus forcément à T+1 ! En novembre dernier, je proposais un paramétrage qui permettait alors d'obtenir la note maximale sur Qualys SSLLabs https://www.ssllabs.com (ce qui n'est bien sûr pas une fin en soi mais qui est un indicateur facile du niveau de sécurité atteint... si l'on fait confiance aux gens de Qualys).

Cependant, les attaques sur l'algorithme de chiffrement RC4 se sont multipliées et celui-ci a été récemment déclaré comme faible et déconseillé donc pour l'établissement de connexions sécurisées. Diable, il faut donc mettre à jour la suite de chiffrements utilisés pour écarter ce chiffrement !

Heureusement, les gens de Mozilla (encore eux !) nous rendent la tâche aisée en publiant une série de 3 suites de chiffrement selon le niveau de sécurité et le niveau de rétro-compatibilité souhaités (avec de vieux navigateurs / de vieux OS) : https://wiki.mozilla.org/Security/Server_Side_TLS

En date du 10 mars, la suite de chiffrement conseillée pour le plus haut niveau de sécurité est la suivante :

Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

Voilà qui devrait aider les administrateurs à optimiser la sécurité des connexions SSL/TLS proposées par leurs serveurs !

lundi 10 novembre 2014

StartSSL pour des certificats SSL "wildcard" à petit prix

Disposant de plusieurs domaines pour mes activités personnelles et professionnelles, j'utilisais jusqu'ici des certificats auto-signés pour sécuriser mes connexions avec SSL/TLS. Cependant, habituer l'utilisateur à "ajouter une exception de sécurité" sans réfléchir me déplaisait au plus haut point. J'ai donc finalement, poussé aussi par mon beau-frère, mis en place de jolis certificats validés par StartCom Ltd. (StartSSL).

Les tarifs pratiqués par StartCom Ltd./StartSSL sont beaucoup plus doux que ceux pratiqués par d'autres acteurs du domaine. Chez eux, on paye en effet le processus de validation d'identité mais ensuite l'émission des certificats est gratuite. Voilà qui est tout à fait intéressant et économique pour couvrir plusieurs domaines !

Ouvrir un compte chez StartSSL

La première étape consiste à se connecter sur http://startssl.com et à choisir "Sign-up" pour ouvrir un nouveau compte. On saisit ses informations personnelles (il faut qu'elles soient exactes si l'on prévoit de faire valider son identité !) puis le site installe automatiquement dans le navigateur un certificat/clé qui autorise ce seul navigateur à se connecter au site. Une bonne pratique consistera à sauvegarder de manière sûre ce certificat pour conserver l'accès au site StartSSL !

Profiter des certificats de niveau 1

Sans rien payer, il est alors possible de faire valider un domaine via le 'Validations Wizard' (la validation d'un domaine consiste à recevoir un courriel envoyé par exemple à postmaster@le-domaine-en-question.fr et à saisir le code de validation reçu) puis de créer des certificats de niveau 1.

Les certificats de niveau 1 sont une bonne base pour débuter mais il n'est notamment pas possible avec ce niveau de disposer de certificats "wildcard" (i.e. pour tous les sous-domaines d'un domaine). Pour bénéficier de cette fonctionnalité, il faut disposer d'un niveau 2.

Obtenir le niveau 2

Pour passer niveau 2, il faut d'une part :

  • soumettre des documents pour prouver son identité (photocopies de 2 pièces d'identité, éventuellement justificatif de domicile, éventuellement recevoir un appel de StartSSL sur son numéro de téléphone)
  • s'acquitter de la somme de 59,90$ (environ 48 euros)

Tout le processus s'effectue en ligne via le 'Validations Wizard', catégorie 'Personal identity validation'. Les gens de StartCom StartSSL sont extrêmement réactifs.

Dans mon cas, après quelques heures et quelques échanges par courriel et téléphone, mon identité a été vérifiée et mon niveau 2 validé.

Créer un certificat 'wildcard'

Une fois niveau 2, voici la marche à suivre :

  • sur le serveur que l'on souhaite protéger, nous allons générer une clé privée et un Certificate Sining Request (CSR) par la commande
openssl req -nodes -newkey rsa:4096 -sha256 -keyout cle-privee.key -out serveur.csr

Il est à noter que ce processus génère une clé privée sans mot de passe. Il est tout à fait possible de générer une clé avec mot de passe mais il faudra alors préciser le mot de passe correspondant aux logiciels serveurs qui utiliseront la clé pour crypter les échanges.

Au cours du processus, OpenSSL va demander quelques informations d'identité. Il est important de préciser dans le champ 'Common Name' le nom d'hôte à protéger : en l'occurrence *.le-domaine-en-question.fr si l'on souhaite bénéficier d'un certificat 'wildcard' pour le-domaine-en-question.fr.

Country Name (2 letter code) [AU]: FR
State or Province Name (full name) [Some-State]: Ile-de-France
Locality Name (eg, city) []: Mary-sur-Marne
Organization Name (eg, company) [Internet Widgits Pty Ltd]: MaSociété
Organizational Unit Name (eg, section) []: 
Common Name (eg, YOUR name) []: *.le-domaine-en-question.fr
Email Address []: postmaster@le-domaine-en-question.fr
A challenge password []: 
An optional company name []:
  • on peut alors afficher le contenu du CSR par
cat serveur.csr

et le conserver précieusement

  • de retour sur le site de StartSSL, se rendre dans le 'Certificates wizard'
  • choisir 'Webserver SSL/TLS certificate'
  • passer (bouton SKIP) l'étape de génération d'une clé privée puisque nous avons créé nous-même notre clé privée sur le serveur
  • copier alors le contenu du CSR dans le champ texte
  • sélectionner le domaine à protéger : seuls les domaines déjà validés peuvent être utilisés. On pourra par exemple saisir *.le-domaine-en-question.fr.
  • et voilà le certificat qui apparaît à l'écran. Il convient de copier ce certificat précieusement, par exemple dans un fichier wildcard.le-domaine-en-question.fr.crt.

Utiliser son tout nouveau certificat

Cette étape dépend ensuite du serveur utilisé (Apache, Pound, Nginx, ...). La plupart du temps, on regroupera le certificat obtenu de la part de l'autorité de certification et la clé privée dans un même fichier .pem. On pourra également inclure les certificats intermédiaires de l'autorité : https://www.startssl.com/certs/ca.pem et https://www.startssl.com/certs/sub.class2.server.ca.pem.

cat wildcard.le-domaine-en-question.fr.crt cle-privee.key ca.pem sub.class2.server.ca.pem > wildcard.le-domaine-en-question.pem

On pourra alors utiliser ce .pem sur son serveur, en s'assurant toutefois de bien le garder secret, car il contient notre clé privée !

Bon courage pour votre génération de certificats !

mercredi 30 octobre 2013

Crypter une partition et l'ouvrir sans crainte d'un keylogger

Nous allons utiliser dm-crypt+LUKS qui se basent sur les outils de cryptographie présents normalement dans le noyau linux. On pourra faire le reproche à cette solution de ne pas permettre mettre en place un déni plausible (i.e. ouvrir une partition avec des données à l'apparence normale sous la contrainte, TrueCrypt le permet).

Création de la partition

La partition à crypter se nomme : /dev/sdaX Choisissons le chiffrement aes-xts-plain avec un taille de clé de 512 bits :

cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/sdaX

Le système demande une 'passphrase' que l'on choisira bien sûr longue, avec de nombreux caractères accentués, des chiffres, des majuscules, des signes de ponctuation... Attention à ne pas perdre la 'passphrase' car sans elle, point de salut !

Puis accédons au périphérique :

cryptsetup luksOpen /dev/sdaX zonecryptee

et formatons l'espace comme souhaité puis montons le :

mkfs.ext3 /dev/mapper/zonecryptee
mount -t ext3 /dev/mapper/zonecryptee /mnt/dossiercrypte/

Pour fermer la partition cryptée :

umount /mnt/dossiercrypte/
cryptsetup luksClose zonecryptee

Pour obtenir des informations sur la partition crypée, on fera :

cryptsetup luksDump /dev/sdaX

Ajouter une clé pour accéder à la partition

Grâce à LUKS, on peut saisir plusieurs clés (jusqu'à 8) pour accéder à un même espace crypé. Commençons par générer une longe clé aléatoire :

dd if=/dev/urandom of=keyfile bs=1024 count=4

et ajoutons cette clé à l'espace crypté :

cryptsetup luksAddKey /dev/sdaX keyfile

On pourra désormais ouvrir l'espace, sans saisir la 'passphrase' secrète et sans crainte d'un keylogger ou d'une caméra qui filmerait nos mains sur le clavier, grâce à la commande :

cryptsetup --key-file=keyfile luksOpen /dev/sdaX zonecryptee

Après ouverture, la clé peut être retirée du système (elle n'est nécessaire qu'à l'ouverture) afin de limiter son exposition aux regards. Bien sûr, il ne faut pas perdre le fichier 'keyfile' et le conserver en sûreté ! S'il était compromis, on pourrait révoquer la clé avec la commande :

cryptsetup luksRemoveKey /dev/sdaX

Refermer la partition

Là rien ne change :

umount /mnt/dossiercrypte/
cryptsetup luksClose zonecryptee

Protégez-vous bien !

lundi 29 août 2011

MD5, l'algorithme de hachage utilisé pour comparer des fichiers

Tout le monde connaît la somme MD5 qui permet de savoir si un fichier est authentique et intègre : on compare l'empreinte MD5 du dit fichier avec une valeur de référence ; s'il y a égalité, alors le fichier est intègre.

A une époque, l'algorithme MD5 était utilisé pour la cryptographie (notamment le stockage des mots de passe - dans Debian 5.0, les mots de passe sont par défaut conservés sous forme d'empreinte MD5 dans le /etc/shadow - avec Debian 6.0, le standard est passé à SHA-512). Toutefois, il a été démontré que l'empreinte MD5 n'était pas infaillible (pour des raisons que nous ne détaillerons pas ici) et le monde cryptographique s'en est détourné pour notamment les algorithmes SHA.

En revanche, l'algorithme MD5 continue à être utilisé (sans que cela ne pose de risque ni ne soit un problème) pour comparer des fichiers.

Curieux, je me suis livré aujourd'hui à un petit test : je voulais m'assurer que l'algorithme MD5 permettait effectivement de repérer des différences même minimes dans des fichiers - l'algorithme décrit sur Wikipedia par exemple rassure également sur ce point.

Je suis donc parti d'un document .odt :

42b0f02e6f5e1ebcbd59741d8650b0a3  fichier.odt

J'ai modifié une lettre de ce même fichier :

4e53f713ec0abedd31f6674ff8a69038  fichier.odt

La modification est bien visible

J'ai alors re-modifié le document afin de revenir à la version initiale :

f02e188d6bc72b69ca153e7d1e0e2e27  fichier.odt

Conclusion : sans doute d'autres parties du fichier odt ont été modifiées, par exemple (mais cela reste à découvrir exactement) un historique des opérations ou un marqueur des dernières modifications.

Evidemment, si j'effectue les mêmes opérations sur un fichier texte, alors je constate bien que l'on retrouve la somme MD5 quand on revient à la version initiale (contenu identique) du fichier.

Question subsidiaire : si je souhaite vous prouver que je ne modifie pas un document sans vous envoyer son contenu (qui est peut-être confidentiel), je vous envoie la somme MD5 du document à l'instant t, que l'on notera MD5(fichier, temps t). A t+1, si vous constatez que MD5(fichier, temps t+1) est différent de MD5(fichier, temps t) alors pouvez-vous conclure que le document a été modifié ? Et, plus important, si vous constatez que MD5(fichier, temps t+1) = MD5(fichier, temps t), êtes-vous certain que je n'ai pas modifié le document ? Question ouverte, je n'ai pas la réponse pour ma part - j'ai déposé la question sur un journal LinuxFr pour la soumettre à la sagacité des internautes.

http://linuxfr.org/users/pab/journaux/md5-et-garantie-de-non-modification

Mise à jour : les mêmes raisons qui ont fait abandonné MD5 en cryptographie (i.e. la non résistance aux collisions c'est-à-dire la possibilité de générer des contenus différents qui ont la même clé MD5) semblent faire dire que le MD5 ne convient pas - il faut lui préférer pour cet usage les algorithmes SHA (e.g. SHA-256). En fait, si on ajoute un coup de crypto assymétrique avec clé publique/privée, alors on obtient a priori la signature numérique.