PKI, TLS et HTTPS

1. Infrastructure à clé publique

1.1. Définition

Une infrastructure à clés publiques (ICP) ou infrastructure de gestion de clés (IGC) ou encore Public Key Infrastructure (PKI), est un ensemble de composants physiques (des ordinateurs, des équipements cryptographiques logiciels ou matériel type HSM ou encore des cartes à puces), de procédures humaines (vérifications, validation) et de logiciels (système et application) en vue de gérer le cycle de vie des certificats numériques ou certificats électroniques.

Une infrastructure à clés publiques fournit des garanties permettant de faire a priori confiance à un certificat signé par une autorité de certification grâce à un ensemble de services.

Ces services sont les suivants :

enregistrement des utilisateurs (ou équipement informatique) ;
génération de certificats ;
renouvellement de certificats ;
révocation de certificats ;
publication de certificats ;
publication des listes de révocation (comprenant la liste des certificats révoqués) ;
identification et authentification des utilisateurs (administrateurs ou utilisateurs qui accèdent à l’ICP) ;
archivage, séquestre et recouvrement des certificats (option).

1.2. Rôle d’une infrastructure à clés publiques

Une infrastructure à clés publiques (ICP) délivre des certificats numériques. Ces certificats permettent d’effectuer des opérations cryptographiques, comme le chiffrement et la signature numérique qui offrent les garanties suivantes lors des transactions électroniques :

confidentialité : elle garantit que seul le destinataire (ou le possesseur) légitime d’un bloc de données ou d’un message peut en avoir une vision intelligible ;
authentification : elle garantit à tout destinataire d’un bloc de données ou d’un message ou à tout système auquel tente de se connecter un utilisateur l’identité de l’expéditeur ou de l’utilisateur en question ;
intégrité : elle garantit qu’un bloc de données ou qu’un message n’a pas été altéré, accidentellement ou intentionnellement ;
non-répudiation : elle garantit à quiconque que l’auteur d’un bloc de données ou d’un message ne peut renier son œuvre, c’est-à-dire prétendre ne pas en être l’auteur.

Les ICP permettent l’obtention de ces garanties par l’application de processus de vérification d’identité rigoureux et par la mise en œuvre de solutions cryptographiques fiables (éventuellement évaluées), conditions indispensables à la production et à la gestion des certificats électroniques.

1.3. Composants de l’infrastructure à clés publiques

L’IETF distingue 4 catégories d’ICP :

l’autorité de certification (AC ou CA) qui signe les demandes de certificat (CSR : Certificate Signing Request) et les listes de révocation (CRL : Certificate Revocation List). Cette autorité est la plus critique ;
l’autorité d’enregistrement (AE ou RA) qui effectue les vérifications d’usage sur l’identité de l’utilisateur final (les certificats numériques sont nominatifs et uniques pour l’ensemble de l’ICP) ;
l’autorité de dépôt (Repository) qui stocke les certificats numériques ainsi que les listes de révocation (CRL) ;
l’entité finale (EE : End Entity) qui utilise le certificat (en général, le terme « entité d’extrémité » (EE) est préféré au terme « sujet » afin d’éviter la confusion avec le champ Subject).

En complément, on pourra ajouter une cinquième catégorie, non définie par l’IETF :

l’autorité de séquestre (Key Escrow) qui stocke de façon sécurisée les clés de chiffrement créées par les autorités d’enregistrement, pour pouvoir, le cas échéant, les restaurer. Les raisons à cela en sont multiples. La perte de la clef privée par son détenteur ne doit pas être définitive. Toute organisation doit être en mesure de déchiffrer les documents de travail d’un de ses membres si, par exemple, celui-ci n’en fait plus partie. Enfin, dans certains pays, en France en particulier, la loi exige que les données chiffrées puissent être déchiffrées à la demande des autorités nationales. La mise en œuvre d’un séquestre répond à cette exigence.

1.4. Les certificats numériques : Familles

Usuellement, on distingue deux familles de certificats numériques :

les certificats de signature, utilisés pour signer des documents ou s’authentifier sur un site web, et
les certificats de chiffrement (les gens qui vous envoient des courriels utilisent la partie publique de votre certificat pour chiffrer le contenu que vous serez seul à pouvoir déchiffrer)

Mais cette typologie n’est pas exhaustive ; un découpage plus orienté applicatif pourrait être envisagé. L’intérêt de la séparation des usages découle notamment des problématiques de séquestre de clés et de recouvrement. En effet, lorsqu’il y a chiffrement, il peut y avoir nécessité de recouvrer les informations chiffrées. Alors que lorsqu’il y a signature, il est indispensable de s’assurer que la clé privée n’est possédée que par une seule partie.

1.5. Nature et composition

Un certificat électronique est une donnée publique. Suivant la technique des clés asymétriques, à chaque certificat électronique correspond une clé privée, qui doit être soigneusement protégée.

Un certificat numérique porte les caractéristiques de son titulaire : si le porteur est un être humain, cela peut être son nom et son prénom, le nom de sa structure (par exemple, son entreprise ou son… État !) et de son entité d’appartenance. Si c’est un équipement informatique (comme une passerelle d’accès ou un serveur d’application sécurisé), le nom est remplacé par l’URI du service. À ces informations d’identification s’ajoute la partie publique du bi-clé.

L’ensemble de ces informations (comprenant la clé publique) est signé par l’autorité de certification de l’organisation émettrice. Cette autorité a la charge de :

s’assurer que les informations portées par le certificat numérique sont correctes ;
s’assurer qu’il n’existe, pour une personne et pour une même fonction, qu’un et un seul certificat valide à un moment donné.

Le certificat numérique est donc, à l’échelle d’une organisation, un outil pour témoigner, de façon électroniquement sûre, d’une identité.

