Vos papiers s’il-vous-plait !

La définition la plus simple que je puisse vous donner d’un certificat électronique (ou certificat de clé publique) est la suivante : c’est une garantie d’identité numérique. Autrement dit, une sorte de carte d’identité que vous pouvez brandir fièrement sur le web (mais pas que) afin d’assurer votre identité. Effet de bord intéressant de son fonctionnement : cela permet aussi de chiffrer des échanges.

Garantir l’origine d’une donnée : un processus pas si simple

Dans la vie de tous les jours, si vous voulez garantir qu’un papier provient de vous, vous allez le signer. C’est un geste simple qu’on fait sans y penser mais qui n’est pas infaillible. On peut en effet s’imaginer que quelqu’un usurpe votre identité en forgeant votre signature pour parvenir à ses fins. Dans les faits, si on est sur une procédure importante (signature de contrat par exemple), on vous demandera des papiers d’identité pour garantir qu’on est sur la bonne personne et on va donc d’une certaine manière doubler, tripler, etc. le nombre de contrôles mis en place pour garantir votre identité.

Dans le monde du numérique, cela se complique. On s’imagine difficilement se déplacer physiquement auprès de chaque possesseur de site web et de chaque récipiendaire de mail important pour lui présenter notre carte d’identité qu’il pourra comparer à notre tronche (petit aparté : je ne ressemble absolument plus à ma photo d’identité, le principe même de cette photo – qui en plus est en noir et blanc – m’a toujours échappé…). Cela casserait un poil le principe de l’abattement des distances et frontières que nous permet le web.

Alors on fait quoi du coup ? On scanne une signature papier et on l’adjoint à nos échanges numériques ? On se créé une catch phrase ou une chaine aléatoire de caractères qu’on met à la fin de nos mails en guise de signature ?

Les idées ci-dessus sont simples à mettre en œuvre mais présentent un gros défaut : le niveau d’assurance apporté est d’environ… 0 ! Eh bien oui, dans le cas d’un document papier signé de votre main, chaque nouvelle signature sera légèrement différente et en cas de forgerie, on pourra toujours contester et recourir à des experts pour authentifier ou non ladite signature. En revanche, pour du numérique, il est tout de suite possible pour quiconque de faire une copie conforme de votre signature puisque vous la transmettez à chacun de vos échanges.

Clé publique / Clé privée

Je vous rassure, on dispose depuis longtemps d’une bonne solution, qui consiste à utiliser des méthodes de cryptographie asymétriques (voir l’article introductif à ce sujet). Pour faire simple : on dispose de deux blocs de données, appelées clé publique et clé privée, permettant de chiffrer et déchiffrer des messages. Un message chiffré par la clé publique ne pourra être déchiffré qu’en utilisant la clé privée associée et réciproquement. Comme leur nom l’indique, la clé publique peut – et, dans notre cas d’espèce, doit – être diffusée sans restriction et la clé privée doit impérativement être gardée secrète par son propriétaire.

Seule la clé privée permet d’encrypter un message de sorte que la clé publique puisse le décrypter et on peut donc utiliser le chiffrement pour authentifier l’identité de la personne (ou du système) qui a émis le message. C’est là l’idée derrière les certificats. En fait, lorsque par exemple site web (dans les faits, le serveur) dispose d’un certificat, il communique sa clé publique aux personnes et systèmes qui veulent communiquer avec lui (typiquement votre navigateur).

Non-TLS HTTP : protocole du passé

Le temps est une notion bien relative lorsqu’on parle de technologies du numérique : une techno qui n’a pas évolué ou a été abandonnée depuis seulement quelques années passe très vite au statut de relique. Ceci en tête, je vais vous parler de temps immémoriaux pas si lointains que ça.

Dans l’ancien temps, lorsque vous naviguiez sur le web, vous accédiez à des URLs du type http://www.domaine.com/path. Ce petit HTTP en début de ligne signifie HyperText Transfer Protocol, qui est le nom d’un protocole utilisé par nos navigateurs pour transférer textes, images, vidéos et autres fichiers à travers le web.

Un beau jour, de petits malins se sont dit qu’ils allaient s’interposer entre les clients (votre PC, smartphone ou autre terminal qui accède à internet) et les serveurs (machines distantes qui hébergent par exemple vos sites web) pour essayer :

• d’intercepter les données sur le chemin (typiquement login/mdp ou données bancaires)
• de se faire directement passer pour le serveur en question en répliquant le site web (cela suppose un peu connaissances sur le fonctionnement des DNS – dont on reparlera sans doute une autre fois – mais c’est très faisable)

