Archives de catégorie : Cryptographie. Chiffrement

Cette catégorie regroupe des informations sur la cryptographie de manière générale, et sur le chiffrement. L’actualité fait hélas de plus en plus mention de failles liées aux processus de sécurisation et de chiffrement.

Parmi les sites expliquant les principes et les bases, bibmath.net est très clair et très fourni.

Chiffrement ubiquitaire

Qu’est-ce que c’est encore que cette bestiole ? On n’arrête pas les nouveautés, qu’on souhaite pour le meilleur mais qui aboutissent en sécurité souvent sur le pire, comme SGX. Sans compter les nouveautés qui n’inventent rien, à part l’inculture de leurs promoteurs qui ne savent pas que la solution en question a déjà été inventée. Regardons donc.

Continuer la lecture →

Fonctions de hachage

Les fonctions de hachage sont des fonctions particulières très utilisées dans le cadre de la sécurité informatique, notamment dans le domaine de la cryptographie et des certificats numériques. Elles permettent d’obtenir une empreinte, également appelée condensat (« hash »), à partir d’un message ou de tout document numérique.

Il existe un nombre assez restreint de fonctions de hachage, car elles sont assez complexes à mettre au point et reposent sur des mécanismes mathématiques complexes.

Principales caractéristiques

En pratique

Une fonction de hachage est une fonction mathématique particulière permettant de calculer rapidement l’empreinte d’une donnée informatique. Une fonction de hachage doit présenter les caractéristiques suivantes :

  • La taille du condensat (« hash ») est fixe (pour un algorithme donné) ;
  • Elle ne fonctionne que dans un sens (c’est-à-dire qu’il n’existe pas de fonction inverse) ;
  • Pour une entrée donnée, on doit toujours obtenir le même résultat (empreinte) ;
  • Toute modification même très légère en entrée produit un résultat très différent ;
  • Elle est rapide à calculer.

L’intérêt de ce condensat est d’avoir une sorte de signature d’un document :

  • L’irréversibilité permet de ne pas pouvoir retrouver le document original à partir du condensat (il est même très difficile de construire un document quelconque à partir d’une empreinte donnée) ;
  • Si deux hashs sont différents, alors les documents initiaux sont forcément différents.

Intérêt et usage des fonctions de hash

L’intérêt principal est de permettre d’identifier la donnée de façon presque sûre sans pour autant transmettre la donnée : il est mathématiquement très difficile (voire impossible) de retrouver la donnée initiale à partir de son empreinte.

Principe d’une fonction de hachage. Une donnée identique en entrée donnera la même empreinte. A l’inverse, une légère différence donnera une empreinte complètement différente.

Ces fonctions peuvent avoir plusieurs usages, plus ou moins critiques. Cela peut aller du simple contrôle technique pour s’assurer qu’un message a été correctement transmis (ou n’a pas été modifié), jusqu’à la signature électronique.

Pour le mot de passe

On s’en sert également pour chiffrer les mots de passe dans beaucoup de systèmes. Puisque ces fonctions sont rapides, on peut facilement calculer l’empreinte d’un mot de passe ; c’est alors lui qui est stocké dans le système, et non le mot de passe en clair. Comme il est difficile de retrouver la donnée initiale à partir d’une empreinte, la protection ainsi obtenue est bonne (plus ou moins en fonction de l’algorithme utilisé et de sa mise-en-oeuvre).

Lorsqu’un utilisateur veut se connecter à un système, il entre son mot de passe. On calcule ensuite son empreinte : si c’est la même que celle stockée dans le système, l’accès est alors autorisé.

Pour vérifier l’intégrité d’une donnée

Si on souhaite vérifier qu’une donnée (un fichier informatique) est intègre, c’est-à-dire non modifiée, on communique le fichier au destinataire et ce dernier recalcule lui-même son empreinte : celle-ci doit correspondre à une empreinte de référence.

Les fonctions de hachage permettent le contrôle d’intégrité et la prise d’empreinte numérique.

Toute la subtilité vient ensuite de la façon dont on connaît cette empreinte de référence : quand on télécharge un fichier, cela peut être une somme de contrôle ; pour un certificat, c’est une des données du certificat.

Pourquoi presque sûre ?

L’empreinte est généralement de petite taille et de longueur fixe. Même si cela représente beaucoup de possibilités, ce nombre est fini, alors que le nombre d’entrées possibles est, lui, infini.

