Le standard TLS/SSL
La sécurité du Web repose sur les standards TLS/SSL qui ont deux buts : authentifier et assurer la confidentialité d’une communication.
Une communication est qualifiée de confidentielle quand les deux parties sont sûres que personne d’autre ne peut comprendre leur communication. Le protocole TLS utilise une clé symétrique de chiffrement, connue uniquement des deux parties.
L’authentification consiste en s’assurer que la personne avec laquelle on communique est bien celle qu’elle prétend être. Pour cela, TLS utilise un chiffrement asymétrique. Un site Web qui veut prouver son identité publie une clé publique, ainsi que son certificat.
Le certificat doit être émis par une autorité de certification en laquelle les gens ont confiance. Le navigateur voulant vérifier que le site est bien le propriétaire du certificat, lui envoie un secret chiffré avec la clé publique. Le site Web utilise sa clé privée pour déchiffrer le secret, et le communiquer à l’envoyeur, qui peut vérifier qu’il s’agit bien du secret émis.
Comme seul le détenteur de la clé privée peut décoder le message, le site est bien le détenteur du certificat.
Les limitations du standard TLS/SSL
Plusieurs problèmes apparaissent avec ce système.
En premier lieu, la perte de la clé privée est catastrophique. Toute personne prenant possession d’une clé privée peut se faire passer pour le détenteur du certificat et donc falsifier son identité, et intercepter toutes les communications.
Une banque qui perdrait sa clé serait un cauchemar pour ses clients, pour la banque elle-même et toute la communauté financière. Aux États-Unis, la banque devrait en informer la Réserve Fédérale, et il est plus que probable que des lois similaires existent en Europe.
Les entreprises souhaitent donc garder leurs clés sur leurs propres sites physiques protégés.
Mais ce n’est pas toujours possible.
Toute entreprise qui utilise un hébergeur Web pour son site doit envoyer la clé à son hébergeur.
Toute entreprise hébergeant elle-même ses sites, mais utilisant des services d’accélération comme CloudFlare, doit envoyer la clé SSL à CloudFlare si elle souhaite que ses sites soient authentifiés par SSL.
La nécessité de travailler avec des fournisseurs de services externes
De très nombreuses entreprises ont pourtant intérêt à utiliser des services comme CloudFlare. D’une part parce que cela permet d’optimiser la visite du site par un client où qu’il soit dans le monde – CloudFlare affirme par exemple qu’elle a des serveurs à moins de 20 ms de connexion de toute personne sur le globe.
Mais d’autre part parce que le site est toujours en ligne, même si le serveur Web de l’entreprise est en panne.
Ou injoignable. C’est notamment le cas lorsqu’une entreprise est victime d’attaques DDOS, ou déni de service distribué, qui consiste à noyer l’infrastructure de l’entreprise sous les fausses requêtes, qu’elle ne peut plus séparer des vraies. Ses services deviennent donc indisponibles.
Paradoxalement, c’est exactement le genre de situation pour lequel un service de distribution de contenu comme Akamai ou CloudFlare est le plus utile. Ces entreprises utilisant une infrastructure ultra-distribuée dans le monde, et de très nombreux fournisseurs de communication simultanément, il est quasi impossible de lancer des attaques DDOS contre elles.
D’un côté les banques (et d’autres entreprises) souhaiteraient utiliser ces fournisseurs de service. De l’autre ils ne le peuvent pas parce qu’il est hors de question de leur transmettre la clé privée SSL.
Le SSL sans clé
CloudFlare vient d’annoncer la disponibilité du SSL sans clé.
En 2012, l’intuition de Sébastien Pahl, un ingénieur système français de CloudFlare, est qu’il est possible de procéder à des authentifications TLS/SSL sans avoir accès à la clé privée.
La clé privée n’est en fait utilisée qu’au début de la communication sécurisée : lors de la négociation (handshake), avant de se mettre d’accord sur une clé de session. Par la suite, seule cette clé de session, temporaire, sera utilisée.
Pahl créera une preuve de concept. Dans les années qui suivent, le système sera amélioré par l’équipe de CloudFlare, puis vérifié par des chercheurs universitaires et des entreprises de sécurité pour s’assurer qu’il est sûr.
Un agent CloudFlare tourne dans l’infrastructure du client, et communique de façon sécurisée avec CloudFlare. Les serveurs Web (NGINX) et la gestion OpenSSL chez CloudFlare sont ajustés pour permettre les opérations à distance sur les clés privées et les empêcher de bloquer le système, afin que les serveurs puissent continuer à répondre à d’autres requêtes en attendant la réponse d’un serveur de clés.
Le serveur de clé, qui tourne chez le client, est disponible pour Linux, la plupart des systèmes Unix, et Windows. Il sera bientôt intégré aux solutions HSM (module matériel de sécurité, un appareil considéré comme inviolable offrant des fonctions cryptographiques).
Limitations
Plusieurs limitations existent encore.
Même si le système a été vérifié par des universitaires et des spécialistes privés de la sécurité, seule une exposition plus large et plus longue aux attaques confirmera la qualité de la sécurité du système.
Et le système nécessite un lien fort de confiance entre le fournisseur de service, en l’occurrence CloudFlare, et le client, comme une banque. En effet toutes les communications entre CloudFlare et le ou les serveurs de clés chez le client sont chiffrés, en utilisant des certificats émis par la propre autorité de certification de CloudFlare.
Le client peut certes créer des règles pare-feu pour limiter les communications aux adresses IP de CloudFlare. Mais qu’en est-il d’un employé indésirable chez CloudFlare ?
Conclusion
Si le système SSL sans clé de CloudFlare s’avère réellement sans faille sécuritaire, il révolutionne la sécurité sur Internet. Tous les Clouds deviennent privés, il n’y a plus de Cloud publique. Les entreprises peuvent faire appel à des fournisseurs de services Cloud sans craindre que leur clé SSL ne soit volée.
Ou tout du moins, la sécurité des clés privées des entreprises ne dépend que d’elles-mêmes.
Note : CloudFlare est un fournisseur de services du Diligent. Le Diligent ne reçoit aucune condition spéciale, paie les services de CloudFlare au même prix publique que les autres clients, et n’a pas été contacté par CloudFlare concernant cet article.