Quel certificat SSL/TLS choisir pour un serveur WWW ?

Introduction

Tout d'abord, il faut savoir pourquoi l'on veut utiliser un certificat X.509 SSL/TLS:

• pour éviter que les mots de passe circulent en clair, par exemple, sans mettre en oeuvre des processus d'authentification non rejouables et non décryptables comme auth/digest

• pour éviter que les données passent en clair

• pour permettre aux utilisateurs de valider que c'est bien notre serveur WWW et pas un imposteur (à cause d'une attaque DNS locale ou distante, ou d'une attaque d'homonymie, voire une attaque en général peu probable man in the middle -- du relais en français)

• pour améliorer le référencement sur certains moteurs de recherche qui priorisent https:// sur http://

Les différents types de validation de certificats

Le certificat auto-signé

Pour réaliser les deux premiers buts ci-dessus, il n'est pas nécessaire d'utiliser une autorité de certification reconnue: un certificat auto-signé, gratuit, simple, de longue durée et sans risque externe d'annulation suffit amplement. Il faudra juste éduquer ses utilisateurs à vérifier l'empreinte du certificat, ou préinstaller le certificat et bien sûr assurer que la clé privée ne soit jamais en possession d'un tiers. Dans un monde où des problèmes de sécurité sont très souvent mis à jour, dont certains peuvent mener à des compromission de clés privées, c'est probablement une bonne solution pour des réactions rapides!

Malheureusement, de plus en plus les clients WWW (navigateurs) font peur aux utilisateurs si le certificat n'est pas lié à une chaîne de confiance X.509 du navigateur: on se demande d'ailleurs pourquoi ils laissent leurs utilisateurs naviguer en clair (sans aucun certificat) avec peu de mise en garde mais alarment de manière sévère lorsque du chiffrement est utilisé avec un certificat auto-signé.

En résumé, cela n'est envisageable qu'avec des utilisateurs formés et dans un cadre administratif donné (exemple: entreprise).

L'autorité de certification locale

L'idée est ici de créer un certificat d'autorité de certification local, qui sera préinstallé sur tous les clients. Ce certificat servira ensuite à signer tous les certificats de l'entreprise et donc à assurer également le 3e but.

C'est très flexible, cela permet de diminuer les coûts directs et indirects, et d'éviter un risque de déni de service (DoS) de la part d'un prestataire externe (notamment si ce prestataire met en place un serveur de révocation OCSP).

On peut même pousser le vice jusqu'à mettre en place des procédures de roll-out de clés, un OCSP, et même deux clés de CA: un CA root sorti une fois par an du coffre-fort, et un CA de deuxième niveau signé par le premier qui sert à la certification des certificats TLS/SSL. A voir si cela est vraiment utile dans le contexte d'une organisation.

Cette solution rend l'entreprise indépendante. Evidemment, il faut installer le certificat du CA local sur tous les équipements (y.c. smartphones). Et cela augmente le risque, si le CA est mal géré, concernant l'ensemble des sites Internet (un CA peut signer n'importe quel certificat, sauf cas particuliers).

C'est aussi la solution qui est utilisée dans le système de détection de malwares basé sur le Man in the Middle (MitM), tel qu'installé par exemple dans des écoles par Swisscom, avec une génération dynamique de certificats temporaires (falsifiés) pour tous les sites Internet.

L'autorité de certification coopérative CAcert

Comme cette autorité n'est pas reconnue par tous, cela correspond un peu au cas ci-dessus de l'autorité de certification locale. De plus, cela rajoute une dépendance externe et transfère de la sécurité.

En pratique peu utile aujourd'hui

Une autorité de certification classique

Exemples: Verisign, StartSSL, ...

Avantage principal: cette autorité est préinstallée dans tous les clients (navigateurs, etc).

Inconvénients

• dépendance à un prestataire externe, risque de DoS voire même de bannissement de l'autorité de certification en cas d'erreur grave (arrivé 1-2 fois par an récemment!)
• certificats de durée limitée (2 ans) à très limitée (1 ans ou moins)
• coût élevés, sauf éventuellement pour les certificats qui ne certifient pas grand chose

Ces autorités différencient souvent (en prix et en fanions sur le certificat) entre

• vérification simple (en général: on ne vérifie que votre capacité à lire les e-mails du domaine certifié, p.ex.); le certificat sera visible en bleu dans les navigateurs et le nom de l'organisation ne figurera pas dans le certificat.
• vérification étendue (passeport, fondé de pouvoir, etc): ce processus s'appelle Extended Validation et est souvent visible en vert dans les navigateurs; de plus, le certificat comporte le nom de l'organisation ainsi certifiée -- c'est de moins en moins mis en avant par les navigateurs

Notons qu'il est déjà arrivé que des autorités de certifications se trompent lors d'une vérification étendue et délivrent un certificat à la mauvaise autorité.

Les entreprises ayant affaire au grand public sont quasiment obligées à acheter des certificats E.V. pour diminuer le risque d'une fraude par imitation, et bien sûr limiter leur frais de helpdesk: de plus, il leur est recommandé d'utiliser des CA de la même juridiction (voir rapport MELANI p. 16).

Votre propre CA certifié

Les très grandes entreprises et administrations publiques (p.ex. la Confédération suisse) peuvent avoir intérêt à obtenir un certificat signé par une autorité de certification comme dans le cas précédent, mais avec un fanion en plus qui permet à ce certificat d'agir lui-même comme autorité de certification. En général, le certificat est limité en portée à quelques domaines particuliers.

L'avantage est une réduction du risque externe, dans la mesure où le CA propre lui-même n'est pas invalidé directement ou indirectement.

Certificats automatiques

Une option intéressante, par exemple avec Apache et la fondation Mozilla, est Let's Encrypt. Elle supporte désormais même les certificats wildcards.

C'est probablement la meilleure solution aujourd'hui dans beaucoup de cas.

Synthèse

Lorsque la réduction des risques externes est un impératif incontournable, un CA local (non reconnu, mais préinstallé sur les postes de l'entreprise) est la meilleure solution. Dans certains cas (p.ex. 802.11x EAP-TTLS, p.ex. une authentification WiFi WPA Entreprise sur un Radius), il est plus simple d'utiliser un certificat auto-signé, d'autant plus que la liste des CA reconnus sur les smartphones pour EAP est souvent vide.

Lorsque l'on s'adresse au grand public, un certificat signé par une véritable autorité de certification reconnue est encore aujourd'hui recommandé. Son niveau de vérification dépend de l'usage considéré, mais un certificat EV est recommandé pour limiter les frais de helpdesk, sans garantir une véritable meilleure protection en général.

Pour rapidement obtenir des certificats valides sans coût avec renouvellement automatique, Let's Encrypt est recommandé.

L'avenir

Une fonction qui serait essentielle et qui permettrait de passer des chaînes de confiance X.509 où un certificat est signé par une seule autorité de certification, aux fameux réseaux de confiance popularisés par PGP/GPG dans les années 90, serait la signature multiple d'un certificat par plusieurs autorités de certification, et l'utilisation de serveurs d'état de certificat OCSP propres à chaque signataire.

Cela permettrait deux choses

• limiter l'impact de la compromission ou de la folie d'un CA
• modification de la confiance face aux certificats par un système de "ranking" ou de points, où un certificat serait plus sûr s'il est signé par beaucoup d'autorités (trust chains)

Cela n'est pour le moment pas possible, car cela nécessiterait au moins un changement de la spécification X.509.

Par contre, il est désormais possible de réduire l'impact d'un CA compromis en indiquant dans le DNS quels CA ont le droit de signer quels domaines.