Statistiquement, il est donc très peu probable que deux données différentes en entrée produisent la même empreinte, mais c’est possible : la difficulté augmente avec la longueur choisie pour l’empreinte. Pour SHA-1, c’est 160 bits. pour SHA-256 c’est… 256 bits !

Trouver deux données différentes ayant un même hash est appelé collision. La probabilité d’une collision dépend principalement de la longueur du hash, mais aussi (un peu) de la façon dont il est calculé (notamment la rapidité de son calcul).

Les propriétés et les attaques

Propriétés formelles attendues d’une fonction de hachage

Reprenons un peu le chemin de la théorie. Selon McAfee Labs (Intel)1, une bonne fonction de hachage doit avoir les propriétés suivantes :

  • Résistance à la préimage : Pour une valeur de hachage donnée, il doit être difficile de trouver un fichier ou message pour lequel la fonction de hachage produirait une valeur identique.
  • Résistance à la seconde préimage : Pour un fichier ou message donné, il doit être difficile de trouver un second fichier ou message tel que la fonction de hachage produirait la même valeur pour les deux fichiers ou messages.
  • Résistance à la collision : Il doit être difficile de trouver deux fichiers ou messages distincts pour lesquels la fonction de hachage produirait la même valeur de hachage.

Dis comme ça, il n’est pas évident de voir la différence (je parle pour moi). Mais l’enjeu de cette formalisation est de voir quels sont les types d’attaques possibles : chaque propriété est plus ou moins forte, pour un type de hash donné. Et plus la propriété est faible, plus une attaque est probable.

Les différents type d’attaques

Attaques par collision

Il existe deux types principaux d’attaques de collisions :

  • l’attaque de collisions classique : cette attaque consiste à trouver deux messages m1 et m2 différents, tels que hachage (m1) = hachage (m2) ;
  • l’attaque de collisions avec préfixes choisis : étant donné deux préfixes différents P1 et P2, cette attaque consiste à trouver deux suffixes S1 et S2 tels que hachage (P1 ∥ S1) = hachage ( P2 ∥ S2) (où ∥ est l’opération de concaténation).

Source : Wikipédia

xxx

Qu’est-ce qui se passe avec SHA-1

Il se passe que la robustesse de SHA-1 est remise en question face au développement de la puissance de calcul disponible. Or SHA-1 est très utilisé, notamment pour les certificats ; or si on peut attaquer SHA-1, on peut alors attaquer des certificats et créer des faux !

Pour plus d’informations : voir SHA-1.

Ce qu’affichent les navigateurs

La signalétique est généralement univoque. Chrome affiche du vert quand c’est sûr, du gris pour un avis neutre, et du rouge quand le niveau de sécurité est trop faible.

Ce qu’affiche Chrome pour un certificat de type EV considéré comme sûr.

Malheureusement tout le monde applique un peu les règles qu’il veut, comme il le sent, ce qui aboutit à des incohérences pour un utilisateur multi-navigateurs (comme moi). Google a tendance à avoir l’attitude la plus restrictive, ce qui n’est pas forcément condamnable, sauf que cela n’a pas toujours de l’intérêt, comme par exemple sur des sites de peu d’influence ou de peu d’importance.

De plus, Google change ses règle si rapidement qu’un utilisateur peut être perdu en voyant un site « dégradé » (en termes de sécurité) d’une version à l’autre du navigateur.

Exemple d’utilisation

Sous Linux, si vous ne disposez pas des commandes shaxxxsum :

openssl dgst -sha1 filename

Calcul multipartite sécurisé

Le calcul multipartite sécurisé est un problème où chacune des parties veut effectuer une opération commune sur des données qui doivent rester privées (aucun des participants ne connaît les données de l’autres) et exactes (non compromises). Il faut aussi qu’un tiers extérieur (attaquant) ne puisse pas accéder lui non plus aux données privées, ni les falsifier.

Participons

Une des applications pratiques est celle du classement de fortunes de millionnaires, sans rendre publics les montants de ces fortunes. Pour deux millionnaires cela revient à savoir lequel est le plus riche sans connaître la fortune de l’autre. La réduction à deux participants n’est pas anodine car elle permet, dans certaines méthodes, une généralisation à plusieurs participants.

Un cas d’usage similaire est celui d’enchères anonymes, ou du comptage des voix dans une élection : il faut savoir qui a gagné sans connaître le vote de chacun (note : ceci est réalisable dans le cas du vote papier, et beaucoup plus difficile dans un vote électronique).

