Quel certificat SSL/TLS choisir pour un serveur WWW ?

Introduction

Tout d'abord, il faut savoir pourquoi l'on veut utiliser 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)

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 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 la seule solution pour des réactions rapides!

Malheureusement, de plus en plus les clients WWW (navigateurs) font peur aux utilisateurs si le certificat n'a pas été acheté: on se demande d'ailleurs pourquoi ils laissent leurs utilisateurs naviguer en clair (sans aucun certificat) sans mise en garde mais alarment de manière sévère lorsque du chiffrement est utilisé avec un certificat auto-signé. Peut-être car la certification SSL/TLS est un "business" à millions, dont même les navigateurs libres comme Firefox profitent.

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 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.

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é.

Donc intéressant dans certains cas.

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

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.

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 impératif. 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.

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.

-- MarcSCHAEFER - 22 Aug 2014
Topic revision: r5 - 06 Feb 2016, MarcSCHAEFER
 

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback