Depuis quelques semaines, vous pouvez installer simplement et gratuitement un certificat Let's Encrypt sur votre serveur et disposer d'une connexion HTTPS. Mais que se cache-t-il derrière cette petite révolution qui veut généraliser le fameux cadenas vert ? 

Let's Encrypt est disponible en bêta publique depuis la fin de l'année dernière et commence à être intégré aussi bien chez des hébergeurs comme Gandi et Infomaniak, que dans des produits grand public comme les NAS de Synology ou le boîtier Server de la Freebox.

Pour rappel, ce projet vise un objectif assez simple à comprendre, mais complexe à atteindre : faciliter la mise en place d'un certificat SSL/TLS par ceux qui hébergent leur site web, notamment ceux qui ont le moins de moyens. Un élément vital lorsqu'il s'agit d'établir une connexion sécurisée (HTTPS) affichant le fameux cadenas, une phase reposant sur un chiffrement asymétrique avec un couple de clefs publique/privée dont il faut s'assurer de l'origine.

Il rejoint ainsi une tendance actuelle du secteur, accompagnée par des acteurs comme Google ou Mozilla qui poussent à une adoption massive de HTTPS à travers leurs différents outils. Chrome et Firefox commencent ainsi progressivement à préparer le terrain pour un changement important de paradigme : une page HTTPS sera bientôt la norme, et une page HTTP classique une variante « non sécurisée ».

Des cadenas rouges commencent ainsi peu à peu à apparaître, dans l'édition développeur de Firefox ou même dans Gmail. L'aboutissement de plusieurs années d'évolution, qui ne doit pour autant pas nous faire perdre notre discernement : la présence d'un cadenas vert ne veut pas dire qu'un site est fiable. Uniquement que la liaison est sécurisée.

X.509 et autorités de certification : une question de confiance

Contrairement à PGP et son « web of trust », SSL/TLS repose sur un standard connu sous le petit nom de X.509. Et si dans le premier cas, chacun peut signer une clef publique afin d'assurer de sa fiabilité et constituer une chaîne de confiance, dans le second, cela repose principalement sur les autorités de certification. 

Elles font office de tiers de confiance dont le rôle est de s'assurer de l'identité d'une personne ou d'une société afin de lui délivrer un certificat. Le niveau de vérification peut être plus ou moins important et il est parfois question de différentes classes. Cela peut ainsi aller du simple email à la rencontre physique, en passant par la fourniture de documents officiels. 

Les autorités de certification sont des entreprises privées, qui n'ont pas besoin d'une reconnaissance particulière pour opérer. Par contre, elles doivent détenir un sésame important pour être considérées comme légitimes : les principaux navigateurs doivent leur accorder leur confiance et intégrer leur certificat racine.

Si ce n'est pas le cas, l'internaute qui visite un site avec un certificat généré par une autorité de certification non reconnue aura droit à une belle erreur affichée dans une page aux tons rouges. De quoi en rebuter plus d'un. Il reste néanmoins possible de procéder à un rajout manuel si l'on décide de faire confiance à une autorité non intégrée nativement au navigateur.

Au final, il est ici aussi question d'une chaîne de confiance. L'utilisateur doit ainsi faire confiance à son navigateur, qui décide de faire confiance à des sociétés privées qui décident ou non de faire confiance à leurs clients. Un système plus centralisé que PGP donc, mais qui a tout de même connu son lot de problèmes à travers le temps : vols de certificats, faux certificats, certificats bloqués, etc. Il reste néanmoins la norme pour ce qui est de la protection des communications entre serveurs web.

Derrière un cadenas, plusieurs types de certificats

Les certificats proposés dans le cadre de l'hebergement peuvent être établis pour un domaine en particulier, plusieurs ou tous ses sous-domaines.  On parle alors de certificat wildcard.

On distingue aussi les certificats à validation étendue (EV) qui permettent d'obtenir une barre verte près du cadenas affiché au sein du navigateur. Le signe qu'un minimum de vérifications ont été effectuées concernant la société à qui appartient le domaine, selon les directives du CA/Browser Forum. Certaines informations sont d'ailleurs directement intégrées au certificat et vérifiables par l'internaute (adresse, type de société, SIREN).

Longtemps, obtenir un certificat a donc été une affaire de professionnels disposant de moyens pour se les payer : site de vente en ligne, banques, éditeurs de logiciels, emails en entreprise, etc. Ils sont d'ailleurs le plus souvent associés à des garanties financières en cas de problème pouvant atteindre plusieurs centaines de milliers de dollars.

Mais avec le temps, et la montée en puissance de la demande pour le chiffrement des échanges par tout un chacun, les choses ont commencé à changer.

Obtenir un certificat gratuit, c'est possible depuis longtemps

Depuis quelque temps, il est ainsi possible d'obtenir gratuitement des certificats plus ou moins limités. Pour ceux qui un besoin essentiellement personnel, des acteurs comme Comodo et StartSSL proposent d'obtenir un certificat qui se base sur une simple vérification de votre adresse email.

Il vous permet ainsi de chiffrer ou de signer vos emails à travers des clients compatibles avec S/MIME, ce qui est assez répandu, même sur mobile (Outlook sous Windows, Mail chez Apple, Thunderbird, etc.) et relativement simple à mettre en place. Vous pouvez aussi vous en servir pour signer des documents ou vous connecter à certains services.

Ils seront par contre limités à une adresse précise et ne pourront pas être utilisés pour établir une connexion sécurisée sur un site web par exemple. StartSSL propose néanmoins un certificat Classe 1 gratuit pour un domaine dans le cadre d'une utilisation personnelle et non commerciale. 

Vous pouvez aussi obtenir un certificat gratuit pendant un an chez GoDaddy pour un projet open source, alors que chez Gandi, ce sera pour tout achat d'un domaine que le certificat vous sera offert la première année. D'autres autorités de certification jouent plutôt sur la possibilité de tester leur service pour une courte durée. C'est par exemple le cas de GeoTrust ou RapidSSL qui proposent un certificat pour une durée de 30 jours, contre 90 jours chez Comodo.

CAcert : l'acte manqué

Et si de telles pratiques sont désormais courantes, un autre acteur avait cherché à rendre plus accessible l'obtention d'un certificat il y a quelques années : CAcert. Il s'agit d'une association à but non lucratif, fondée en 2003 et basée en Australie, qui se présente comme « une Autorité de Certification communautaire qui émet gratuitement des certificats pour tous ».

Outre le fonctionnement classique qui se base sur une vérification automatisée de l'email, le service reprend les bases du « web of trust » de PGP et propose à ses membres de se rencontrer afin de signer leurs clefs respectives au sein de son Assurance Program. L'acquisition de points donne accès à des privilèges supplémentaires (voir la liste).

Mais dans la pratique, CAcert n'est reconnu par aucun des grands navigateurs. Ainsi, une erreur s'affiche pour les visiteurs qui n'ont pas choisi d'intégrer manuellement le certificat racine de l'autorité de certification, un peu comme lorsque l'on est en présence d'un certificat auto-signé.

Pendant un temps, des discussions avaient été engagées avec Mozilla. Courant 2006, Frank Hecker ouvrait la porte à une intégration sous réserve du respect des pratiques de la fondation en la matière. Un audit indépendant était notamment nécessaire et avait été commencé.

Mais fin avril 2007, Ian Grigg annonçait que l'audit avait été suspendu quelques mois plus tôt afin de prendre le temps de structurer CAcert de manière correcte face à son ambition d'une intégration par les navigateurs. Une situation qui n'a pas évoluée depuis. CAcert est néanmoins intégré par quelques distributions Linux ou proposé sous la forme d'un package à installer.

Pour autant, cette idée n'est pas oubliée et en novembre dernier, l'association mettait en place une nouvelle équipe avec pour but de pouvoir valider un audit. Cela passe notamment par le renouvellement de la signature du certificat racine en exploitant SHA256 en remplacement de MD5. Après un essai réussi l'été dernier, l'évènement avait été prévu pour le 29 janvier. Il a finalement été décalé à une date ultérieure.

Let's Encrypt : une autorité reconnue, grâce à Identrust