Mathématiquement, cela peut aussi être la création d’un entier aléatoire N que deux parties ne peuvent reconstituer que conjointement. Si N = pq avec p et q étant des facteurs de N, alors aucune des deux parties ne connaît (p,q). Les deux parties peuvent ainsi effectuer des calculs sur des fonctions polynomiales sans révéler les valeurs utilisées en entrée, qui restent donc secrètes, ce qui a des applications en cryptographie.

Les Yao Garbled Circuits sont une solution possible permettant le calcul multipartite sécurisé.

Garbled circuits, secure multi-party computation

Références externes

Autres informations

Google Releases Encrypted Multi-Party Computation Tool(June 19, 2019)
Google has rolled out its open-source Private Join and Compute (PJC) secure multi-party computation tool. PJC can be used in studies that require data sets containing sensitive information from two separate parties. PJC will allow two sets of data to be used in computations without exposing the data each set contains. The data are encrypted during the computation; all parties can see the result. 
Read more in:
– security.googleblog.com: Helping organizations do more without collecting more data
– www.wired.com: Google Turns to Retro Cryptography to Keep Data Sets Private
– www.theregister.co.uk: Google takes the PIS out of advertising: New algo securely analyzes shared encrypted data sets without leaking contents
– www.zdnet.com: Google open sources Private Join and Compute, a tool for sharing confidential data sets

FIDO

FIDO est une alliance créée (en 2012) à l’origine par PayPal et quelques autres acteurs afin d’essayer d’établir un protocole d’authentification sans mot de passe.

Dès 2013, Google, Yubico et NXP1 s’y joignent pour répondre à une problématique forte chez Google de lutte contre le phishing. Pour cela, l’industrie avait besoin d’un standard pour une authentification « forte », et très vite l’idée d’un facteur matériel a été présentée par ces acteurs, avec un protocole ouvert et donc utilisable par tous.

L’acronyme FIDO correspond à Fast IDentity Online, ce qui souligne bien l’orientation web des protocoles. Les grandes étapes historiques de cette alliance sont ici.

FIDO « 1 »

Le besoin initial était de renforcer l’authentification sur des services web ; il était donc naturel d’introduire un second facteur en complément du mot de passe. Fin 2014, les normes FIDO UAF et FIDO U2F sont publiées simultanément.

Premiers protocoles

UAF

UAF correspond à Universal Authentication Framework, qui propose un protocole d’authentification sans mot de passe, à base de cryptographie.

U2F

U2F est la norme concernant le second facteur d’authentification, ou Universal 2nd Factor en anglais, également à base de cryptographie.

A quoi ça sert ?

Grâce à ces normes, on garantit la valeur de l’authentification puisqu’on sait comment cette dernière est établie. Garantir ne signifie pas que l’authentification est parfaite mais qu’on en connaît les mécanismes, et qu’on peut ainsi gérer correctement le risque associé.

Certification

En bonus, une certification peut ainsi être réalisée sur les dispositifs concernés : en utilisant un dispositif FIDO, on sait donc parfaitement comment ce dernier fonctionne. Par la suite, les travaux concernant la certification vont continuer pour suivre l’évolution des technologies et l’accompagner.

La suite

Des travaux viendront compléter ces premières normes, en standardisant les échanges via Bluetooth et NFC, en incluant la biométrie, etc.

FIDO2

En 2016, l’alliance poursuit son travail avec un objectif ambitieux, à savoir créer une norme reconnue pour l’authentification forte sur internet (sur le web).

Pour cela, l’alliance pouvait se baser sur les travaux de la première norme et en 2018 le protocole fut intégré comme candidate recommandation par le W3C, ouvrant la porte à la reconnaissance en tant que standard international de ce qui était en train de devenir FIDO2.

FIDO2 vs. webAuthn

FIDO2 est un ensemble de spécifications, comprenant deux parties :

  • webAuthn qui est une ensemble de spécifications du W3C, dont le but est d’établir des standards pour le Web ;
  • CATP qui est un ensemble de spécifications de l’alliance FIDO décrivant un protocole d’authentification entre un client et un dispositif d’authentification communiquant via USB, Bluetooth ou NFC.
fido2_building_blocks.png
Source : Overview (yubico.com)
fido2_app_architecture.png
Source : Overview (yubico.com)

Les avantages selon FIDO

Sécurité

Sécurité

FIDO utilise un mécanisme cryptographique pour assurer l’authentification à un site. Chaque authentifiant est unique pour chaque site, le secret ne quittant jamais le dispositif FIDO.

Facilité d’utilisation

Facilité d’utilisation