L’usage conjoint des clés cryptographiques publiques (contenue dans le certificat) et privée (protégée par l’utilisateur, par exemple au sein d’une carte à puce), permet de disposer de fonctions de sécurité importante (cf. infra).

1.6. Gestion

Un certificat numérique naît après qu’une demande de certificat a abouti.

Une demande de certificat est un fichier numérique (appelé soit par son format, PKCS#10, soit par son équivalent fonctionnel, CSR pour Certificate Signing Request) qui est soumis à une autorité d’enregistrement par un utilisateur final ou par un administrateur pour le compte d’un utilisateur final.

Cette demande de certificat est examinée par un Opérateur d’Autorité d’Enregistrement. Cette position est une responsabilité clé : c’est lui qui doit juger de la légitimité de la demande de l’utilisateur et accorder, ou non, la confiance de l’organisation. Pour se forger une opinion, l’Opérateur doit suivre une série de procédures, plus ou moins complètes, consignées dans deux documents de référence qui vont de pair avec la création d’une ICP qui sont la Politique de Certification (PC) et la Déclaration des Pratiques de Certification (DPC). Ces documents peuvent exiger, en fonction des enjeux de la certification, des vérifications plus ou moins poussées : rencontre en face-à-face, validation hiérarchique, etc. L’objectif de l’Opérateur d’AE est d’assurer que les informations fournies par l’utilisateur sont exactes et que ce dernier est bien autorisé à solliciter la création d’un certificat.

Une fois son opinion formée, l’Opérateur de l’AE valide la demande ou la rejette. S’il la valide, la demande de certificat est alors adressée à l’Autorité de Certification (AC). L’AC vérifie que la demande a bien été validée par un Opérateur d’AE digne de confiance et, si c’est le cas, signe la CSR. Une fois signée, une CSR devient… un certificat.

Le certificat, qui ne contient aucune information confidentielle, peut par exemple être publié dans un annuaire d’entreprise : c’est la tâche du Module de Publication, souvent proche de l’AC.

1.7. Modes de création

Il existe deux façons distinctes de créer des certificats électroniques : le mode centralisé et le mode décentralisé.

le mode décentralisé est le mode le plus courant : il consiste à faire créer, par l’utilisateur (ou, plus exactement par son logiciel ou carte à puce) le biclé cryptographique et de joindre la partie publique de la clef dans la CSR. L’Infrastructure n’a donc jamais connaissance de la clé privée de l’utilisateur, qui reste confinée sur son poste de travail ou dans sa carte à puce.

le mode centralisé consiste en la création du biclé par l’AC : au début du cycle de la demande, la CSR ne contient pas la clé publique, c’est l’AC qui la produit. Elle peut ainsi avoir de bonnes garanties sur la qualité de la clé (aléa) et peut… en détenir une copie protégée. En revanche, il faut transmettre à l’utilisateur certes son certificat (qui ne contient que des données publiques) mais aussi sa clé privée ! L’ensemble de ces deux données est un fichier créé sous le format PKCS#12. Son acheminement vers l’utilisateur doit être entrepris avec beaucoup de précaution et de sécurité, car toute personne mettant la main sur un fichier PKCS#12 peut détenir la clé de l’utilisateur.

Le mode décentralisé est préconisé pour les certificats d’authentification (pour des questions de coût, parce qu’il est plus simple de refaire un certificat en décentralisé qu’à recouvrer une clé) et de signature (parce que les conditions d’exercice d’une signature juridiquement valide prévoit que le signataire doit être le seul possesseur de la clé : en mode décentralisé, l’ICP n’a jamais accès à la clé privée).

Le mode centralisé est préconisé pour les certificats de chiffrement, car, lorsqu’un utilisateur a perdu sa clé (par exemple, sa carte est perdue ou dysfonctionne), un opérateur peut, au terme d’une procédure de recouvrement, récupérer la clé de chiffrement et la lui remettre. Chose qui est impossible à faire avec des clés qui n’ont pas été séquestrées.

1.8. Scénario de fin de vie

Il existe deux scénarios possibles de fin de vie d’un certificat numérique :

le certificat numérique expire (chaque certificat numérique contient une date de « naissance » et une date de « péremption »).
le certificat est révoqué, pour quelque raison que ce soit (perte de la clé privée associée, etc.) et dans ce cas, l’identifiant du certificat numérique est ajouté à une liste de certificats révoqués (CRL pour Certificate Revocation List) pour informer les applications qu’elles ne doivent plus faire confiance à ce certificat. Il est aussi possible que les applications s’informent en quasi temps réel de l’état du certificat avec le protocole OCSP.

1.9. Autorité de certification

En cryptographie, une Autorité de Certification (AC ou CA pour Certificate Authority en anglais) est un tiers de confiance permettant d’authentifier l’identité des correspondants. Une autorité de certification délivre des certificats décrivant des identités numériques et met à disposition les moyens de vérifier la validité des certificats qu’elle a fourni.

Les services des autorités de certification sont principalement utilisés dans le cadre de la sécurisation des communications numériques via protocole Transport Layer Security (TLS) utilisé par exemple pour sécuriser les communications web (HTTPS) ou email (SMTP, POP3, IMAP… sur TLS), ainsi que pour la sécurisation des documents numériques (par exemple au moyen de signatures électroniques avancées telles que PAdES pour des documents PDF, ou via le protocole S/MIME pour les emails).

1.10. Utilisation dans le domaine des communications web

Les navigateurs web modernes intègrent nativement une liste de certificats provenant de différentes Autorités de Certification choisies selon des règles internes définies par les développeurs du navigateur.

Lorsqu’une personne physique ou morale souhaite mettre en place un serveur web utilisant une communication HTTPS sécurisée par TLS, elle génère une clé publique, une clé privée puis envoie à l’une de ces Autorité de Certification une demande de signature de certificat (en anglais CSR : Certificate Signing Request) contenant sa clé publique ainsi que des informations sur son identité (coordonnées postales, téléphoniques, email…).

Après vérification de l’identité du demandeur du certificat par une autorité d’enregistrement (RA), l’Autorité de Certification signe le CSR grâce à sa propre clé privée (et non pas avec la clé privée de la personne donc) qui devient alors un certificat puis le transmet en retour à la personne qui en a fait la demande.

Le certificat ainsi retourné sous forme de fichier informatique est intégré dans le serveur web du demandeur. Lorsqu’un utilisateur se connecte à ce serveur web, celui-ci lui transmet à son tour le certificat fourni précédemment par l’Autorité de Certification.

Le navigateur web du client authentifie le certificat du serveur grâce au certificat de l’Autorité de Certification (intégré nativement dans le navigateur, cf. ci-dessus) qui l’a signé précédemment. L’identité du serveur est ainsi confirmée à l’utilisateur par l’Autorité de Certification.

Le navigateur web contacte ensuite l’Autorité de Certification concernée pour savoir si le certificat du serveur n’a pas été révoqué (= invalidé) depuis qu’il a été émis par l’Autorité de Certification via une demande OCSP.

Auparavant, les navigateurs téléchargeaient régulièrement des listes de révocation (CRL : Certificate Revocation List) de la part des Autorités de Certification au lieu de contacter directement celles-ci par des demandes OCSP. Ce processus a été abandonné depuis car utilisant inutilement beaucoup de bande passante.

Sur le plan technique, cette infrastructure de gestion des clés permet ainsi d’assurer que :

les données transmises entre le serveur web et le client n’ont pas été modifiées durant le transfert : intégrité par hachage des données.
les données proviennent bien du serveur web connu et qu’il ne s’agit pas d’un serveur web tiers tentant d’usurper l’identité de celui-ci.
les données ne peuvent pas être interceptées par un tiers car elles sont chiffrées.

1.11. Fonctionnement interne

L’autorité de certification (AC) opère elle-même ou peut déléguer l’hébergement de la clé privée du certificat à un opérateur de certification (OC) ou autorité de dépôt. L’AC contrôle et audite l’opérateur de certification sur la base des procédures établies dans la Déclaration des Pratiques de Certification. L’AC est accréditée par une autorité de gestion de la politique qui lui permet d’utiliser un certificat renforcé utilisé par l’OC pour signer la clé publique selon le principe de la signature numérique.

2. Certificats électroniques

Un certificat électronique (aussi appelé certificat numérique ou certificat de clé publique) peut être vu comme une carte d’identité numérique. Il est utilisé principalement pour identifier et authentifier une personne physique ou morale, mais aussi pour chiffrer des échanges.

Il est signé par un tiers de confiance qui atteste du lien entre l’identité physique et l’entité numérique (virtuelle).

Le standard le plus utilisé pour la création des certificats numériques est le X.509.

2.1. Définition

Un certificat électronique est un ensemble de données contenant :

au moins une clé publique ;
des informations d’identification, par exemple : nom, localisation, adresse électronique ;
au moins une signature (clé privée) ; de fait quand il n’y en a qu’une, l’entité signataire est la seule autorité permettant de prêter confiance (ou non) à l’exactitude des informations du certificat.

Les certificats électroniques et leur cycle de vie (voir liste de révocation de certificats et protocole de vérification de certificat en ligne) peuvent être gérés au sein d’infrastructures à clés publiques.

2.2. Types

Les certificats électroniques respectent des standards spécifiant leur contenu de façon rigoureuse. Les deux formats les plus utilisés aujourd’hui sont :

X.509, défini dans la RFC 5280 ;
OpenPGP, défini dans la RFC 4880.

La différence notable entre ces deux formats est qu’un certificat X.509 ne peut contenir qu’un seul identifiant, que cet identifiant doit contenir de nombreux champs prédéfinis, et ne peut être signé que par une seule autorité de certification. Un certificat OpenPGP peut contenir plusieurs identifiants, lesquels autorisent une certaine souplesse sur leur contenu, et peuvent être signés par une multitude d’autres certificats OpenPGP, ce qui permet alors de construire des toiles de confiance.

2.3. Utilité

Les certificats électroniques sont utilisés dans différentes applications informatiques dans le cadre de la sécurité des systèmes d’information pour garantir :

la non-répudiation et l’intégrité des données avec la signature numérique ;
la confidentialité des données grâce au chiffrement des données ;
l’authentification ou l’authentification forte d’un individu ou d’une identité numérique.

2.4. Exemples d’utilisation

Serveur web (voir TLS et X.509) ;
Courrier électronique (voir OpenPGP) ;
Poste de travail (voir IEEE 802.1X) ;
Réseau privé virtuel (VPN, voir IPsec) ;
Secure Shell (SSH), TLS ;
Documents électroniques.

3. Transport Layer Security

Transport Layer Security (TLS), et son prédécesseur Secure Sockets Layer (SSL), sont des protocoles de sécurisation des échanges sur Internet. Le protocole SSL a été développé à l’origine par Netscape. L’IETF, en a poursuivi le développement en le rebaptisant Transport Layer Security (TLS). On parle parfois de SSL/TLS pour désigner indifféremment SSL ou TLS.

TLS (ou SSL) fonctionne suivant un mode client-serveur. Il permet de satisfaire aux objectifs de sécurité suivants :

l’authentification du serveur ;
la confidentialité des données échangées (ou session chiffrée) ;
l’intégrité des données échangées ;
de manière optionnelle, l’authentification du client (mais dans la réalité celle-ci est souvent assurée par le serveur).

Le protocole est très largement utilisé, sa mise en œuvre est facilitée par le fait que les protocoles de la couche application, comme HTTP, n’ont pas à être profondément modifiés pour utiliser une connexion sécurisée, mais seulement implémentés au-dessus de SSL/TLS, ce qui pour HTTP a donné le protocole HTTPS.

Un groupe de travail spécial de l’IETF a permis la création du TLS et de son équivalent en mode UDP, le DTLS. Depuis qu’il est repris par l’IETF, le protocole TLS a connu trois versions, TLS v1.0 en 1999, TLS v1.1 en 2006 et TLS v1.2 en 2008. Un premier brouillon de TLS v1.3 est sorti en 2014.

3.1. Présentation

Au fur et à mesure qu’Internet se développait, de plus en plus de sociétés commerciales se mirent à proposer des achats en ligne pour les particuliers. L’offre se mit à croître régulièrement, mais le chiffre d’affaires dégagé par le commerce électronique restait modeste tant que les clients n’avaient pas une confiance suffisante dans le paiement par carte bancaire. Une des façons de sécuriser ce paiement fut d’utiliser des protocoles d’authentification et de chiffrement tels que SSL. La session chiffrée est utilisée pour empêcher un tiers d’intercepter des données sensibles transitant par le réseau : numéro de carte lors d’un paiement par carte bancaire, mot de passe lorsque l’utilisateur s’identifie sur un site…

Avec un système SSL, la sécurité a été sensiblement améliorée et les risques pour le client grandement réduits, comparés à l’époque où le paiement par internet était encore une technologie émergente. Bien que, comme tout système de chiffrement, le SSL/TLS ne pourra jamais être totalement infaillible, le grand nombre de banques et de sites de commerce électronique l’utilisant pour protéger les transactions de leurs clients peut être considéré comme un gage de sa résistance aux attaques malveillantes.

En 2009, TLS est utilisé par la plupart des navigateurs Web. L’internaute peut reconnaître qu’une transaction est chiffrée à plusieurs signes :

l’URL dans la barre d’adresse commence par https et non http (https://…) ;
affichage d’une clé ou d’un cadenas, dont l’emplacement varie selon le navigateur : généralement à gauche de la barre d’adresse mais aussi dans la barre inférieure de la fenêtre ;
les navigateurs peuvent ajouter d’autres signes, comme le passage en jaune de la barre d’adresse (cas de Firefox).

Il existe quelques cas très spécifiques où la connexion peut être sécurisée par SSL sans que le navigateur n’affiche ce cadenas, notamment si le webmaster a inclus la partie sécurisée du code HTML au sein d’une page en http ordinaire, mais cela reste rare. Dans la très grande majorité des cas, l’absence de cadenas indique que les données ne sont pas protégées et seront transmises en clair.

3.2. Protocole SSL

La première version de SSL parue, la SSL 2.0, possédait un certain nombre de défauts de sécurité, parmi lesquels la possibilité de forcer l’utilisation d’algorithmes de chiffrement plus faibles, ou bien une absence de protection pour la prise de contact et la possibilité pour un attaquant d’exécuter des attaques par troncature1. Les protocoles PCT 1.0, puis SSL 3.0, furent développés pour résoudre la majeure partie de ces problèmes, le second devenant rapidement le protocole le plus populaire pour sécuriser les échanges sur Internet.

1994 : SSL 1.0. Cette première spécification du protocole développé par Netscape resta théorique et ne fut jamais mise en œuvre3.
Février 1995 : publication de la norme SSL 2.0, première version de SSL réellement utilisée. Elle fut également la première implémentation de SSL bannie, en mars 2011 (RFC 6176).
Novembre 1996 : SSL 3.0, la dernière version de SSL, qui inspirera son successeur TLS. Ses spécifications sont rééditées en août 2008 dans la RFC 61014. Le protocole est banni en 2014, à la suite de la publication de la faille POODLE, ce bannissement est définitivement ratifié en juin 2015 (RFC 7568).

3.3. Protocole TLS

Le protocole TLS n’est pas structurellement différent de la version 3 de SSL, mais des modifications dans l’utilisation des fonctions de hachage font que les deux protocoles ne sont pas directement interopérables. Cependant TLS, comme SSLv3, intègre un mécanisme de compatibilité ascendante avec les versions précédentes, c’est-à-dire qu’au début de la phase de négociation, le client et le serveur négocient la « meilleure » version du protocole disponible par tous deux. Pour des raisons de sécurité, détaillées dans la RFC 6176 parue en 2011, la compatibilité de TLS avec la version 2 de SSL est abandonnée5.

La génération des clés symétriques est un peu plus sécurisée dans TLS que dans SSLv3 dans la mesure où aucune étape de l’algorithme ne repose uniquement sur MD5 pour lequel sont apparues des faiblesses en cryptanalyse.

Janvier 1999 (RFC 2246) : Publication de la norme TLS 1.0. TLS est le protocole développé par l’IETF pour succéder au SSL. Plusieurs améliorations lui sont apportées par la suite :
Octobre 1999 (RFC 2712) : Ajout du protocole Kerberos à TLS ;
Mai 2000 (RFC 2817 et RFC 2818) : Passage à TLS lors d’une session HTTP 1.1 ;
Juin 2002 (RFC 3268) : Support du système de chiffrement AES par TLS.
Avril 2006 (RFC 4346) : Publication de la norme TLS 1.1.
Août 2008 (RFC 5246) : Publication de la norme TLS 1.2.
Mars 2011 (RFC 6176) : Abandon de la compatibilité avec SSLv2 pour toutes les versions de TLS.
Avril 2014 : 1er brouillon pour TLS 1.36.
Juin 2015 (RFC 7568) : Abandon de la compatibilité avec SSLv2 et SSLv3.
Août 2018 : publication de la norme TLS 1.3. Les principales évolutions sont l’abandon du support des algorithmes trop faibles comme MD4, RC4, DSA ou SHA-224, une négociation en moins d’étapes (plus rapide par rapport à TLS 1.2), et une réduction de la vulnérabilité aux attaques par replis.

3.4. Spécifications techniques

Dans la pile de protocole TCP/IP, TLS se situe entre la couche application (comme HTTP, FTP, SMTP, etc.) et la couche transport TCP.

Son utilisation la plus commune reste cependant en dessous de HTTP. Le protocole TLS est implémenté par la couche session de la pile, ce qui a deux conséquences :

pour toute application existante utilisant TCP, il peut exister une application utilisant TLS. Par exemple, l’application HTTPS correspond à HTTP au-dessus de TLS ;
une application TLS se voit attribuer un nouveau numéro de port par l’IANA. Par exemple HTTPS est associé au port 443. Dans certains cas, le même port est utilisé avec et sans TLS. Dans ce cas, la connexion est initiée en mode non chiffré. Le tunnel est ensuite mis en place au moyen du mécanisme StartTLS. C’est le cas, par exemple, des protocoles IMAP, SMTP ou LDAP.

La sécurité est réalisée d’une part par un chiffrement asymétrique, comme le chiffrement RSA, qui permet, après authentification de la clé publique du serveur, la constitution d’un secret partagé entre le client et le serveur, d’autre part par un chiffrement symétrique (beaucoup plus rapide que les chiffrements asymétriques), comme l’AES, qui est utilisé dans la phase d’échange de données, les clés de chiffrement symétrique étant calculées à partir du secret partagé. Une fonction de hachage, comme SHA-1, est également utilisée, entre autres, pour assurer l’intégrité et l’authentification des données (via par exemple HMAC).

4. HTTPS

4.1. Présententation de HTTPS

L’HyperText Transfer Protocol Secure (HTTPS, littéralement « protocole de transfert hypertexte sécurisé ») est la combinaison du HTTP avec une couche de chiffrement comme SSL ou TLS.

HTTPS permet au visiteur de vérifier l’identité du site web auquel il accède, grâce à un certificat d’authentification émis par une autorité tierce, réputée fiable (et faisant généralement partie de la liste blanche des navigateurs internet). Il garantit théoriquement la confidentialité et l’intégrité des données envoyées par l’utilisateur (notamment des informations entrées dans les formulaires) et reçues du serveur. Il peut permettre de valider l’identité du visiteur, si celui-ci utilise également un certificat d’authentification client.

HTTPS est généralement utilisé pour les transactions financières en ligne : commerce électronique, banque en ligne, courtage en ligne, etc. Il est aussi utilisé pour la consultation de données privées, comme les courriers électroniques, par exemple.

Depuis le début des années 2010, le HTTPS s’est également généralisé sur les réseaux sociaux.

Par défaut, les serveurs HTTPS sont connectés au port TCP 443.

En janvier 2017, Google Chrome et Mozilla Firefox ont commencé à identifier et signaler les sites Web qui recueillent des informations sensibles sans utiliser le protocole HTTPS. Ce changement a pour but d’augmenter de manière significative l’utilisation du HTTPS. En février 2017, le protocole de sécurité HTTPS était utilisé par environ 16,28 % de l’Internet français.

4.2. Description informelle du protocole

Le protocole est identique au protocole web habituel HTTP, mais avec un ingrédient supplémentaire dit TLS qui fonctionne assez simplement ainsi :

Le client — par exemple le navigateur Web — contacte un serveur — par exemple Wikipédia — et demande une connexion sécurisée, en lui présentant un certain nombre de méthodes de chiffrement de la connexion (des suites cryptographiques).
Le serveur répond en confirmant pouvoir dialoguer de manière sécurisée et en choisissant dans cette liste une méthode de chiffrement et surtout, en produisant un certificat garantissant qu’il est bien le serveur en question et pas un serveur pirate déguisé (on parle de l’homme du milieu). Ces certificats électroniques sont délivrés par une autorité tiers dans laquelle tout le monde a confiance, un peu comme un notaire dans la vie courante, et le client a pu vérifier auprès de cette autorité que le certificat est authentique (il y a d’autres variantes, mais c’est le principe général). Le certificat contient aussi un cadenas en quelque sorte (une clé dite publique) qui permet de prendre un message et de le mélanger avec ce cadenas pour le rendre complètement secret et uniquement déchiffrable par le serveur qui a émis ce cadenas (grâce à une clé dite privée, que seul le serveur détient, on parle de chiffrement asymétrique).
Cet échange permet au client d’envoyer de manière secrète un code (une clé symétrique) qui sera mélangé à tous les échanges entre le serveur et le client de façon que tous les contenus de la communication — y compris l’adresse même du site web, l’URL — soient chiffrées. Pour cela on mélange le contenu avec le code, ce qui donne un message indéchiffrable et à l’arrivée refaire la même opération avec ce message redonne le contenu en clair, comme dans un miroir.

En bref : serveur et client se sont reconnus, ont choisi une manière de chiffrer la communication et se sont passé de manière chiffrée un code pour dialoguer de manière secrète.

4.3. Principe de fonctionnement de TLS dans les navigateurs web

Lorsqu’un utilisateur se connecte à un site web qui utilise TLS, les étapes suivantes ont lieu :

le navigateur du client envoie au serveur une demande de mise en place de connexion sécurisée par TLS.
Le serveur envoie au client son certificat (voir l’article concerné pour plus de détails) : celui-ci contient sa clé publique, ses informations (nom de la société, adresse postale, pays, e-mail de contact…) ainsi qu’une signature numérique sous forme de texte chiffré.
Le navigateur du client tente de déchiffrer la signature numérique du certificat du serveur en utilisant les clés publiques contenues dans les certificats des autorités de certifications (AC) intégrés par défaut dans le navigateur.
1. Si l’une d’entre elles 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é.
2. Si aucune d’entre elles 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.
3. 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.
4. En cas d’échec, le certificat est invalide, la connexion ne peut pas aboutir.
Le navigateur du client génère une clé de chiffrement symétrique (à la différence des clés privés et publiques utilisés par les certificats qui sont asymétriques), appelée clé de session, qu’il chiffre à l’aide de la clé publique contenue dans le certificat du serveur puis transmet cette clé de session au serveur.
Le serveur déchiffre la clé de session envoyée par le client grâce à sa clé privée.
Le client et le serveur commencent à s’échanger des données en chiffrant celles-ci avec la clé de session qu’ils ont en commun. On considère à partir de ce moment que la connexion TLS est alors établie entre le client et le serveur.
Une fois la connexion terminée (déconnexion volontaire de l’utilisateur ou si durée d’inactivité trop élevée), le serveur révoque la clé de session.

Optionnel : si le serveur nécessite également que le client s’authentifie, le client lui envoie son propre certificat en même temps que la clé de session. Le serveur procède alors comme détaillé au point n°3 pour vérifier que le certificat du client est valide.

Source : Transport Layer Security et HyperText Transfer Protocol Secure

5. Letsencrypt

Source : Let’s Encrypt

Let’s Encrypt (abrégé LE) est une autorité de certification lancée le 3 décembre 2015 (Bêta Version Publique). Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS au moyen d’un processus automatisé destiné à se passer du processus complexe actuel impliquant la création manuelle, la validation, la signature, l’installation et le renouvellement des certificats pour la sécurisation des sites internet.

En septembre 2016, plus de 10 millions de certificats ont été délivrés. En février 2017, Let’s encrypt était utilisé par 13,70% du total des domaines français enregistrés. Le 30 août 2017, Let’s Encrypt dépasse les 50 millions de noms de domaine sécurisés selon PlanetHoster. En avril 2018, Let’s encrypt fournit 51,21 % des certificats TLS.

Le projet vise à généraliser l’usage de connexions sécurisées sur l’internet. En supprimant la nécessité de paiement, de la configuration du serveur web, des courriels de validation et de gestion de l’expiration des certificats, le projet est fait pour réduire de manière significative la complexité de la mise en place et de la maintenance du chiffrement TLS. Sur un serveur GNU/Linux, l’exécution de seulement deux commandes4 est censée être suffisante pour paramétrer le chiffrement HTTPS, l’acquisition et l’installation de certificats, et ceci en quelques dizaines de secondes.

Le protocole défi-réponse utilisé pour automatiser les inscriptions à cette nouvelle autorité de certification est appelé Automated Certificate Management Environment (ACME). Les processus de validation sont effectués à de multiples reprises sur des chemins réseaux séparés. La vérification des entrées DNS est réalisée de plusieurs points géographiques afin de rendre les attaques d’usurpation DNS plus difficiles à réaliser. Les interactions de l’ACME sont basées sur l’échange de documents JSON sur des connexions HTTPS. Une ébauche des spécifications est disponible sur GitHub, et une version a été soumise à l’Internet Engineering Task Force comme proposition pour un standard Internet.

Un logiciel de gestion de certificats en Python et sous licence Apache appelé “certbot” s’installe sur le client (le serveur web d’un inscrit). Ce programme réclame le certificat, effectue le processus de validation de domaine, installe le certificat, configure le chiffrement HTTPS dans le serveur HTTP et dans un second temps, renouvelle le certificat. Après l’installation, l’exécution d’une simple commande suffit à obtenir l’installation d’un certificat valide. Des options additionnelles, comme l’agrafage OCSP ou HTTP Strict Transport Security, peuvent également être activées. Le paramétrage automatique ne s’effectue initialement qu’avec Apache et Nginx.

On trouvera plus d’informations sur le site web officiel https://letsencrypt.org/

6. Pratique de TLS et des certificats

6.1. Récupérer, visualiser, transcoder un certificat

Visualiser un certificat :
```
# cat /etc/pki/tls/certs/localhost.crt
```

Mieux présenté avec openssl :

# openssl x509 -text -noout -in /etc/pki/tls/certs/localhost.crt
Certificate:
Data:
    Version: 3 (0x2)
    Serial Number: 28890 (0x70da)
Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=--, ST=SomeState, L=SomeCity, O=SomeOrganization, OU=SomeOrganizationalUnit, CN=localhost.localdomain/emailAddress=root@localhost.localdomain
    Validity
        Not Before: Sep 26 13:57:53 2016 GMT
        Not After : Sep 26 13:57:53 2017 GMT
    Subject: C=--, ST=SomeState, L=SomeCity, O=SomeOrganization, OU=SomeOrganizationalUnit, CN=localhost.localdomain/emailAddress=root@localhost.localdomain
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:9d:fd:05:7b:39:c2:75:62:ac:41:9b:96:5d:af:
                94:2e:80:d2:50:99:1a:9e:ad:6c:2b:ce:1a:6f:e5:
                4c:2e:51:f2:13:13:b5:05:2f:f6:ac:42:97:96:a2:
                52:3e:55:8b:70:fa:bb:af:93:7a:f7:a3:8f:a4:2e:
                6e:cc:eb:53:1d:81:ed:58:8d:69:c1:6e:0e:e9:22:
                89:46:55:e8:8a:fc:46:1a:c3:28:f3:38:c5:e4:8a:
                4b:83:9a:96:79:e7:e4:53:4f:75:d9:5b:47:4f:5e:
                88:e9:7a:a6:30:ef:a4:e0:ed:8e:02:6d:70:79:ea:
                17:84:dc:41:75:7e:95:94:9f:dd:2b:fc:1b:15:a0:
                5d:71:b1:5f:29:51:4a:0c:d4:0b:2e:8b:f8:4c:d8:
                40:d1:b4:f9:1c:e7:18:d4:43:49:6b:81:f0:87:73:
                b6:1c:a5:95:52:65:f8:72:33:1f:ad:3f:07:8f:7c:
                44:3c:3d:64:e4:3f:7c:ea:79:db:a4:d7:ef:64:1f:
                84:d6:81:cc:cc:1c:87:da:61:33:96:41:4b:7a:02:
                84:a3:f0:ee:82:e0:93:e3:d5:fd:26:45:bc:f0:a1:
                24:fc:d3:74:1e:8e:96:60:f7:4d:77:92:ca:a1:5a:
                dc:26:6c:52:d9:d7:ea:3b:30:bc:67:36:1f:24:83:
                6a:df
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Basic Constraints:
            CA:FALSE
        X509v3 Key Usage:
            Digital Signature, Non Repudiation, Key Encipherment
Signature Algorithm: sha256WithRSAEncryption
     0c:06:72:8d:6d:29:ae:a5:5b:bf:8d:57:6e:7b:ff:82:98:ad:
     30:39:5f:6c:dc:cb:58:84:cc:ca:bc:cb:01:db:6f:e0:05:98:
     50:e0:88:8a:69:e7:7e:75:26:89:60:a8:ec:c7:b6:62:ef:b0:
     7e:9a:93:72:f6:89:d9:ef:f5:e8:33:a0:d2:92:b0:9a:95:5c:
     ee:21:83:d6:5f:88:df:89:b4:9d:3b:27:02:5d:b4:34:b8:00:
     e0:75:32:1e:77:71:3d:0b:62:82:43:a5:8a:71:30:9c:f2:56:
     e1:69:6f:25:a6:84:7b:b8:57:0a:f7:14:a1:f4:aa:0d:39:0e:
     4b:7d:5b:c9:06:d5:70:04:a4:bd:9e:e2:ca:46:80:90:36:e2:
     f0:12:f1:b5:0f:b5:da:21:d8:31:f3:c1:27:d3:47:b2:df:7b:
     9e:7c:86:2a:d2:25:57:83:70:5b:c0:c4:63:48:d8:56:f9:53:
     90:d9:7d:b0:a7:9e:38:0e:41:c9:c4:16:a5:55:5a:c3:1c:3c:
     7b:4d:51:2d:bb:a5:e0:af:96:6d:95:3d:d4:21:0f:5a:48:2c:
     83:92:a5:64:1e:57:65:8a:45:cf:5d:f2:d2:d0:d1:2d:6a:7c:
     18:df:ff:b2:bf:8f:f4:fe:78:10:b1:f4:82:31:19:96:b8:bd:
     11:b1:99:b2

Récupérer un certicat X509 en ligne

# openssl s_client -showcerts -connect www.linux.com:443
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign CloudSSL CA - SHA256 - G3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Fastly, Inc.", CN = n.ssl.fastly.net
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=San Francisco/O=Fastly, Inc./CN=n.ssl.fastly.net
i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3
-----BEGIN CERTIFICATE-----
MIIOdjCCDV6gAwIBAgIMDvskHGiB0MJcky5oMA0GCSqGSIb3DQEBCwUAMFcxCzAJ
...
hLx9Lj/Y6X4/9l5lxjSFf5y+M9WHVWAR3VQ1dpTkkXfarj1eIRxZS2LsvBJjgw8b
XgwBVqdmBNkD0g==
-----END CERTIFICATE-----
1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3
i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
-----BEGIN CERTIFICATE-----
MIIEizCCA3OgAwIBAgIORvCM288sVGbvMwHdXzQwDQYJKoZIhvcNAQELBQAwVzEL
...
HY7EDGiWtkdREPd76xUJZPX58GMWLT3fI0I6k2PMq69PVwbH/hRVYs4nERnh9ELt
IjBrNRpKBYCkZd/My2/Q
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=San Francisco/O=Fastly, Inc./CN=n.ssl.fastly.net
issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 5535 bytes and written 373 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1.2
Cipher    : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 639EF6139293984B77BA686502009FA32EE55CA40892D3772ECE1559DE411BA6
Session-ID-ctx:
Master-Key: 69CDFB6E8807850C181CE54D66676762FE1B6E5F8FE79B2D8E9CB6782EF6E5BA4A58835BC5BE3FFCC7EC11EABEB48EFD
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 1200 (seconds)
TLS session ticket:
0000 - 63 cc 77 4a 00 db 2c 42-2e 8f 76 23 dd a9 ae 53   c.wJ..,B..v#...S
0010 - eb f3 5b 75 31 9c 7e dd-34 0e 27 9e c5 87 6f 3e   ..[u1.~.4.'...o>
0020 - fb fd 08 7f 4c 97 d1 e6-88 67 32 e6 95 9e 70 ee   ....L....g2...p.
0030 - 1c 8f f2 1a 98 b6 5e 20-3d b9 14 c3 c0 61 36 5b   ......^ =....a6[
0040 - a6 05 43 fa bc 4c b3 58-8f a4 10 76 18 a0 11 12   ..C..L.X...v....
0050 - 1b be 0d 04 48 85 a1 44-ea fb ad a0 3d 13 85 51   ....H..D....=..Q
0060 - 1a fb f6 95 a1 1e 06 c2-e2 c7 ba 8b de 52 9e 1d   .............R..
0070 - 64 56 db 5a c8 0b 82 43-84 6d a0 2f 0a ef 8e ef   dV.Z...C.m./....
0080 - 73 64 b9 c7 c3 37 d0 ce-62 d5 44 0d fd cc 2f b4   sd...7..b.D.../.
0090 - ea 34 8c a5 eb 0f 4b 0b-2b c9 bb 58 ec c8 44 e2   .4....K.+..X..D.

Start Time: 1475086354
Timeout   : 300 (sec)
Verify return code: 0 (ok)
---

Transcodage PEM/DER

6.2. Créer un certificat x509 auto-signé

En trois étapes :

Création de la clé privée server.key
Avec la clé privée, création d’un fichier de demande de signature de certificat (CSR Certificate Signing Request)
Auto-signature

Création de la clé privée `server.key`

# openssl genrsa -out server.key 2048
Generating RSA private key, 2048 bit long modulus
.........................................+++
..................................................................................................................................................................................+++
e is 65537 (0x10001)

# chmod 440 server.key

Avec la clé privée, création d’un fichier de demande de signature de certificat (CSR Certificate Signing Request)

# openssl req -new -key server.key -out server.req
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:BE
State or Province Name (full name) []:Brussels
Locality Name (eg, city) [Default City]:Brussels
Organization Name (eg, company) [Default Company Ltd]:Linux
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Auto-signature

# openssl x509 -req -days 365 -in server.req -signkey server.key -out server.crt
Signature ok
subject=/C=BE/ST=Brussels/L=Brussels/O=Linux
Getting Private key

Affichage du certificat

# openssl x509 -text -noout -in server.crt
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 10940766965370417421 (0x97d569969d3b710d)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=BE, ST=Brussels, L=Brussels, O=Linux
        Validity
            Not Before: Sep 28 18:31:12 2016 GMT
            Not After : Sep 28 18:31:12 2017 GMT
        Subject: C=BE, ST=Brussels, L=Brussels, O=Linux
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c4:1e:20:7c:04:56:ec:24:ef:df:02:d6:6e:95:
                    79:98:24:b1:76:51:3e:2d:46:e0:4a:b1:35:16:92:
                    7e:06:8d:03:2f:fd:6d:6f:e5:48:64:1c:11:d4:48:
                    40:08:27:53:a0:9c:cc:87:f9:f5:80:8a:44:9a:a6:
                    32:ba:30:a0:94:d9:0c:76:d0:db:26:a8:52:62:83:
                    2a:43:c1:c8:bf:36:49:a9:35:21:50:79:48:35:ca:
                    10:cf:15:f3:60:87:d2:f1:3e:b0:af:12:81:02:2e:
                    20:3a:29:a4:f2:8c:15:07:27:07:4c:05:27:b9:b6:
                    b3:d8:01:ff:77:13:ce:48:c7:ad:4c:08:64:af:39:
                    7d:1a:15:cf:aa:bd:7b:c3:d6:ae:21:7b:1f:d6:fa:
                    cc:af:39:ac:34:9e:fa:f7:a2:38:1e:b5:7b:d7:67:
                    c5:b2:9b:b5:08:af:55:27:08:87:16:8f:a4:5a:e4:
                    6f:ee:9f:05:0b:59:a1:d6:90:8e:96:66:d1:98:89:
                    27:43:ae:ba:60:f9:0d:9a:e9:1d:f4:07:a6:25:f3:
                    41:d5:a7:bc:78:4b:94:23:98:81:cf:32:1b:92:0a:
                    46:35:b7:1b:80:03:ca:14:f3:57:89:db:9c:3d:1e:
                    b3:79:61:8d:2c:49:0c:12:6b:22:fc:d1:44:64:cd:
                    e6:f1
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha1WithRSAEncryption
         79:d6:0b:23:54:0b:16:cd:00:09:8a:1e:fb:cb:33:a4:8a:73:
         c8:38:54:6f:72:e6:37:81:bf:ed:18:67:18:96:93:a0:9d:d1:
         92:45:de:3f:f1:c8:16:75:fb:e1:b6:b6:e3:b8:91:a3:f8:65:
         d4:54:09:dd:e8:2a:ba:5e:23:e0:6a:e4:a1:31:61:85:f7:7a:
         7a:7a:24:4e:c9:ed:c4:ed:e1:f9:2f:d0:bd:a2:9b:ec:32:3b:
         c8:b0:2c:56:40:c7:69:ea:cd:52:1e:60:2f:31:92:3e:90:e0:
         c3:77:59:8b:a9:1e:dc:33:44:da:99:dc:3a:21:ad:df:c4:9a:
         c8:53:42:0b:9e:67:83:7f:3e:3f:82:18:07:12:5f:4b:12:ca:
         65:8c:a9:ee:00:ab:b5:39:bd:e0:33:0f:c9:d6:db:cc:d2:f3:
         1b:bb:6e:fe:bc:c4:2c:a6:e6:de:ee:e0:ba:ff:68:1b:9b:17:
         e5:3c:83:7d:c1:03:95:8a:84:44:53:1d:fc:97:a5:2c:17:74:
         41:80:39:f7:a9:18:7c:9d:6b:5c:cb:87:83:d3:aa:4b:f6:c7:
         f0:e6:5c:4a:ce:f2:a3:b5:ef:a6:4b:c4:e0:54:66:cf:e3:3e:
         42:df:e4:a8:9d:9e:97:14:6a:eb:e2:2d:5b:23:a7:68:56:82:
         ad:b3:6e:19

6.3. Tester une liaison TLS

Arrêter le pare-feu

# systemctl stop firewalld
# iptables -X
# iptables -F
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

…