Il aura donc fallu attendre 2014 pour voir émerger une nouvelle initiative du genre : Let's Encrypt. Elle est opérée par une « Public benefit corporation », à la manière de Kickstarter : l'Internet Security Research Group (ISRG). Basée à San Francisco mais défiscalisée, elle s'engage à agir pour le bien public. Elle compte à son directoire des membres qui font partie de l'Université du Michigan, l'École de droit de Stanford, Mozilla, Akamai, Cisco, CoreOS ou encore l'EFF.

La plupart de ces entités font aussi partie de la liste des sponsors qui compte d'autres membres prestigieux : Chrome, Facebook, Automattic (Wordpress) et Shopify. On retrouve aussi une pléthore d'hébergeurs dont trois bien connus chez nous : Gandi, Infomaniak et OVH (qui a opté pour le niveau Platinum). De son côté, le fournisseur d'accès Free a récemment intégré la liste. Chacun peut aussi y aller de son petit don.

Dans la pratique, Let's Encrypt est donc une nouvelle autorité de certification, mais qui a cette fois droit aux honneurs des principaux navigateurs. Pour autant, cela ne veut pas dire que son certificat racine (ISRG Root X1) est reconnu. L'audit et la procédure sont actuellement en cours, notamment auprès de Mozilla.

Pour le moment, les certificats intermédiaires, qui signent ceux délivrés aux utilisateurs, ont eux-mêmes été signés par Identrust (sponsor Gold du projet) avec son DST Root CA X3. Celui-ci ayant la confiance des principaux navigateurs, aucune erreur ne sera donc affichée.

L'automatisation jusqu'à l'installation du certificat

Let's Encrypt vise à simplifier la création et l'installation d'un certificat SSL/TLS gratuit sur un serveur, pour une durée de trois mois (renouvelable). De quoi permettre à chacun de proposer des connexions sécurisées, afin de chiffrer les contenus échangés, de s'assurer de l'identité du serveur et d'éviter que le contenu ne soit altéré.

Par contre, vous ne pourrez pas utiliser le certificat généré pour un autre usage comme le chiffrement de vos emails ou la signature électronique par exemple. La vérification de l'identité est assez basique et l'ensemble du processus tient d'une sorte de croisement entre StartSSL (pour l'aspect gratuit) et SSLMate qui avait introduit une automatisation assez intéressante du processus d'achat et d'acquisition des certificats SSL. 

Dans son billet d'annonce, l'EFF indiquait en effet que son objectif premier était de réduire le temps d'installation qui restait de son point de vue un problème. On pouvait alors lire que l'équipe du projet avait relevé qu'il fallait entre une et trois heures à un développeur pour activer le chiffrement sur un site avec la méthode habituelle, contre 20 à 30 secondes avec Let's Encrypt.

Plusieurs outils ont ainsi été développés comme Boulder (en Go), pour l'autorité de certification. Mais aussi d'un protocole en voie de standardisation (ACME) et un client open source. Notez que celui-ci peut être aisément remplacé, on retrouve ainsi déjà de nombreuses alternatives.

De quoi donner des idées d'intégration, qui commencent à porter leur fruit comme nous l'avons évoqué plus haut, puisque plusieurs hébergeurs commencent à proposer une solution, parfois de type 1-click à la manière d'Infomaniak. Mais cela concerne aussi les fabricants d'appareils dont l'administration se fait via une interface web ou qui proposent d'héberger du contenu comme le boîtier Server de la Freebox ou les NAS de Synology. 

Et ce n'est sans doute qu'un début, d'autres sociétés travaillant sans doute activement à leur propre solution. On pense notamment à des acteurs comme Automattic, sponsor de Let's Encrypt, qui édite Wordpress.

La phase de bêta ouverte : entre réussite et évolutions nécessaires

Depuis décembre, Let's Encrypt est donc en bêta publique. Et l'on peut d'ores et déjà dire que la promesse de base est tenue. En effet, le script (Python) est assez simple à mettre en place, surtout si l'on respecte les règles de base de la phase de bêta : exploiter un serveur Apache 2.x sous Debian8+ ou Ubuntu 12.04 +.