La facilité d’utilisation provient du dispositif FIDO lui-même, qui gère la partie cryptographique avec le site web. L’authentification sur le dispositif lui-même peut être celui que le client désire (parmi ce qui existe), et est réalisée localement, sans échange avec le serveur web.

Types d’authentification pris en charge

FIDO versions 1 et 2 permettent plusieurs types d’authentification, en combinant les différentes possibilités. En ce ce qui concerne FIDO2 :

  • Un seul facteur : identité + identifiant (« credential ») FIDO2
  • Second facteur (complément du 1er) : identité + mot de passe + identifiant FIDO2
  • Un seul facteur, sans mot de passe : clé cryptographique (« resident key ») FIDO2 stockée sur le dispositif FIDO2
  • Deux facteurs (MFA) « sans mot de passe » : clé cryptographique FIDO2 + code PIN

Les dispositifs FIDO2 sont également rétro-compatibles avec l’authentification FIDO U2F :

  • Un seul facteur : identité + identifiant FIDO U2F
  • Second facteur: identité + mot de passe + identifiant FIDO2 U2F

Points clés

  • Les identifiants FIDO2 sont basés sur une paire de clé cryptographique de type asymétrique.
  • Le fournisseur d’identité (« identity provider », ou IdP) valide l’identité de l’utilisateur et associe une clé publique FIDO2 à un compte utilisateur (phase d’enregistrement, souvent appelée improprement enrolement en français).
  • L’identifiant (« credential ») FIDO2 peut être généré sur un support matériel (clé physique, smartphone, PC portable…) ou par logiciel, selon la politique choisie.
  • L’authentification utilise une clé cryptographique liée au dispositif d’authentification et, en option, un autre facteur qui peut être de type « ce que je sais » (code PIN) ou « ce que je suis » (biométrie). Cet identifiant complémentaire (PIN ou biométrie) n’est pas diffusé entre les dispositifs d’authentification et n’est pas partagé avec aucun serveur. Il est stocké uniquement sur le dispositif d’authentification.
  • La clé privée de l’utilisateur (de la paire de clé asymétrique) ne quitte jamais le dispositif d’authentification. Le serveur d’authentification ne conserve que la clé publique associée au compte de l’utilisateur durant la phase d’enregistrement.
  • La saisie du code PIN, la présentation de la biométrie, ou l’appui sur le bouton présent sur le dispositif sert à débloquer la clé privée afin de signer cryptographiquement les données envoyées au fournisseur d’identité dans l’assertion. Les données signées contiennent également l’indication d’utilisation ou non d’un code PIN ou de la biométrie. La demande d’authentification se poursuit à partir du moment que le fournisseur d’identité a vérifié l’assertion d’authentification.

Hello ?

Sources

Sujets connexes

Authentification web

A regarder :

  1. La théorie, l’alliance
  2. Principes, programmes, working Groups
  3. L’architecture
  4. Sécurité du stockage
  5. Versus biométrie
  6. Inter-opérabilité
  7. Développements, API

Attaques 2FA

Autres ressources

Commandes utiles

openssl

Voici quelques commandes utiles. Sauf indication contraire, c’est du Linux 😉 mais ça marche quasiment de la même façon sous Windows.

openSSL est un outil open source très répandu qui offre un très grand nombre de fonctions utiles pour la mise en oeuvre de SSL. Voici quelques exemples d’utilisation.

Pour récupérer le certificat présenté par un site :

openssl s_client -connect nom_du_site:443 -showcerts

Pour afficher en clair le contenu d’un certificat X.509 :

openssl x509 -in nom_fichier_certificat -text

Debugging de connexion SSL

openssl s_client -state -nbio -debug -connect ...

Pour afficher la clé publique d’un certificat :

openssl x509 -pubkey -noout -in nom_fichier_certificat

Pour afficher la clé publique en format utile pour une connexion SSH avec clé :

 ssh-keygen -y -f nom_fichier_cerificat

Pour la clé privée :

openssl pkcs12 -in fichier.pfx -nocerts -out fichier.key -nodes
openssl rsa -in fichier.key -out clepriv.key

A passer ensuite dans la moulinette PuTTY KeyGen pour transformer tout ça en format utilisable par PuTTY…

Convert PEM files

PEM to DER

openssl x509 -outform der -in certificate.pem -out certificate.der

PEM to P7B

openssl crl2pkcs7 -nocrl -certfile certificate.cer -out certificate.p7b -certfile CACert.cer

PEM to PFX

openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt

Convert P7B files

P7B to PEM

openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer

P7B to PFX

openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CACert.cer

Convert PFX files

PFX to PEM (extraction du certificat)

openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes

PFX to PEM (extraction de la clé privée)

openssl pkcs12 -in certificate.pfx -nocerts -out cle.pem -nodes

Convert DER files

DER to PEM

openssl x509 -inform der -in certificate.cer -out certificate.pem

Sources

git

Pour utiliser git avec token d’authentification, il faut indiquer ce token dans l’URL des push.

git remote set-url origin "https://USER:TOKEN@gitlab.com/user/projet.git"

BitLocker

Récupération des informations sur un volume donné :

manage-bde –protectors –get [volume]

Création d’un fichier package de clé, sur un id récupéré par la commande ci-dessus :

manage-bde -KeyPackage C: -id "{id}" -path "f:\Folder"

Réseau

Windows

ipconfig /displaydns 
tracert 
netsh

Linux

Pour arrêter et redémarrer une interface (afin de prendre en compte les changements de paramétrage).

ifconfig eth0 down
ifconfig eth0 up

Autres commandes :

route -n

Windows

Mesure de performances Win10

Voir aussi

GnuPG

GnuPG est un système de chiffrement (ou cryptosystème) indépendant des grands acteurs de la sécurité et de la surveillance (lesquels se confondent parfois). Il se base sur l’utilisation de clés de chiffrement asymétriques, ce qui permet de les échanger plus facilement.

Principes

A quoi ça sert un crypto-machin ?

Ça sert à masquer vos très chères données à nos très chers GAFA et autres acteurs du web et de l’internet. Accessoirement, Mme Michu ne pourra pas non plus lire ce que vous échangez avec vos correspondants.

En gros, vous créez une paire de clés de chiffrement qui vous seront associée à vous personnellement. Un des clés sera publique, l’autre sera privée ; elles vous permettront de chiffrer vos données ou vos mails. La clé publique pourra et devra être diffusée partout, et la clé privée devra rester secrète et donc, au contraire, être la plus cachée possible. Le gros inconvénient est que lorsqu’on perd sa clé privée, et bien c’est foutu, ça marche plus ! Il n’y a plus qu’à en recréer une, et diffuser la nouvelle clé auprès de vos correspondants, car il n’existe aucun moyen de la récupérer.

Comment ça s’installe ?

Sur les systèmes Linux, les outils nécessaires sont généralement installés par défaut. Après, le plus important est de stocker la clé privée en lieu sûr. La première opération à réaliser est la génération d’une paire de clés avec la commande --gen-key :

gpg --gen-key

On aura besoin durant cette procédure de disposer d’une quantité d’aléa (ou entropie) suffisante. Afin de voir l’entropie disponible sur un système Linux, on peut utiliser la commande suivante1 :

watch cat /proc/sys/kernel/random/entropy_avail

S’il vous en manque, il peut être judicieux d’utiliser le package rng-tools (sur Ubuntu).

apt-get install -y rng-tools

Pour générer un peu d’entropie supplémentaire, on peut utiliser la commande suivante :

/usr/sbin/rngd -r /dev/urandom

La seconde mesure consiste à générer un certificat de révocation pour toute une nouvelle paire de clés. La raison de procéder ainsi est qu’il vous faut disposer de la clé privée pour générer son certificat de révocation. Générer le certificat de révocation le plus tôt possible vous met à l’abri de l’oubli de votre clef. Vous devrez bien sûr conserver ce certificat à l’abri. En outre, il doit rester facile et rapide de révoquer une clé, en cas de compromission.

Comment ça marche pour chiffrer/déchiffrer ?

Pour chiffrer :

gpg -e destinataire [message]

Pour déchiffrer :

gpg [-d] [message]

Et pour signer ?

Pour signer et chiffrer un message, la syntaxe complète est :

gpg [-u expéditeur] [-r destinataire] [--armor] --sign --encrypt [message]

On peut faire un chouïa plus simple, pour signer un message avec l’identité par défaut de votre trousseau de clé :

gpg --sign|--clearsign|--detach-sign [message]

L’option --sign vous construit un fichier .gpg illisible, --clearsign produit un fichier au format texte avec le contenu en clair suivi de la signature, et enfin --detach-sign ne fournit que la signature dans un fichier .sig. Ajoutez l’option --armor pour avoir un fichier signature en clair, suffixé par .asc. Si vous prenez l’option --clearsign, cela vous construira un fichier de type :