On s’est donc retrouvés face à un double problème : il fallait pouvoir certifier l’identité des serveurs avec lesquels on communique et protéger les informations qu’on lui transmet. Solution miracle : les certificats ! Ils permettent justement d’assurer l’identité numérique d’une entité et de crypter les flux qui lui sont destinés.

Un site qui utilise un certificat est identifiable facilement par plusieurs témoins. Déjà, le préfixe de protocole de l’URL n’est plus HTTP, mais HTTPS, le S voulant dire Secure. De fait, on a toujours un transfert HTTP, mais les données sont préalablement passées par la couche TLS (Transport Layer Security) ou SSL (Secure Sockets Layer) qui vient crypter les échanges sur la base du certificat (et donc de la clé publique) transmis par le serveur. Notez que TLS est le successeur plus sûr de SSL. Ensuite, votre navigateur doit afficher une icône qui témoigne de la sécurisation apportée et de la confiance qu’il a envers ce site web (oui, c’est bien votre navigateur qui fait confiance en votre nom).

Je parle de ça, là-haut :

Il existe très peu de sites qui utilisent encore le HTTP non-TLS (ou tout du moins non Secure). De fait, soyez conscients qu’un site non sécurisé ne garantit ni son authenticité ni la sécurité des données que vous lui transmettez. Il convient donc de n’accorder aucune confiance à un tel site et de n’y saisir aucune information personnelle.

Et si j’en fais un faux ?

Faites demi-tour dès que possible

Je vous ai dit plus haut que le certificat est le garant de l’identité numérique de nos systèmes puisque seule la clé privée associée peut avoir chiffré le message.

Ceux qui suivent ont aussi remarqué que j’ai écrit plus bas (enfin, plus haut aussi, mais plus bas que l’extrait que je citais à l’instant ; vous suivez ?) que mon navigateur, lorsqu’il contacte un serveur via HTTPS, se voit communiquer en retour le certificat, donc la clé publique, de ce serveur.

Les petits malins qui ont fait 51 245 + 1 574 = 52 819 (oui, on est quand même dans un truc un poil moins immédiat pour le commun des mortels que 1 + 1 = 2) se disent peut-être la chose suivante : “mais alors, si je me tente un petit man in the middle où je simule le serveur (le truc où il faut connaître un peu l’idée derrière un DNS), je peux avoir ma propre clé privée du faux serveur avec le certificat associé, envoyer ledit certificat au client et hop : dans son cul !?“.

Pas tout à fait ! J’ai aussi dit plus haut que votre navigateur accorde ou non sa confiance aux sites web et qu’il saura vous le faire savoir. Ainsi, si quelqu’un usurpe l’identité d’un serveur, votre navigateur saura le détecter en étudiant la signature de ce certificat et vous prévenir qu’il ne faut pas y aller car la connexion n’est pas sécurisée (dans les faits le faux certificat sécurisera bien le flux en lui-même, mais par contre ce dernier sera transmis à la mauvaise personne, qui dispose de fait des moyens de le déchiffrer).

Il s’agit de ce genre d’avertissement (notez le warning sur le cadenas à gauche de l’URL) :

Plusieurs types d’erreur de certificat peuvent mener à cette page (Firefox donne plus de détails si on clique sur “Avancé…”) mais globalement la réaction à avoir est la suivante : cassez-vous !

Il n’y a qu’un cas valable où vous pourriez être amené à aller de l’avant, c’est s’il s’agit d’un serveur (ou d’une application locale) que vous administrez vous-même. Toutefois, dans ce cas je vous enjoins à corriger le problème plutôt que de créer une exception dans votre navigateur, parce qu’il serait un poil con de créer une exception, de l’oublier et de se faire exploiter cette exception plus tard par quelqu’un de mal intentionné !

Je m’explique : une fois l’exception créée dans votre navigateur, il ne vous donnera plus jamais de warnings concernant l’URL en question (il maintient une liste des exceptions que vous lui avez demandées de faire). Du coup vous devenez instantanément vulnérable à une attaque de type man in the middle sur l’URL en question, puisque vous acceptez de fait des certificats foireux.

En résumé : idéalement ne mettez jamais en place d’exception (même pour localhost – un article à paraître bientôt vous expliquera comment faire ça proprement et simplement pour vos développements locaux) mais si vous le faites pensez à l’enlever immédiatement quand vous avez fini, ça vous évitera peut-être des problèmes.

Encore ces histoires de signature

