18-01-2017
Cryptographie et applications quotidiennes
Sommaire
Problématique générale
Trois objectifs à atteindre
1ère fonction de base : la cryptographie symétrique
2ème fonction de base : la cryptographie asymétrique
3ème fonction de base : la fonction de hachage
Echanges cryptés combinant les 3 techniques de base
Certificat électronique = clé publique + signature numérique
Code barres 2D-Doc
Infrastructure à clés publiques
Certificat racine de l’Etat Français
Connexion Internet en HTTPS (protocoles SSL et TLS)
Solidité des algorithmes de cryptage, et masque jetable
Surveillance Internet crypté grâce à un proxy SSL : légal !
Faux certificat validé par une autorité officielle : illégal !
Limites de TLS
Problématique générale
Alice veut envoyer un message confidentiel à Bob via Internet, qui est un réseau non sécurisé.
Eve (de l'anglais eavesdropper) est une écouteuse passive. Elle peut écouter les échanges d'Alice et de Bob sur Internet, mais elle ne peut pas les modifier.
Mallory (ou Mallet, pour malicieux) est un attaquant actif. Au contraire d'Eve, Mallory peut modifier les messages, substituer les siens, remettre en jeu d'anciens messages, etc…
Trois objectifs à atteindre
1) Confidentialité : seul le destinataire légitime peut déchiffrer le message. Par exemple : seul Bob pourra déchiffrer le message envoyé par Alice. Eve et Mallory ne peuvent pas décrypter le message.
2) Authenticité : certitude que l’auteur du message est bien celui qui a signé le message. Par exemple : Bob est certain que l’information provient d’Alice, et pas de Mallory.
Remarque : l'identification permet de connaître l'identité d'une personne (cas de présentation d’une pièce d’identité) alors que l'authentification permet de vérifier cette identité (cas de prise d’empreintes digitales).
3) Intégrité : aucune altération ou destruction n’affecte le message envoyé. Par exemple : Mallory ne peut modifier le message sans que Bob ne s’en aperçoive.
Pour répondre à ces objectifs, il existe actuellement 3 méthodes de base qui doivent être combinées : la cryptographie symétrique, la cryptographie asymétrique, et la fonction de hachage.
1ère fonction de base : la cryptographie symétrique
Existence d’une unique clé secrète (K) qui permet à la fois de chiffrer et de déchiffrer un message. C’est le système de cryptage le plus vieux du monde. L’algorithme de cryptage est noté C.
CK(message)= crypt
CK(crypt)= message
Problèmes de cette technique :
- la clé doit être échangée entre les deux correspondants de façon sûre pour rester totalement confidentielle. Or Internet n’est pas un réseau sécurisé, donc l’échange de la clé par ce moyen est délicat.
- en cas de correspondants nombreux, il faut autant de clés que de correspondants.
Exemples d’algorithmes de cryptographie symétrique : AES, DES, 3DES, RC4, RC5, MISTY1…
2ème fonction de base : la cryptographie asymétrique
Pour résoudre le problème d’échange de la clé, la cryptographie asymétrique a été mise au point dans les années 1970. Elle se base sur le principe de deux clés :
- une clé publique, permettant le chiffrement ;
- une clé privée, permettant le déchiffrement.
La clé publique est mise à la disposition de tous les internautes pour chiffrer un message. Ce dernier ne pourra être déchiffré qu'avec la clé privée, qui doit rester confidentielle. La fonction de cryptage asymétrique est donc à sens unique, contrairement à la fonction de cryptage symétrique qui est à double sens (d’où les termes de symétrique/asymétrique).
En pratique, on peut aussi crypter avec la clé privée, et décrypter avec la clé publique.
Kpb : clé publique
Kpr : clé privée
C : fonction de chiffrement
D : fonction de déchiffrement
CKpb(message)= crypt
DKpr(crypt)= message
CKpr(message)= crypt
DKpb(crypt)= message
Exemples d’algorithmes de cryptographie asymétrique: RSA, DSA…
Cas 1. Alice utilise Kpb-Bob pour envoyer un message à Bob : CKpb-Bob(message)= crypt
Bob utilise sa clé privée pour déchiffrer le message : DKpr-Bob(crypt)= message
La confidentialité est assurée : Eve ne connaît pas Kpr-Bob donc elle ne peut pas déchiffrer le message.
Mais l’authenticité pose problème : Mallory peut se faire passer pour Alice et envoyer un faux message à Bob. Il lui suffit de faire : CKpb-Bob(faux-message)= crypt
Solution : Alice utilise sa propre clé privée pour authentifier le message avant de l’envoyer.
Cas 2. Alice fait un double cryptage : CKpr-Alice(CKpb-Bob(message))= crypt
Bob utilise d’abord la clé publique d’Alice, puis sa clé privée sur le résultat :
DKpr-Bob(DKpb-Alice (crypt))= message
L’authenticité est assurée : Mallory ne connaît pas Kpr-Alice donc s’il envoie un faux-message à Bob, le premier décryptage par Bob va échouer et Bob saura qu’Alice n’est pas l’auteur du message.
Problème : Alice doit utiliser deux fois la fonction de cryptage, ce qui ralentit considérablement la vitesse de l’échange.
Solution : utiliser une fonction de hachage.
3ème fonction de base : la fonction de hachage
Une fonction de hachage convertit un message en un condensat (= une empreinte = une suite réduite de caractères). Il est impossible de retrouver le message d’origine à partir du condensat : ce n'est donc pas une technique de chiffrement. Par contre, une modification du message d’origine, même mineure, change complètement la valeur du condensat. C’est donc une méthode pour garantir l’intégrité d’un message.
H(message)= condensat_1
H(message_modifié)= condensat_2
Exemples de fonctions de hachage : MD5, SHA-1, SHA-256…
Echanges cryptés combinant les 3 techniques de base
Cas 3 : la signature numérique.
Alice envoie : CKpb-Bob(message)= crypt
Puis à la fin, Alice envoie : CKpr-Alice(H(message))= signature
Bob décrypte d’abord le message : DKpr-Bob(crypt)= message
La confidentialité est assurée : Eve ne connaît pas Kpr-Bob donc elle ne peut pas déchiffrer le message.
Bob décrypte ensuite la signature : DKpb-Alice(signature)= condensat_1
Puis il applique la même fonction de hachage au message décrypté : H(message)= condensat_2
La confidentialité est assurée : bien que Eve peut obtenir condensat_1, elle ne peut pas remonter au message d’origine (propriété de la fonction de hachage).
L’authenticité et l’intégrité sont assurées : il suffit à Bob de vérifier que condensat_1 = condensat_2.
Si oui alors le message provient bien de Alice, car seule Alice possède Kpr-Alice, et donc elle seule a pu créer la signature.
Si Mallory envoie un faux message à Bob, il ne pourra envoyer une fausse signature à Bob car il ne connaît pas Kpr-Alice. Bob saura que le message est un faux.
De plus, Alice ne peut répudier son message (cad nier en être l’auteur), puisque elle seule possède Kpr-Alice.
Cas 4 : signature numérique puis cryptage symétrique.
Problème : le cas 3 est plus rapide que le cas 2, néanmoins, il est possible d’accélérer encore l’envoi. En effet, la cryptographie symétrique est beaucoup plus rapide que la cryptographie symétrique. Par ex, DES est 1000 fois plus rapide que RSA.
Solution : on utilise d’abord la cryptographie asymétrique pour échanger une clé secrète, puis ensuite cette clé secrète est utilisée pour le chiffrement symétrique du reste de l’échange. A la fin de l’échange, la clé secrète est détruite.
Certificat électronique = clé publique + signature numérique
Les cas 3 et 4 utilisent la clé publique comme un moyen d’identifier et d’authentifier les correspondants. C’est sur ce système que se basent les certificats. Un certificat électronique est un fichier qui contient un ensemble de données, dont :
- au moins une clé publique,
- des informations d'identification, par exemple : nom, localisation, adresse électronique etc…
- au moins une signature (issue du cryptage des informations précédentes à l’aide d’une clé privée). La signature permet de prêter confiance (ou non) à l'exactitude des informations du certificat. Elle est essentielle au sein de l'infrastructures à clés publiques (cf plus bas).
Certains certificats électroniques sont déjà présents sur les ordinateurs des clients (= intégrés aux logiciels des navigateurs). Pour afficher les certificats intégrés au navigateur Mozilla Firefox :
Outils > Options > Avancées > Certificats > Afficher Les Certificats.
Un certificat est utilisé pour :
- identifier et authentifier une personne physique ou morale. Pour cela, la signature du certificat est décryptée avec une clé publique de confiance déjà présente dans le navigateur : si le résultat est cohérent alors le certificat est authentique, et l’intégrité des informations du certificat est certaine.
- chiffrer des échanges après l’authentification. Le navigateur utilise ensuite la clé publique présente dans le certificat pour chiffrer ses premiers échanges avec le serveur (cf solution du cas 4).
Code barres 2D-Doc
En 2013, l'Agence Nationale des Titres Sécurisés (ANTS) a défini la norme 2D-Doc pour faire face aux faux justificatifs présentés en mairie ou en préfecture. Cette norme permet de sécuriser les données échangées sous forme papier entre l'usager et l'administration. Les documents ciblés concernent en particulier les justificatifs (factures EDF, eau, téléphone, quittances d'assurance et de loyer, RIB, revenus…)
Une entreprise ou une collectivité, qui souhaite intégrer des codes 2D-Doc sur les documents qu'elle émet, doit obtenir un certificat numérique accrédité par l'ANTS.
Le 2D-DOC est un code Datamatrix (= code barres bidimensionnel) qui contient les informations clés du document : le type de document, le nom et le prénom de l'émetteur, la civilité, l'adresse, le numéro de facture, la date d'émission du document…
Ces informations sont verrouillées par une signature électronique (cf cas 3). Elle garantit l'identification de l'organisme émetteur et l'intégrité du document. Le code 2D-DOC est donc une sorte de certificat électronique, mais sous forme papier, vérifiable par une machine (de type scanner ou lecteur de code à barres).
Infrastructure à clés publiques
Les échanges sécurisés sur Internet sont donc basés sur la tenue et la mise à jour des certificats électroniques, qui contiennent des clés publiques et des signatures numériques. Ces signatures sont elles mêmes authentifiées par des certificats de plus haute autorité, déjà présents dans les navigateurs internet. Ces certificats sont appelés certificats racines : ils sont au sommet de l'arborescence de certification. Tous les certificats immédiatement sous le certificat racine héritent de la confiance de cette racine. Les certificats situés plus bas dans la structure (= certificats subordonnés) dépendent également du niveau de confiance accordée aux intermédiaires, souvent désignés sous le nom d'autorités de certification subordonnées. C'est cette relation qui est à la base de la chaîne de confiance (= toile de confiance).
Pour connaître la chaîne de confiance des certificats lors de la visite d’un site web dans Mozilla Firefox :
Cliquer sur le cadenas à côté de l’URL du site web > flèche droite > Plus d’Informations > Sécurité > Afficher Le Certificat : puis onglet Détails.
La hiérarchie des certificats est alors affichée :
Dans cet exemple, le site web visité gnutls.org utilise le certificat « Gandi Standard SSL CA 2 », lui-même certifié par le certificat racine « USERTrust RSA Certification Authority » déjà présent dans Mozilla Firefox.
Les autorités publiques et/ou de gouvernance de l'Internet diffusent leurs certificats racines aux principaux producteurs de systèmes d'exploitation et de navigateurs web (tels que Mozilla Firefox, Google Chrome, Microsoft Internet Explorer…) qui les incluent alors nativement. Ces autorités sont appelées autorités de certifications (AC).
Certificat racine de l’Etat Français
Avant 2007, l’Etat Français n’avait pas de certificat racine. Les administrations devaient donc se faire elles-mêmes certifier par des autorités privées, ce service étant payant !
Pour y échapper, l’Assedic avait mis en place son propre certificat, mais qui n’était pas reconnu par les navigateurs internet. Cela a gravement perturbé la connexion au site web de l’ASSEDIC car une alerte de sécurité était déclenchée par le navigateur. Un message du type: « Site web certifié par une autorité inconnue. Impossible de vérifier l’identité www.assedic.fr comme un tiers de confiance » apparaissait.
En février 2007 est paru au Journal officiel le certificat racine de l'administration Française. L’Etat n'a plus besoin de faire appel à des organismes privés pour obtenir un certificat subordonné (et payant !) La diffusion de ce certificat racine dans tous les navigateurs est maintenant gage d'indépendance.
Pour afficher le certificat racine de l'Etat Français dans Mozilla Firefox :
Outils > Options > Avancées > Certificats > Afficher Les Certificats : chercher PM/SGDN
IGC/A : Infrastructure de Gestion de la Confiance de l’Administration.
PM/SGDN : Premier Ministre / Secrétariat Général de la Défense Nationale
Connexion Internet en HTTPS (protocoles SSL et TLS)
Lors d’une connexion Internet sécurisée, l’adresse du site web commence par https (pour secure http). Un cadenas apparaît à côté de l’adresse. L’échange https utilise les protocoles SSL (Secure Sockets Layer) et son successeur TLS (Transport Layer Security). Ces protocoles utilisent l’authentification par certificats électroniques.
Lorsqu'un client se connecte à un site web qui utilise SSL/TLS, les étapes suivantes ont lieu :
1) le serveur envoie au client son certificat électronique (clé publique + signature numérique).
2) le navigateur du client déchiffre la signature numérique du certificat en utilisant les clés publiques contenues dans les certificats racines intégrés au navigateur.
a) si l'un d'entre eux fonctionne, le navigateur web en déduit le nom de l'autorité de certification qui a signé le certificat envoyé par le serveur. Il vérifie que celui-ci n'est pas expiré puis envoie une demande OCSP à cette autorité pour vérifier que le certificat du serveur n'a pas été révoqué.
b) si aucun d'entre eux ne fonctionne, le navigateur web tente de déchiffrer la signature numérique du certificat du serveur à l'aide de la clé publique contenue dans celui-ci. En cas de réussite, cela signifie que le serveur web a lui-même signé son certificat. Un message d'avertissement s'affiche alors sur le navigateur web, prévenant l'utilisateur que l'identité du serveur n'a pas été vérifiée par une autorité de certification et qu'il peut donc s'agir potentiellement d'un site frauduleux.
c) en cas d'échec, le certificat est invalide, la connexion ne peut pas aboutir.
3) le navigateur du client génère une clé de chiffrement symétrique, appelée clé de session, qu'il chiffre à l'aide de la clé publique contenue dans le certificat du serveur, puis envoie ce message chiffré au serveur.
4) le serveur déchiffre la clé de session envoyée par le client grâce à sa propre clé privée.
5) le client et le serveur échangent dorénavant les données uniquement à l'aide de la clé de session, en chiffrement symétrique. La connexion TLS est établie.
6) Une fois la connexion terminée (déconnexion volontaire de l'utilisateur ou durée d’inactivité trop élevée), le serveur révoque la clé de session.
Différences entre SSL et TLS.
En 1995, SSL sort dans sa version SSL 2.0. La découverte de plusieurs vulnérabilités amène à faire évoluer SSL. En 1999, TLS est introduit comme la nouvelle version de SSL. Les différences entre SSL et TLS ne sont pas énormes, mais suffisamment importantes pour empêcher l'interopérabilité entre les deux. Compte tenu des failles de SSL, il faut le désactiver et utiliser uniquement TLS.
Remarque : les certificats ne sont pas dépendants des protocoles. En clair, il n’existe pas de certificat lié à TLS ou lié à SSL. Les protocoles sont déterminés par la configuration serveur, pas par les certificats en tant que tels.
Dans son édition du 6 septembre 2013, le journal le Guardian affirmait que la NSA (Agence de Sécurité Américaine) était capable de déchiffrer la plupart des données chiffrées circulant sur Internet. De nombreuses sources ont cependant indiqué que la NSA n'avait pas mathématiquement cassé les chiffrements mais s'appuierait sur des faiblesses d'implémentation des protocoles de sécurité (SSL et TLS). Ces protocoles sont donc en constante évolution pour éliminer ces failles de sécurité.
Faille de sécurité dans le protocole TLS.
Dans le cas général d’utilisation de TLS, seul le serveur web est authentifié par le client, mais le client n’est pas authentifié par le serveur web. En d’autres termes, l’authentification est unilatérale et pas mutuelle. En conséquence, la sécurité de l’échange ne se fait pas de bout en bout (entre client et serveur web). Cette faille peut être exploitée par un proxy SSL (cf plus bas). Les communications https peuvent alors être lues en clair par le proxy SSL sans qu’une alerte de sécurité ne soit déclenchée chez le client !
Seule solution pour résoudre cette faille : utiliser une option du protocole TLS appelée mTLS (authentification mutuelle par TLS). Mais pour que le serveur authentifie le client, il faut que ce dernier possède son propre certificat électronique, et que ce dernier soit tenu à jour. Cela implique un travail lourd côté client, et qui est rarement mis en œuvre.
Cas des applis
Dans le cas d’une appli pour consulter ses comptes bancaires, par exemple, c’est la banque qui a fabriqué l’appli. Elle y a donc intégré sa clé publique. Lors de la connexion de l’appli sur internet, l’appli authentifie le serveur de la banque grâce à la clé de la banque. Un proxy SSL serait donc sans effet dans ce cas.
Le problème d’un navigateur internet est qu’il intègre de nombreux certificats racines, et que chaque certificat racine peut autoriser n’importe quel site internet.
Solidité des algorithmes de cryptage, et masque jetable
Tout algorithme de cryptage peut être attaqué par la force brute. Il s'agit de tester, une à une, toutes les combinaisons possibles. Elle permet de casser un mot de passe en un temps fini, mais le temps augmente avec la longueur du mot de passe. Même si en théorie et avec suffisamment de temps, l'attaquant peut toujours trouver le mot de passe, lorsque ce temps dépasse la décennie il ne pourra pas en escompter un grand profit, et le mot de passe aura de toute façon changé.
Il n’en va pas de même pour les algorithmes qui garantissent une sécurité inconditionnelle cad qui sont mathématiquement incassables. Actuellement, une seule technique est inconditionnellement sûre : le masque jetable. Sa particularité est qu’elle ne repose pas sur la difficulté du calcul, comme pour les autres systèmes de chiffrement. Au contraire, elle est très simple à mettre en œuvre. Un chiffrement à la main par la méthode du masque jetable fut notamment utilisé par Che Guevara pour communiquer avec Fidel Castro.
Principe du masque jetable :
La clé doit avoir la même taille que le message à crypter. Pour chiffrer le mot HELLO, il faut donc une clé de 5 caractères. Prenons par exemple WMCKL. Cette clé est choisie à l'avance entre les deux personnes souhaitant communiquer, et n'est connue que d'eux.
Pour crypter HELLO, on attribue un nombre à chaque lettre, par exemple le rang dans l'alphabet, de 0 à 25. Ensuite on additionne la valeur de chaque lettre avec la valeur correspondante dans le masque ; enfin si le résultat est supérieur à 25 on soustrait 26 (calcul dit « modulo 26 ») :
7 (H) 4 (E) 11 (L) 11 (L) 14 (O) message
+ 22 (W) 12 (M) 2 (C) 10 (K) 11 (L) masque
= 29 16 13 21 25 masque + message
= 3 (D) 16 (Q) 13 (N) 21 (V) 25 (Z) masque + message modulo 26
Le texte reçu par le destinataire est « DQNVZ ».
Le déchiffrement s'effectue de manière similaire, sauf que l'on soustrait le masque au texte chiffré au lieu de l'additionner. Ici encore on ajoute éventuellement 26 au résultat pour obtenir des nombres compris entre 0 et 25 :
3 (D) 16 (Q) 13 (N) 21 (V) 25 (Z) message chiffré
- 22 (W) 12 (M) 2 (C) 10 (K) 11 (L) masque
= -19 4 11 11 14 message chiffré - masque
= 7 (H) 4 (E) 11 (L) 11 (L) 14 (O) message chiffré - masque modulo 26
On retrouve bien le message initial « HELLO ».
L'exemple donné ici utilise un alphabet de 26 caractères et des décalages modulo 26. Mais d'autres décalages peuvent être utilisés. Che Guevara utilisait, en plus des 26 caractères de l'alphabet, quelques signes de ponctuation, et les codait préalablement par des nombres de un ou deux chiffres en base 10 ; il utilisait alors un décalage modulo 10 chiffre par chiffre à partir de la clef jetable, qui était elle-même une suite de chiffres.
Chaque clé, ou « masque », ne doit être utilisée qu'une seule fois (d'où le nom de masque jetable).
Le gros inconvénient du masque jetable est son impossibilité de mise en œuvre dans de nombreux cas, comme la sécurisation des échanges sur Internet. En effet, l’échange de la clé entre les correspondants nécessite au préalable un canal parfaitement sûr. Le masque jetable n’a donc d'intérêt que si ce canal existe au moment de l'échange des clés, et n’existe plus au moment de l'échange des messages (sinon autant utiliser directement le canal en question pour les messages).
Che Guevara et Fidel Castro ont dû se voir pour échanger de façon confidentielle une clé commune très longue. Après leur séparation, ils ont utilisé cette clé pour chiffrer/déchiffrer leurs messages qu’ils se sont échangés par des canaux non sécurisés. Cet échange a pu se poursuivre tant que la clé n’était pas épuisée (d’où l’intérêt d’une longue clé au départ).
Cas de la fonction de hachage MD5 :
La fonction de hachage MD5, créée en 1991, a été cassée en 2004. En effet, une équipe chinoise découvre des collisions complètes cad deux messages différents qui produisent la même empreinte. MD5 n'est donc plus considéré comme sûr au sens cryptographique. On utilise maintenant des algorithmes tels que SHA-256 pour la signature électronique des certificats.
Cependant l’utilisation de MD5 pour la « signature » d'un fichier reste plutôt fiable. En effet, le système de cassage de MD5 concerne des collisions quelconques et ne permet pas de réaliser une collision sur une empreinte spécifique, c'est-à-dire réaliser un deuxième message à partir de l'empreinte d'un premier message, qui produirait la même empreinte.
En d’autres termes, s’il est possible de modifier un fichier pour qu’il corresponde à la même empreinte que le fichier original, le fichier modifié ne fonctionnera pas, et l’utilisateur s’en rendra compte. MD5 reste donc couramment utilisé pour vérifier l’intégrité des fichiers circulant sur internet.
Surveillance Internet crypté grâce à un proxy SSL : légal !
Un arrêt de la Cour européenne des droits de l’homme de 2007 autorise la surveillance des flux web des salariés par l’employeur. L’employeur peut déchiffrer les flux https (SSL/TLS) par une méthode simple : le proxy SSL.
Principe du proxy SSL
Tout le trafic web de l’entreprise doit passer par un unique ordinateur appelé proxy :
Le proxy « dupe » alors le client en interceptant la connexion TLS qu’il initie en direction du serveur web cible. Le proxy doit pour cela intégrer un serveur TLS pour pouvoir être le point de terminaison des sessions HTTPS. Le proxy joue ensuite le rôle de client vis-à-vis du serveur cible avec lequel il établit un autre tunnel TLS pour sécuriser les échanges qui transitent sur Internet. Ce double rôle permet ainsi au proxy de disposer du trafic http non chiffré entre les deux tunnels TLS établis.
Cette structure met en jeu deux connexions TLS indépendantes :
- client <> Proxy : l’authentification TLS ne peut se faire que si le proxy présente un certificat valide au client. Comme les ordinateurs de l’entreprise sont gérés par l’administrateur réseau, qui gère aussi le proxy, il est facile d’intégrer à chaque navigateur web des ordinateurs de l’entreprise un certificat local, qui n’a de valeur qu’au sein de l’entreprise. Un certificat local est à usage strictement interne, et n’est rattaché à aucune autorité de certification. Lorsque le client TLS réclame le certificat du serveur web, le proxy lui envoie le certificat local au lieu du « vrai » certificat. Le navigateur qui possède le certificat local racine est berné et valide l’authentification.
- Proxy <> serveur web : le proxy réclame ensuite le « vrai » certificat au serveur web, et s’authentifie en tant que client. Il fait ensuite l’interface entre le client de l’entreprise (via le certificat local) et le serveur web (via le « vrai » certificat).
Résultat : l’ensemble du flux (mots de passe, mails confidentiels, numéros de carte bancaire…) passe en clair dans le proxy et peut être stocké sur un serveur de l’entreprise. La dissimulation est (presque) parfaite au niveau du navigateur web du client.
Détection de la supercherie par le client
La communication https avec le proxy étant authentifiée par un certificat local de l’entreprise, il suffit d’afficher et de vérifier le certificat :
Cliquer sur le cadenas à côté de l’URL du site web > flèche droite > Plus d’Informations > Sécurité > Afficher Le Certificat : puis onglet Détails. La hiérarchie des certificats est alors affichée.
Si le certificat racine présente une entité inconnue (rechercher sur Google) alors il s’agit d’un certificat local : le trafic https est donc espionné. Si le certificat racine est une entité connue et officielle, alors le trafic https n’est pas espionné.
Sécurisation des échanges malgré surveillance par proxy SSL
Méthode 1
La surveillance par proxy SSL est possible car dans le protocole TLS l’authentification est unilatérale et pas mutuelle. En effet, seul le serveur web est authentifié par le client, mais le client n’est pas authentifié par le serveur web (cf « faille de sécurité dans le protocole TLS » ci-dessus)
En cas d’authentification mutuelle (mTLS), le proxy ne pourra substituer le certificat local au « vrai » certificat. Mais dans ce cas, le proxy peut empêcher la connexion et bloquer l’accès au serveur web, ce qui rend caduque cette méhode.
Méthode 2
Comme la surveillance par proxy SSL est possible seulement si l’ordinateur du client intègre le certificat local de l’entreprise, il suffit d’utiliser un ordinateur qui ne possède pas ce certificat. Par exemple, un employé peut se connecter avec son propre ordinateur portable. Mais cela suppose que l’ordinateur a été déclaré auprès de l’administrateur réseau afin de pouvoir se connecter. Il suffit que le proxy refuse les connexions d’ordinateurs non déclarés pour rendre caduque cette méthode.
Faux certificat validé par une autorité officielle : illégal !
Scandale en 2013 : Google avait mis la main sur un faux certificat de chiffrement SSL, émis et utilisé par le Ministère des Finances pour chiffrer les échanges entre les utilisateurs internes et son proxy SSL.
En d’autres termes, le Ministère des Finances pouvait créer de faux certificats pour n’importe quel site, sans que les utilisateurs s’en rendent compte facilement. En effet, il aurait fallu que les utilisateurs affichent la hiérarchie des certificats et vérifient le certificat racine. Ils se seraient rendus compte qu’il s’agissait à chaque fois du certificat racine de l’Etat Français, pour tous les sites web visités (étrange pour une connexion à Google par exemple !)
Et comme tous les navigateurs intègrent le certificat racine de l’Etat Français, un ordinateur tiers introduit sur le réseau aurait été berné aussi (cf méthode 2 de sécurisation des échanges malgré surveillance par proxy SSL, ci-dessus)
Cette utilisation d’un certificat racine officiel au lieu d’un certificat local est totalement illégale !
Google a immédiatement sonné l’alarme, en épinglant non pas le Ministère des Finances, mais l’ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) qui gère l’utilisation du certificat racine de l’Etat Français. L’ANSSI a réagi au quart de tour, en révoquant les faux certificats et en publiant un communiqué qui fait référence à une « erreur humaine » dans l’utilisation des certificats.
Limites de TLS
La liste des certificats racines intégrés à Mozilla Firefox fait apparaître un grand nombre de certificats gérés par les Etats :
On peut imaginer qu’un Etat souhaitant inspecter le trafic web de ses concitoyens mette en place un proxy SSL à l’échelle du pays. Dans ce cas, le trafic https sera espionné.
Seule l’authentification de bout en bout permettrait de s’en affranchir, à supposer que le proxy SSL laisse passer les échanges qu’il ne peut pas surveiller.
Conclusions
- les systèmes de cryptages sont fiables en tant que tels et jusqu’à preuve du contraire,
- mais leur application via le protocole crypté HTTPS présente au moins 2 faiblesses :
1) l’utilisation d’un proxy SSL qui déchiffre le trafic, à cause de l’authentification unilatérale de TLS et des certificats locaux (l’utilisateur doit en avoir conscience lors de l’utilisation d’un réseau d’entreprise),
2) la capacité pour un certificat racine de créer des certificats subordonnés pour n’importe quel site web (l’utilisateur doit donc faire confiance à l’ensemble des certificats racine présents sur son ordinateur).
Dans tous les cas, l’utilisateur peut vérifier la hiérarchie des certificats en cliquant sur le cadenas du navigateur. Il est libre de ne pas poursuivre la connexion s’il a le moindre doute sur le certificat racine qui valide la connexion https.