root@rasp-janiko:/jean/test# cat essai.txt.asc 
-----BEGIN PGP SIGNED MESSAGE----- 
Hash: SHA1 
Ceci est un test. 
-----BEGIN PGP SIGNATURE----- 
Version: GnuPG v1.4.12 (GNU/Linux) 
iQEcBAEBAgAGBQJV+WSgAAoJEN+s4kEe3i4xT6AH/RlkQZyQQ5XkdGmIQGgk8H6h 
C8zK7/RO1XzzP4xyqA59yHfgPgwGJ9PASaaUlOHgLcIbbiTRTrow8ZIPNhBdF4fC 
gEvZfu9p27X6SXXRa/94Lt1uIHDVFhtzWf9YNoytToxRSIf/CvPpTXcHPbnYP7YD 
Gwdz+Qxz8u2vhKJKLk4uXHgJb97IvsgoSfpb7e7TMMqCRIKV2S6T1LyouW+Tyy1Y 
ZerF5rGIWle2rYVQoM5ujuM77q/XaxAZyGQ7fp5rndBSVMBWptK5W9k8Ji4vhCqa 
FqhVdzTvq+DwmsjigCUtLk9uxSdqBhNQ+xb3sSRlyXG1PmnQtigXlUnUs/wBVds= 
=t6tc 
-----END PGP SIGNATURE-----

Pour vérifier la signature, il suffit de taper :

gpg --verify [message]

Si tout va bien, vous aurez :

root@rasp-janiko:/jean/test# gpg --verify essai.txt.asc 
gpg: Signature faite le mer. 16 sept. 2015 14:46:24 CEST avec la clef RSA d'identifiant 1EDE2E31 
gpg: Bonne signature de « Jean GEBAROWSKI (statodynamicien) <jean@geba.fr> » </jean@geba.fr>

Et si la signature est mauvaise ou que le fichier est modifié :

root@rasp-janiko:/jean/test# gpg --verify essai.txt.asc 
gpg: Signature faite le mer. 16 sept. 2015 14:46:24 CEST avec la clef RSA d'identifiant 1EDE2E31 
gpg: MAUVAISE signature de « Jean GEBAROWSKI (statodynamicien) <jean@geba.fr> » </jean@geba.fr>

Ce qu’il faut vérifier

Comme toujours, ça ne sert à rien d’utiliser des moyens sûrs si on ne vérifie pas leur validité. Quand on reçoit une alerte sur un certificat, il ne faut pas cliquer sur OK sans réfléchir. Pour les clés PGP, on a vu des tentatives d’usurpation reposant sur l’identifiant court (ou short id), qui peut parfois être dupliqué ! Donc en utilisant et/ou important des clés, il ne faut pas de limiter à cet identifiant mais aussi vérifier l’adresse mail23…

Outils et sites utiles

Site officiel

Failles

Une faille a été découverte en mai 20184 dans de nombreux outils de messagerie ou dans leurs plugins mettant en oeuvre PGP et S/MIME. Il s’agirait plus d’une mauvaise implémentation de ces protocoles dans les clients de messagerie que d’autre chose, mais le résultat est le même : il y a danger, même sil l’exploitation n’est pas triviale5.

Le seul conseil pour l’instant est de désactiver le déchiffrement automatique des messages dans les clients de messagerie concernés (tels que Outlook, Thunderbird, Apple Mail, etc.) en supprimant les clés qui y sont stockés, et de désactiver l’affichage HTML. Le déchiffrement ne doit être effectué que dans une application tierce, jusqu’à production du correctif.

Une autre faille a été mise au jour en juin 20186 permettant d’usurper n’importe quelle signature, ce qui est gênant. La version 2.2.8 de GnuPG corrige le tir de cette anomalie qui existait depuis très longtemps, apparemment !

Scan SSL

La confiance n’exclut pas le contrôle, dit-on souvent. Il existe d’excellents outils pour évaluer la sécurité et la robustesse d’un serveur proposant une communication SSL.

Pour ma part, je recommande SSLScan, dont il existe plusieurs variantes. En fouillant un peu, celle qui me semble la plus pertinente est celle de rbsec, car elle est à peu près à jour (elle intègre les versions 1.1 et 1.2 de TLS), et ne mixe pas les technologies puisqu’il s’agit uniquement d’un programme en langage C. Ca permet d’éviter de trop nombreuses dépendances, et ça évite de cumuler les vulnérabilités de multiples technologies (bien que cet aspect puisse être débattu).

Lien interne

  • Test de connexion SSL (par Janiko), à venir

Liens externes