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

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…

Où vérifier ?

Le réseau SKS Keyserver (Synchronizing Key Server) a été historiquement le principal système de distribution des clés publiques. Le réseau SKS est en déclin (relatif) car il est vulnérable à des attaques comme l’empoisonnement de clés (« key poisoning »). On a, par exemple :

Sinon vous pouvez vous tourner vers :

  • keys.openpgp.org qui s’est modernisé, et qui est intégré par défaut dans plusieurs outils GPG.

Pour importer une clé : 

gpg --keyserver hkps://keys.openpgp.org --recv-keys

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).

Continuer la lecture →

Heartbleed

Heartbleed est le nom donné à une faille dans une implémentation d’openSSL.

OpenSSL : c’est quoi ?

Avant toute chose, il faut savoir que SSL (dont les versions récentes s’appellent TLS) est un protocole qui permet de chiffrer des communications sur internet et d’authentifier une machine (un serveur web par exemple). Chiffrer, c’est rendre illisible un message à tous ceux qui ne disposent pas de la clé de déchiffrement. Ce protocole est très utilisé sur internet, et openSSL est un des outils d’implémentation de SSL parmi les plus utilisés.

Quand vous vous connectez de manière sécurisée sur un site web, vous passez par https et plus de la moitié de serveurs web dans le monde utilisent openSSL pour réaliser cette connexion https.

Quelle est la faille ?

La faille permettrait à un attaquant d’avoir accès à certaines données chiffrées lors des communications SSL sur les sites utilisant les versions vulnérables. En conséquence, certains mots de passe (voire certains certificats) pourraient être compromis et donc réutilisés par l’attaquant.

Quel est le composant touché ?

La faille est exploitable quand une version vulnérable d’openSSL est installée sur le serveur web. OpenSSL est un logiciel open source. Seules certaines versions sont vulnérables :

La branche 0.9.8 n’est pas touchée, et la correction est présente à partir de la version 1.0.1g. 

Sources

  • http://heartbleed.com/
  • https://www.openssl.org/news/secadv/20140407.txt
  • https://www.20minutes.fr/high-tech/1348577-20140410-heartbleed-faire-proteger-faille-securite-geante
  • http://www.lemonde.fr/technologies/article/2014/04/11/faille-heartbleed-les-sites-pour-lesquels-il-est-conseille-de-changer-son-mot-de-passe_4399564_651865.html
  • http://www.lemonde.fr/technologies/article/2014/04/09/une-enorme-faille-de-securite-dans-de-nombreux-sites-internet_4397995_651865.html
  • https://www.nextinpact.com/news/86941-heartbleed-openssl-et-question-securite-expliques-simplement.htm

Poodle

Poodle est le nom donné à une faille inhérente au protocole SSL v3.

Désactivation de SSLv2 et SSLv3 sur Plesk

Sur Plesk, il est possible de désactiver SSL v2 et v3 de façon définitive, grâce à un paramètre disablesslv3 qu’il faut positionner à true. J’avoue avoir eu un peu de mal à trouver comment faire, mais une fois que c’est fait, cela débarrasse de ce boulet !

