Sécurité (Internet, logiciels, etc.)

Tester si la révocation de certificats est vérifiée par votre navigateur web

Quelques liens pour tester si la révocation de certains certificats est vérifiée par votre navigateur web (les résultats dépendent à la fois du site web et du navigateur web):

• revoked.grc.com.

• www.vinc17.net:4434 (note: ce test est obsolète car le certificat révoqué a expiré le 2015-12-12, si bien que ce n'est plus un test sur la révocation).

Test effectué le 2014-05-27 avec navigateurs à jour: sur ces 3 sites, Firefox détecte bien que le certificat a été révoqué, mais Chromium ne le détecte que pour le premier site. D'autres clients, comme le navigateur web Lynx ou l'utilitaire GNU Wget, ne vérifient rien.

Test effectué le 2015-05-03 sous Debian/unstable: maintenant Lynx et GNU Wget rapportent tous deux l'état de révocation puisqu'ils utilisent maintenant tous deux GnuTLS 3, où la vérification est faite. Mais ceci donne un faux sentiment de sécurité car aucune erreur n'est rapportée en cas d'absence de réponse OCSP, ce qui arrivera typiquement avec un serveur pirate. J'ai détecté ceci avec un serveur de test openssl s_server utilisant un certificat révoqué.

Notez que ces tests ne sont pas suffisants pour connaître le comportement de votre navigateur en cas d'attaque réelle, comme une attaque de l'homme du milieu. Par exemple, avec de tels tests, l'option security.OCSP.require de Firefox n'aura aucune influence, alors que cette option est cruciale en cas d'attaque réelle.

Agrafage OCSP (OCSP stapling)

Une des meilleures façons de vérifier si un certificat a été révoqué est l'agrafage OCSP (en anglais, OCSP stapling), avec un fallback sur l'OCSP classique (nécessaire en cas d'attaque). Mais cette méthode doit être activée sur le serveur web. Pour Apache, l'administrateur peut suivre ces instructions de 2013, en particulier:

• Dans le fichier de configuration principal de SSL (e.g. /etc/apache2/mods-available/ssl.conf):

  SSLUseStapling on
  SSLStaplingResponderTimeout 5
  SSLStaplingReturnResponderErrors off
  SSLStaplingCache shmcb:/var/run/ocsp(128000)

  [Mise à jour 2020-03] La directive SSLStaplingReturnResponderErrors off n'est pas expliquée et est surprenante. Je suppose qu'il s'agit d'un contournement d'un bug dans Apache, qui pourrait autrement retourner une fausse erreur (voir la section suivante). Ainsi, plutôt que d'obtenir une fausse erreur qui empêcherait le chargement du document, il vaut mieux un comportement comme si l'agrafage OCSP n'était pas utilisé.

• Dans chaque hôte virtuel (e.g. fichier sous le répertoire /etc/apache2/sites-available), ou la configuration principale si aucun hôte virtuel n'est utilisé: une directive SSLCACertificateFile. Par exemple:

  SSLCACertificateFile /etc/ssl/certs/ca.pem

L'agrafage OCSP doit aussi être supporté par le navigateur web. Mais d'après l'article Wikipédia OCSP stapling, seuls Microsoft Internet Explorer et Firefox 26+ le supportent (2014-05).

[Mise à jour 2015-11-15] Voir aussi The case for OCSP Must-Staple sur GRC. C'est implémenté dans Firefox 45: voir le bug 901698 de Mozilla, résolu le 2015-11-14.

Bug d'Apache concernant l'agrafage OCSP [2020-03]

Actuellement (au moins jusqu'à la version 2.4.41), si Apache ne peut pas se connecter au serveur OCSP, il propage l'erreur au client (par exemple, un navigateur web), même si la dernière réponse OCSP est toujours valide. Cela annihile l'un des buts de l'agrafage OCSP, qui est de rendre les défaillances temporaires invisibles. Voici quelques rapports de bug sur ce problème:

• Bug 57121 d'Apache: ocsp stapling should not pass temporary server outages to clients

• Bug 60182 d'Apache: SSLStaplingFakeTryLater Deviates From Documented Behavior of Only Being Effective When SSLStaplingReturnResponderErrors is On

• Bug 933129 de Debian: apache2: OCSP stapling poorly handled, yielding trylater errors in the client (que j'ai rapporté)

Ceci est d'autant plus ennuyeux que les défaillances apparaissaient sur mon serveur de plus en plus fréquemment. Un commentaire dans le bug 57121 d'Apache a finalement mentionné une méthode pour éviter le problème: l'utilisation d'un petit proxy OCSP, ocsp_proxy.

J'ai donc commencé à essayer cette méthode. Malheureusement, il y avait quelques problèmes avec ma machine sous Debian 10:

• J'ai rapporté le bug suivant: fail to start the systemd service due to the "test" utility being only in /usr/bin, qui a été corrigé rapidement après une courte discussion.

• Il y avait un peu de travail d'administration à faire, résumé ci-dessous. Ce n'était pas difficile, mais comme ce n'était pas documenté, je me suis demandé d'abord pourquoi ça ne fonctionnait pas.

• Avec la documentation fournie (et d'autres documents trouvés sur le réseau), Apache ne pouvait pas se connecter au proxy. Après quelques tests et du débuggage, j'ai fini par trouver qu'Apache essayait de se connecter en IPv4 (à cause de l'utilisation de l'adresse 127.0.0.1 dans sa configuration) tandis que le proxy écoutait sur une socket IPv6 (à cause de l'utilisation de localhost dans la configuration et du fait qu'IPv6 est préféré par défaut). Après le changement de configuration d'Apache, tout marchait bien. J'ai alors fait un pull request (contenant aussi un changement précédent), qui a été fusionné rapidement (correction de documentation pour la configuration d'Apache).

Résumé des choses que j'ai dû faire pour utiliser ocsp_proxy:

1. Installer le paquet redis (une base de données utilisée par ocsp_proxy) et d'autres paquets fournissant les modules Perl nécessaires.

2. Comme on le voit dans le fichier systemd/ocsp_proxy.service du source ocsp_proxy, ocsp_proxy se connecte à redis sur une socket Unix. Mais redis ne crée pas de socket dans sa configuration par défaut. On doit changer cela en ajoutant les deux lignes suivantes au fichier de configuration /etc/redis/redis.conf:

   unixsocket /run/redis/redis.sock
   unixsocketperm 770

   Le nom du fichier correspond à celui dans systemd/ocsp_proxy.service.

3. Redémarrer le serveur redis avec service redis restart.

4. Télécharger ocsp_proxy (par exemple en clonant le dépôt git) si ce n'est pas déjà fait, et exécuter les commandes suivantes en tant que root. La troisième doit être exécutée depuis le source d'ocsp_proxy.

   # adduser --system --group --home /var/lib/ocspproxy --no-create-home ocspproxy
   # adduser ocspproxy redis
   # make install SYSTEMD_DIR=/etc/systemd/system
   # systemctl enable ocsp_proxy.service --now

   La première commande crée un utilisateur et un groupe ocspproxy comme demandé par systemd/ocsp_proxy.service, et la seconde ajoute cet utilisateur au groupe redis pour que ocsp_proxy puisse se connecter à la socket. Puisque ce n'est pas un paquet Debian, l'installation du fichier de service doit être faite sous /etc/systemd/system; d'où l'argument SYSTEMD_DIR=/etc/systemd/system dans la troisième commande.

5. Comme cela est maintenant correctement documenté dans ocsp_proxy, reconfigurer Apache pour utiliser le proxy en ajoutant la ligne suivante au fichier de configuration SSL d'Apache, typiquement /etc/apache2/mods-available/ssl.conf:

   SSLOCSPProxyURL http://localhost:8888/

   Puis redémarrer Apache.