“Tu nous a dit que le certificat était en fait une forme de signature et après tu nous parles de la signature du certificat lui-même. Je suis perdu : on signe la signature ? Mais alors, on a un certificat sur le certificat ? Et du coup qui signe le certificat qui sert à signer les signatures ?!? Oh putain la migraine !”

Pas de panique, j’ai bel et bien dit tout ça et oui, en effet, il y a des certificats “maîtres” émis par des autorités de certification reconnues, qui sont utilisés pour signer les certificats utilisés par les sites web et autres serveurs. Ils viennent attester que le certificat que votre navigateur reçoit a bien été émis sur demande du propriétaire légitime du domaine – plus précisément du FQDN : Fully Qualified Domain Name – que vous consultez.

Votre navigateur connait toutes les autorités de certification sérieuses et est donc capable au premier coup d’œil de savoir si le certificat arboré par un site web est autosigné (autrement dit aucun certificat tiers ne certifie son authenticité – c’est le cas de celui que j’ai utilisé pour générer l’erreur du screenshot plus haut), s’il a été signé par une autorité qui n’est pas reconnue comme étant de confiance ou si il est bien émis par une autorité reconnue et qu’il ne présente donc pas de risque de sécurité.

Lorsque vous êtes détenteur d’un nom de domaine et que vous souhaitez avoir un certificat pour ce dernier, l’autorité de certification (marre de l’écrire donc je mettrai CA – Certificate Authority – pour la suite) que vous avez choisie va mettre en place un processus pour s’assurer que vous êtes bien le propriétaire légitime du nom de domaine (là aussi, marre, on va donc partir sur DN – Domain Name). Ainsi, pas possible de faire émettre un “vrai” certificat signé par un CA reconnu pour un DN que vous ne possédez pas.

Durée de vie d’un certificat

Il est important d’avoir conscience d’une chose à l’ère numérique dans laquelle on vit : aucune sécurité n’est parfaite. Il est en effet impossible d’avoir une sécurisation absolue, d’autant plus dans le cadre du chiffrement qui se veut par essence réversible. Tout est forcément crackable (oui, j’assume cet orthographe), ce n’est qu’une question de temps.

Pour pallier cette fatalité, un certificat est associé à une date de fin au-delà de laquelle sa sécurité n’est plus garantie (et donc votre navigateur vous enverra à nouveau des avertissements qu’il ne faut surtout pas ignorer). Un peu avant sa date de fin, un nouveau certificat sera généré pour le remplacer et assurer la relève.

Le but du jeu est donc de trouver la bonne position du curseur entre une durée de vie trop courte (et donc des certificats que je passe mon temps à renouveler) et une durée de vie trop longue (qui ouvre le risque que le certificat soit cracké “de son vivant”).

Tous les services sérieux basés sur la cryptographie utilisent ce même principe de renouvellement régulier du chiffrement de sorte que le temps nécessaire à son crackage soit largement supérieur à son temps de validité. C’est notamment pour cela qu’on vous change votre carte bancaire tous les trois ans.

Avant de se laisser

Il ne faut pas confondre chaîne de certification valide (et donc beau cadenas à côté de l’URL dans le navigateur) et sécurité de vos données. Je sais que j’ai parlé de sécurisation jusqu’à maintenant, mais on partait du principe que vous faisiez confiance in fine au serveur que vous tentez de joindre. De fait, on peut envisager un certificat légitime signé par un CA reconnu qui mène à un site web malicieux ou encore à un serveur mal sécurisé.

Pour reprendre l’exemple de notre fonctionnalité de login qu’on a vue au précédent article Hash & chiffrement : on repose sur le chiffrement pour que le couple login/mdp transite jusqu’au serveur de façon sécurisée, puis le serveur créé un hash du mdp et le compare à sa base de données.

Ça, c’est dans un monde parfait mais si le développeur qui a fait le backend (partie de l’application qui tourne côté serveur) n’est pas bien informé sur la sécurité informatique, peut-être que dans les faits il ne hash pas votre mot de passe. Du coup vos informations sont vulnérables du fait de cette faille de sécurité.

Autre scénario : le développeur sait très bien ce qu’il fait et stocke bien les hash des mdp dans sa base de données (aujourd’hui je suis flemmard, on part sur DB –Data Base – pour les prochaines fois ?), mais garde volontairement une copie en clair aussi “pour son usage personnel”…

Donc gardez bien ça en tête :

• pas de certificat valide = demi-tour, je ne suis sûrement pas où je pense être
• certificat valide = mes données vont au bon endroit et sont chiffrées en chemin ; je reste par contre conscient que j’accorde ma confiance au développeur du serveur sur ce qu’il va en faire par la suite