Pour plus d’informations, il faut aller sur le forum Plesk. Et pour mémoire, voici la manip : 

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` -Dpsa -e "insert into misc values('disablesslv3', 'true')"


# /usr/local/psa/admin/bin/httpdmng --reconfigure-all

La 1ère ligne positionne le paramètre, la 2e permet de reconstruire les configurations nécessaires. Pour vérifier, tapez : 

# cat /var/www/vhosts/system/*/conf/last_nginx.conf | grep ssl_protocols

Il s’agit de la configuration de nginx, et les vieux SSL doivent avoir disparu.

Voir aussi Logjam.

SHA-1

SHA-1 est le nom d’un algorithme de hachage très utilisé en cryptographie.

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

Beaucoup de bruits courent en 2014-2015 au sujet de la vulnérabilité potentielle de cet algorithme de hachage. Il est très fortement utilisé dans toute l’industrie informatique, notamment dans les certificats numériques (mais pas uniquement).

Or des travaux ont mis en évidence des failles possibles sur cet algorithme dès 2005. Toutefois, cela restait théorique car hors de portée de la puissance de calcul disponible à l’époque. Dix ans plus tard, les choses ont bien sûr évolué.

Continuer la lecture →

Freak

Une de plus ! Freak est une faille quasiment de conception de SSL. Une fonctionnalité, diront certains.

Dans les années 1990, l’administration américaine s’inquiétait de la prolifération des systèmes de chiffrement, et craignait de ne plus en avoir le contrôle (comprendre : ne plus pouvoir déchiffrer les messages codés, en cas de besoin). Elle a donc décidée d’interdire l’exportation de tout ce qui était indéchiffrable avec les moyens de l’époque, d’où une limitation de la taille de clés (par exemple).

Les outils se sont adaptés en conséquence, prévoyant un mécanisme spécial « export » qui ramenait automatiquement à des valeurs convenables la complexité du chiffrement lors d’un échange, même si les deux parties pouvaient faire beaucoup mieux.

Avec le temps, cette limitation est tombée, mais le mécanisme servant à réduire la taille des clés a été reconduit dans la plupart des outils utilisés. Et on s’en est rendu compte seulement en 2015, alors que cette fonctionnalité était largement documentée, et n’était même pas cachée1 !

FREAK a touché toutes les bibliothèques SSL/TLS ou applications utilisant SSL/TLS ayant respecté la réglementation… et oublié de supprimé cette limitation quand les règles se sont assouplies. Exemple : openSSL, S-Channel, Chrome…

Liens externes

Logjam

Logjam est une nouvelle faille dans le désormais périlleux chemin de la cryptographie, touchant une étape de négociation lors d’une connexion [[TLS|SSL/TLS]]. Même si, comme Freak, son exploitation n’est pas forcément facile, cela va imposer à moyen terme l’augmentation de la longueur de certaines clés, ou l’utilisation de certains algorithmes à la place de certains jugés trop faibles, ce qui aura surtout pour effet de compliquer encore la vie des webmasters (et des navigateurs web).

En effet, à force d’augmenter la solidité des mécanismes de sécurité, on finit par demander beaucoup de calculs à la fois au serveur et au navigateur ; or tout le monde n’est pas obligatoirement à niveau, et on pourrait finir (par exemple) par rendre certains sites inaccessibles aux utilisateurs dont les ordinateurs (ou les navigateurs web) ne sauraient pas composer avec cette complexité croissante.

Une synthèse, avec un outil de test ainsi que les recommandations à suivre sont ici : weakdh.org.

Désactivation sur Plesk

Sur Plesk, si vous avez une version 2.2 d’Apache couplé à nginx, il faudra un peu ruser pour ne plus être exposé à Logjam. pour plus d »infos, allez voir le forum.

Il faut en premier lieu créer un fichier DH personnalisé, de complexité (longueur) suffisante : 

openssl dhparam -out dhparams.pem 2048

Ensuite, il faut un template personnalisé pour ses sites web, dans /usr/local/psa/admin/conf/templates/custom/domain. Le fichier à modifier est nginxDomainVirtualHost.php. Il faut ajouter l’option ssl_dhparam en lui mettant le fichier que l’on vient de créer. 

ssl_ciphers                 HIGH:!aNULL:!MD5;


ssl_prefer_server_ciphers   on;


ssl_dhparam             /dhparams.pem;

Ensuite on reconfigure et ça devrait aller. 

# /usr/local/psa/admin/bin/httpdmng --reconfigure-all

Pour vérifier, tapez : 

# cat /var/www/vhosts/system/*/conf/last_nginx.conf | grep dh_param

Liens externes

  • http://www.nextinpact.com/news/94144-logjam-apres-freak-nouvelle-faille-dans-chiffrement-connexions.htm
  • http://forum.odin.com/threads/ssl-poodle-sslv3-bug.323338/#post-761018
  • https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

Certificat

Un certificat (en réalité un certificat numérique, mais je simplifie la terminologie car je ne parle que de sécurité informatique) est un document informatique permettant de prouver l’authenticité et l’intégrité d’un élément (une clé) de chiffrement public.

Il existe plusieurs types de certificats, ayant des caractéristiques et des niveaux de garantie assez différents.

Caractéristiques principales

Classes de certificats

Bien qu’il n’y ait pas de standard en la matière, les autorités de confiance délivrant les certificats proposent différents niveaux de garanties, déclinées souvent en classes.

Etendue de la validation

Il y a trois grand types de validation :

Domain Validation (DV)

C’est le type le plus simple de validation pour un certificat. L’autorité de certification (AC) émettra un certificat de validation de domaine à toute personne apparaissant comme contact administratif dans le registre public associé à chaque nom de domaine (ou suivant des contrôles assez simples se basant sur une adresse mail). La seule garantie obtenue est que le nom de domaine est bien celui qui apparaît, ce qui peut suffire à certains usages. Cela permet toutefois de chiffrer le trafic entre l’internaute et le site en question, et d’établir un minimum de confiance de façon assez rapide (pour le propriétaire du site).

Organization Validation (OV)

Ici, l’Autorité de Certification contrôle également l’identité de l’entreprise et de la personne formulant la demande de certificat. C’est un niveau supérieur, qui permet d’associer une identité à un nom de domaine, ce qui peut trouver son utilité quand des noms de domaines peuvent être ambigus.

Extended Validation (EV)

Édictées par le CA Browser Forum1, les directives EV2 obligent l’Autorité de Certification à effectuer une vérification beaucoup plus poussée de l’identité de l’entreprise ou de la personne demandant le certificat. Le niveau de garantie est supérieur à un certificat OV, ce qui est attesté par une barre verte contenant le nom de l’organisation dans certains navigateurs. En général, ils ne permettent pas le multi-domaine (SAN) ni le wildcard.

Type de certificat

Wildcard

Multi-domaine (SAN)

Usage

Validité d’un certificat

Que doit-on vérifier pour pouvoir dire qu’un certificat est valide ?

  1. Le certificat doit avoir un format valide ;
  2. le certificat doit être valide au moment de son utilisation (date de fin mais aussi date de début) ;
  3. il doit être issu d’une autorité de confiance (CA) reconnue et fiable ;
  4. le nom du service correspond bien à celui que l’on veut (champ CN du sujet) ;
  5. l’usage du certificat est conforme à celui qu’on veut en faire, en vérifiant :
    1. Basic constraints : indique notamment s’il s’agit d’un certificat racine ou non (CA:FALSE par exemple)
    2. Key Usage : signature, chiffrement, etc.
    3. Extended Key Usage : authentification du site web, par exemple ;
  6. le certificat ne doit pas avoir été révoqué (mais c’est bien rare que cette vérification soit faite…).

Applications

SSL/TLS

SSL et TLS sont deux noms différents pour la même chose. Enfin presque : il y a eu plusieurs versions de SSL (notamment v2 et v3) puis l’appellation TLS a remplacé SSL. Nous avons donc eu TLS 1.0, puis TLS 1.1 et maintenant TLS 1.2.

SSL est un protocole permettant de sécuriser des échanges de flux réseaux. Comme tout protocole, il n’est constitué que de spécifications : on dit quoi faire et comment. Après, ce sont des programmes (des librairies…) qui implémentent (mettent en oeuvre en pratique) ce protocole.

SuperFish

Etablissement d’une session TLS

Avant d’échanger des messages de façon sécurisée, il faut commencer par se mettre d’accord sur la façon de faire.

Hello client (ClientHello)

Le 1er message est envoyé par le client au serveur. Ce message contient :

  • Le numéro de version de la version TLS la plus récente supportée par le client ;
  • la date et heure client ;
  • 28 octets aléatoires ;
  • un numéro de session (en cas de reprise de session) ;
  • la liste des méthodes cryptographiques supportées par le client ;
  • la liste des méthode de compression supportées ;
  • certaines valeurs spécifiques comme le nom du service demandé (Server Name Indication).

Premier retour serveur

Le serveur va ensuite envoyer un paquet de messages pour avancer dans le dialogue.

Hello serveur (ServerHello)

Le serveur va d’abord poliment renvoyer son bonjour. Il va indiquer :

  • La version du protocole SSL/TLS qu’il souhaite utiliser ;
  • la date et heure côté serveur ;
  • 28 octets aléatoires ;
  • un numéro de session si besoin ;
  • l’algorithme cryptographique et l’algorithme de compression retenus pour cette session, en fonction de ce que supporte le client.

Présentation des certificats du serveur (Certificate)

Le serveur envoie ensuite ses certificats.

à approfondir

Echange de clé serveur (ServerKeyExchange)

Le contenu de cette partie est variable. Elle est fonction de ce qui a été négocié auparavant, principalement des algorithmes cryptographiques retenus.

  • Dans le cas d’un échange de type Diffie-Hellman, ce message contient les paramètres de cet échange. Ils sont générés aléatoirement par le serveur et signés par la clé privée du serveur (sauf dans le cas d’un échangé DH/ECDH anonyme).
  • Dans les autres cas, ce message n’existe pas car les informations nécessaires sont dans le certificat.

Fin du bonjour (HelloDone)

Ce message marque la fin de cette étape. Mais ça n’est pas fini pour autant.

Pre-master secret

Voici maintenant une étape tout aussi importante dans l’établissement de l’échange : l’échange d’un pre-master secret, valeur essentielle pour la connexion, et qui ne doit être connue que des deux parties (Alice et Bob). Il existe plusieurs méthodes pour cela :

  • RSA : la valeur secrète est générée par le client, aléatoirement, et elle est envoyée au serveur chiffrée avec la clé publique du serveur (donc seul le serveur peut la déchiffrer), dans un message ClientKeyExchange.
  • Diffie-Hellman ou Elliptic Curve Diffie-Hellman (DH ou ECDH) : la valeur secrète est négociée via l’algorithme de Diffie-Hellman. Il en existe une variante basée sur les courbes elliptiques. Les paramètres côté serveur sont inclus dans le certificat ; côté client, c’est également dans le certificat si le client en présente un, sinon il doit en générer aléatoirement.
  • Diffie-Hellman Ephemeral (DHE) avec également une variante basée sur les courbes elliptiques (ECDHE) : les valeurs secrètes sont générées aléatoirement, dans tous les cas, et de façon unique pour chaque transaction. Côté serveur, les paramètres sont signés avec sa clé privée.
  • Diffie-Hellman anonyme, avec variante EC : C’est du DHE mais sans chiffrement côté serveur. En conséquence, cette négociation est vulnérable aux attaques MITM.

On en parle, hélas

Oui, on parle de SSL malheureusement, car on se rend compte de son importance et de la menace représentée par les failles du protocole ou de son implémentations. Freak, Poodle ou Heartbleed sont des exemples de failles ayant fortement impacté le monde informatique mais aussi, indirectement, les utilisateurs.

Quelles versions utiliser ?

Le conseil général est le suivant : toujours utiliser la dernièr version quand c’est possible.

Est-ce toujours possible ?

Comme le titre le laisse entendre : non. Comme vu plus haut, la connexion en SSL/TLS se fait sur la base d’une négociation entre le serveur (le site internet) et le client (le navigateur web). Les deux essayent généralement d’utiliser les versions les plus récentes et les plus sécurisées, mais il arrive souvent que les navigateurs ne soient pas à jour et ne connaissent tout simplement pas les versions récentes de TLS.

Y a-t-il des versions à éviter ?

Oui, car certaines versions contiennent des failles intrinsèques (par exemple Poodle). Par ailleurs, avec le temps, certaines attaquent deviennent plus faciles : soit parce qu’elles sont mieux connues, soit parce que la puissance de calcul nécessaire est plus facilement accessible. A fin juin 2015, on considère que SSL v2 et SSL v31 ne doivent plus être utilisées.

Liens

Liens internes

Liens externes

Registre distribué

La technologie de registre distribué a le vent en poupe depuis quelques années (depuis la popularisation des cryptomonnaies telles que le bitcoin). On appelle aussi ça « chaîne de blocs », traduction plus littérale mais technique : ça dit ce que c’est, mais pas ce que ça fait, à l’inverse de « registre distribué ».

Continuer la lecture →