Le support de nginx 0.8.48 + est intégré, mais encore expérimental. Il demandera donc un peu plus de pratique puisque le mode entièrement automatisé ne pourra pas être utilisé. Si vous disposez de tous les éléments requis, cela tiendra en quelques lignes de code seulement, afin de récupérer les fichiers depuis le dépôt GitHub puis de lancer le script d'installation automatisé :

user@webserver:~$ git clone https://github.com/letsencrypt/letsencrypt
user@webserver:~$ cd letsencrypt
user@webserver:~/letsencrypt$ ./letsencrypt-auto

Notez que vous pouvez préciser les domaines pour lesquels vous demandez un certificat (-d), utiliser un serveur de test afin de vérifier que tout se passe bien (--test-cert) ou même passer par une procédure (accessible uniquement dans certains cas) qui ne nécessitera pas un arrêt du serveur web (webroot). 

• Tutoriel de base
• Documentation détaillée

Au final, tout semble donc parfait dans le meilleur des mondes. Mais il faudra tout de même que Let's Encrypt rassure et évolue pour réellement prendre de l'ampleur. Comme nous l'avions déjà évoqué dans un précédent article, les choix techniques effectués, notamment sur les paramètres utilisés par défaut, peuvent être critiqués.

Il faudra aussi un support plus large des plateformes, et un renforcement des procédures pour limiter les dérives. En effet, TrendMicro expliquait récemment comment certains petits malins pouvaient utiliser l'automatisation du système afin de disposer de certificats utilisés à des fins peu recommandables. 

50 nuances de HTTPS : l'internaute va avoir mal (aux cheveux)

Mais cette problématique n'est pas propre à Let's Encrypt même si le fonctionnement même du système peut renforcer le problème. Cela va devoir introduire un niveau de compréhension des certificats SST/TLS de base, qui ne sont qu'une validation de domaine (DV). De quoi complexifier le message derrière le fameux cadenas vert qui avait été pensé pour rassurer les internautes en un coup d'œil.

Seule certitude : ce certificat est valide pour ce domaine

Pourtant, son apparition peut n'être qu'une confirmation de l'accès au serveur accessible par un domaine (ou un sous-domaine) particulier, ce qui peut être le cas d'une personne mal intentionnée. En aucun cas cela ne confirme forcément l'identité de l'éditeur ou les bonnes intentions d'un site et de son contenu.

Pour avoir des détails complémentaires, il faut aller regarder de près le certificat. Les certificats à validation étendue ont ainsi cet avantage d'apporter une dose de confiance supplémentaire, puisqu'une existence légale de la société dont le nom est précisé dans la barre verte doit avoir été vérifiée.

Quel rôle pour une autorité de certification ?

L'ISRG avait d'ailleurs anticipé cette problématique et évoqué ce qu'elle estime être son rôle face à la problématique du phishing et des malwares. Elle y expliquait qu'il ne s'agissait pas de vérifier le contenu des sites et d'en juger afin de savoir s'il faut ou non révoquer un certificat.

Simple prestataire technique qui doit s'assurer de la détention d'un domaine, elle préfère donc se reposer sur des acteurs de plus grande importance comme les navigateurs, qui ont une plus grande connaissance du contenu et surtout, bien plus de ressources à leur disposition. Mais ce débat n'est sans doute pas définitivement tranché, et devrait revenir sur le devant de la scène. 

Pour le moment, une vérification est donc effectuée à travers la Google Safe Browsing API pour bloquer l’émission de certificats à des sites considérés comme malveillants. Pour rappel, cette base de données est notamment utilisée par Chrome et Firefox (voir cet article).

Reste à voir si cela sera suffisant ou s'il faudra trouver des parades afin de ne pas donner aux internautes une fausse impression de sécurité du fait de la présence d'un cadenas vert, qui n'indique qu'un chiffrement de la communication avec le serveur du site. 

Car la montée en puissance du HTTPS pour tous n'en est qu'à ses débuts. Hébergeurs, internautes, éditeurs et autres acteurs du web vont devoir adapter leurs usages et leurs réflexes. Si l'arrivée de Let's Encrypt aura assurément été un tournant, il s'agit là des prémices de ce qui n'est simple étape de cette petite révolution.