Serveur GoAhead : des certificats TLS révoqués restent acceptés

Le serveur GoAhead charge une liste de révocation sans l'activer : un certificat client révoqué peut encore se connecter.
Une faille touche le serveur GoAhead, un serveur web très répandu dans les équipements embarqués. Son moteur TLS par défaut charge bien une liste de révocation de certificats. Pourtant, il n’active jamais la vérification correspondante. Un certificat client révoqué peut donc encore passer l’authentification sur les configurations concernées.
Le problème est discret, mais il touche un mécanisme de sécurité essentiel. En effet, la révocation sert à couper l’accès d’un appareil ou d’un utilisateur dont le certificat est compromis. Si elle ne s’applique pas, la mesure reste purement théorique.
Serveur GoAhead : une révocation chargée mais jamais appliquée
Le défaut se situe dans la gestion du moteur TLS par défaut. L’administrateur configure une liste de révocation (CRL) pour bloquer les certificats clients invalidés. Le serveur lit ce fichier et le charge en mémoire. Cependant, l’option qui force le contrôle de cette liste n’est jamais activée.
Autrement dit, la liste est présente, mais personne ne la consulte. Le serveur valide alors le certificat comme si aucune révocation n’existait. Un client dont le certificat a été retiré peut ainsi ouvrir une session.
Ce type d’erreur est trompeur. D’abord, la configuration paraît correcte, car la liste est bien déclarée. Ensuite, aucun message d’erreur n’alerte l’administrateur. Par conséquent, une équipe peut croire à tort que ses certificats révoqués sont bloqués.
Quelles configurations sont exposées ?
Le défaut concerne les builds qui utilisent le moteur OpenSSL avec une authentification TLS mutuelle. Dans ce mode, le serveur vérifie le certificat du client, et le client vérifie celui du serveur. Une liste de révocation doit en plus être configurée pour écarter les certificats invalidés.
Ces trois conditions doivent donc être réunies :
- un build GoAhead s’appuyant sur le moteur OpenSSL ;
- l’authentification mutuelle TLS activée ;
- une liste de révocation de certificats déclarée dans la configuration.
Les déploiements qui n’utilisent pas l’authentification par certificat client ne sont pas concernés par ce volet. En revanche, les environnements industriels, les routeurs ou les caméras qui reposent sur ce mode méritent une vérification rapide. Ces équipements sont souvent installés pour de longues années, et leurs mises à jour restent rares.
Un risque de déchiffrement des sessions
L’alerte d’origine évoque aussi une seconde faiblesse TLS pouvant permettre de déchiffrer des sessions. Les éléments dont nous disposons ne détaillent ni son mécanisme, ni son identifiant CVE, ni les versions touchées. Nous préférons donc ne pas extrapoler à ce stade.
Toutefois, le cumul des deux défauts mérite l’attention. D’un côté, un certificat révoqué reste accepté. De l’autre, la confidentialité des échanges peut être mise en cause. Pour un équipement exposé, ces deux risques touchent à la fois l’accès et le secret des données.
Il est donc prudent de suivre les avis officiels de l’éditeur. Les correctifs et la liste précise des versions affectées y seront publiés. Il faudra les comparer avec les builds réellement déployés.
Que faire sur un serveur GoAhead exposé ?
Plusieurs actions peuvent réduire le risque sans attendre. Elles ne remplacent pas un correctif, mais elles limitent l’exposition.
- Inventorier les équipements. Identifiez tous les appareils qui embarquent GoAhead, y compris ceux fournis par des tiers.
- Vérifier le moteur TLS. Contrôlez si le build repose sur OpenSSL et si l’authentification mutuelle est active.
- Tester la révocation. Présentez volontairement un certificat révoqué dans un environnement de test. Si la connexion réussit, le serveur est vulnérable.
- Compenser en amont. Placez un proxy inverse ou un pare-feu applicatif qui contrôle réellement la révocation devant l’équipement.
- Réémettre les certificats sensibles. Remplacez ceux qui ont été révoqués pour cause de compromission, et réduisez leur durée de validité.
- Restreindre l’accès réseau. Limitez l’interface d’administration à des adresses de confiance.
Par ailleurs, surveillez les journaux de connexion. Une authentification réussie avec un certificat connu comme révoqué doit déclencher une enquête. Ce signal est précieux, car il trahit une exploitation possible du défaut.
Ce qu’il faut retenir
- Le serveur GoAhead charge la liste de révocation, mais n’active pas le contrôle associé.
- Un certificat client révoqué peut donc encore s’authentifier.
- Les builds avec moteur OpenSSL et TLS mutuel, avec une CRL configurée, sont concernés.
- Une seconde faiblesse TLS, liée au déchiffrement de sessions, est signalée, mais ses détails restent à confirmer.
- Testez vos équipements, appliquez les correctifs de l’éditeur dès leur disponibilité et ajoutez un contrôle de révocation en amont.
Cette affaire rappelle une règle simple. Une protection n’a de valeur que si elle est réellement appliquée. Configurer une mesure ne suffit pas : il faut aussi vérifier qu’elle fonctionne.
Source : GoAhead TLS Flaws Allow Revoked Client Certificates and Enable Session Decryption