Mon blog

Les révélations de Snowden ont sérieusement relancé l'intérêt pour la sécurité informatique, et notamment sur les risques d'espionnage. Mais, en sécurité, le mieux est parfois l'ennemi du bien. Certaines exigences de sécurité peuvent mener à des solutions techniquement parfaites mais tellement compliquées à utiliser qu'elles ne seront que peu ou pas déployées. C'est par exemple le cas de l'authentification pour utiliser le chiffrement. Si on impose l'authentification forte du pair avant de chiffrer, on risque de ne pas pouvoir chiffrer, dans des cas où ce serait pourtant bien utile. Ce nouveau RFC, par le mainteneur de Postfix, définit un concept utile, cela de sécurité opportuniste (opportunistic security) : on chiffre quand on peut, même sans authentification, et on authentifie si c'est possible. L'idée est d'augmenter sérieusement la part de trafic chiffré dans l'Internet.

Un petit détour technique, avant de commencer le RFC. Pourquoi chiffrer sans authentifier est-il dangereux ? Si on ne veut que la confidentialité, mais qu'on se moque de l'identité du pair avec qui on communique, pourquoi s'embêter à authentifier, surtout lorsqu'on sait que chiffrer est si simple et authentifier si compliqué ? C'est parce que chiffrer sans authentifier vous rend vulnérable à l'Homme du Milieu. Celui-ci, tapi dans le réseau, entre Alice et Bob, va recevoir les messages d'Alice et les transmettre à Bob (et réciproquement) et cela, évidemment, après lecture. Chiffrer ne sert à rien s'il y a un homme du milieu : Alice croit chiffrer pour Bob alors qu'elle chiffre en fait pour l'espion qui pourra donc lire le texte en clair avant de le chiffrer et de le passer à Bob.

À noter que l'homme du milieu est forcément actif : il doit maintenir un canal de communication avec Alice et un avec Bob. Parfois, pour des raisons pratiques ou bien juridiques (un attaquant actif peut relever de lois pénales plus sévères), l'attaquant reste passif et, dans ce cas, le chiffrement seul, sans authentification, protège parfaitement. Attention, toutefois : pas mal de personnes semblent croire que seul le FAI ou bien la NSA peuvent faire des attaques actives : or, celles-ci sont plus faciles que ne le croit M. Toutlemonde (usurpation ARP par exemple).

La solution correcte aux attaques de l'homme du milieu est l'authentification : si Alice vérifie qu'elle parle bien à Bob, et uniquement à lui, alors, elle pourra détecter quand un homme du milieu sera présent, et éviter ainsi de lui passer ses secrets. C'est le mode « tout ou rien » (soit on authentifie, soit on avorte la communication) qui était traditionnel dans les protocoles IETF (à part quelques exceptions comme la sécurité « mieux que rien » du RFC 5386). Mais l'authentification n'est pas facile. Prenons un exemple, celui de HTTPS, qui utilise la plupart du temps des certificats X.509 pour l'authentification. Des tas de choses peuvent aller mal : certificats expirés, signés par une autorité inconnue de ce navigateur, auto-signés pour éviter de payer des AC à l'utilité douteuse, et tous les autres malheurs qui ponctuent la vie de l'internaute qui essaie de se connecter en HTTPS. L'utilisateur se rabat donc souvent sur du simple HTTP non chiffré. De peur de l'homme du milieu, il fait tout passer en clair ! Cet état de chose est évidemment absurde. Lorsqu'on a un des fameux avertissements de sécurité « ce certificat a un problème incompréhensible pour vous, qu'est-ce que vous décidez ? », c'est dans la grande majorité des cas une erreur du serveur et pas une attaque de l'homme du milieu. Il vaudrait donc mieux, lorsque le site est également accessible en HTTP ordinaire, chiffrer sans authentification : cela ne peut jamais être pire que de ne pas chiffrer du tout. (Les sites HTTPS à plus haut niveau de sécurité, comme une place de marché Bitcoin, imposent HTTPS, et, en cas d'erreur, il n'y a qu'à pleurer en attendant la réparation.)

Ce débat sur l'authentification obligatoire est aussi ancien que la cryptographie. Je me souviens des vieux dinosaures de la sécurité regardant SSH avec méfiance, lors de son introduction, car l'authentification n'était pas obligatoire. Mais les solutions que prônaient ces sympathiques tétrapodes étaient tellement complexes à déployer que les gens ne chiffraient pas, et utilisaient telnet. Il est donc clair que SSH, même avec son modèle TOFU (Trust On First Use) d'authentification plutôt faible, a amélioré la sécurité de l'Internet. Le TOFU n'est pas parfait (il est vulnérable si l'homme du milieu est présent dès la première connexion, et il ne permet pas de savoir si un changement de clé est normal ou pas) mais il a permis de remplacer massivement l'ancien telnet par un protocole chiffré.

Outre HTTPS et SSH, plusieurs protocoles utilisent du chiffrement, et ont des solutions plus ou moins bonnes pour l'authentification. Des solutions comme DANE (RFC 6698) ont été proposées pour résoudre une partie des problèmes d'authentification mais, à l'heure actuelle, il est clair que l'Internet n'a pas de solution d'authentification généraliste techniquement correcte, politiquement sûre, et effectivement déployée.

Ce débat a mené au terme de sécurité opportuniste (opportunistic security), qui date de bien avant le RFC. Mais il n'était pas défini rigoureusement. Parfois, il désignait le fait de faire de la crypto sans que l'utilisateur l'ait explicitement demandé (ce que fait HTTPS Everywhere en transformant d'autorité des sessions HTTP en HTTPS), parfois il désignait le chiffrement sans authentification (c'est le sens qu'il a dans le RFC 5386), parfois la capacité de basculer automatiquement en mode non-chiffré (la définition du Wikipédia anglophone) et parfois enfin du chiffrement avec authentification mais sans avoir de configuration spécifique par pair (c'est ainsi que le RFC 4322 utilise le terme). Notre RFC lui donne une définition stable, qui sera utilisée dans les documents ultérieurs de l'IETF, comme le futur HTTP 2 ou comme DANE pour SMTP.

Bref, on change de perspective : d'un modèle où on authentifie systématiquement, protégeant contre les attaques passive et actives (et où l'absence d'authentification n'est citée que comme « mode dégradé », voire coupe la communication complètement), on passe à un modèle plus réaliste où l'état de base est l'absence de toute protection (la réalité de l'Internet d'aujourd'hui) et où tout gain en sécurité, même imparfait, est une amélioration par rapport à cet état de base. Avec la sécurité opportuniste, on chiffre quand c'est possible et on authentifie quand on peut. « Opportuniste » est donc un terme positif dans ce RFC. Il repose sur l'idée d'un « plancher de sécurité » en dessous duquel on ne descendra pas, et du « au moins aussi sûr » où on déploie tout système (comme le chiffrement) qui va améliorer les choses, ou en tout cas ne jamais les dégrader. Ce nouveau modèle ne change rien au cas où l'on imposait une sécurité minimale (par exemple avec HSTS, RFC 6797), il concerne les communications qui se font actuellement en clair.

La section 3 de notre RFC définit ce qu'est la sécurité opportuniste. Elle a (en simplifiant) trois niveaux, le niveau de base, où tout est en clair (c'est la majorité du trafic Internet aujourd'hui), le niveau où on chiffre, mais sans authentifier, et le niveau le plus sûr, où on chiffre après authentification. Ce dernier niveau est le meilleur mais la devise de la sécurité opportuniste est « mieux vaut le deuxième niveau que de rester bêtement sans sécurité du tout ». (Ce modèle est simplifié car il peut y avoir plusieurs niveaux de chiffrement ; par exemple, on va essayer de chiffrer en mode PFS mais, si cela échoue, on chiffre quand même, dans un mode moins sûr.) Ce modèle de sécurité opportuniste repose sur quatre principes :

• Les politiques de sécurité existantes continuent comme avant. Si vous avez mis StrictHostKeyChecking yes dans la configuration d'OpenSSH, la sécurité opportuniste ne vous concerne pas, OpenSSH imposera une authentification de toutes les machines, même la première fois que vous vous connectez.
• Priorité à la communication. En cas de problème d'authentification, on considère qu'il vaut mieux continuer de manière non sûre plutôt que de renoncer (c'est de fait la politique de nombreux utilisateurs).
• S'adapter au pair et donc utiliser, pour chaque couple de machines qui communiquent, la sécurité maximale possible pour ce couple. Si un pair ne parle que DES, c'est nul, mais on l'utilise quand même, sans pour autant descendre le niveau de sécurité de la communication avec les autres pairs. (Il existe plusieurs méthodes pour déterminer les capacités du pair, certaines dans la session elle-même, comme la négociation des algorithmes de chiffrement dans TLS, d'autres externes, comme DANE.)
• Franchise. Dans les messages aux utilisateurs, ou dans les journaux, on ne prétend pas qu'on a obtenu un niveau de sécurité qui ne correspond pas à la réalité. Si on n'a pas pu authentifier, on le dit (cela va poser d'intéressants problèmes d'interface utilisateur...)

La section 4 du RFC illustre le concept de sécurité opportuniste avec SMTP (domaine de compétence principal de l'auteur). Une extension à SMTP, STARTTLS, normalisée dans le RFC 3207, permet d'utiliser TLS pour chiffrer la session. Elle est aujourd'hui largement déployée, par exemple par Facebook ou par Google. À noter que cette extension n'est pas protégée cryptographiquement, et donc vulnérable aux attaques par repli (downgrade attacks) où l'attaquant actif va essayer de faire croire qu'un des pairs ne gère pas la sécurité maximale, menant à l'emploi de solutions de sécurité inférieures (ces attaques, un des points faibles de la sécurité opportuniste, sont traitées également dans la section 6). STARTTLS ne protège donc guère contre un attaquant actif. Donc, utiliser le texte en clair lorsqu'il y a un problème TLS (mauvais certificat, par exemple, ce qui est très fréquent avec SMTP sur TLS) n'a guère de sens : de toute manière, un attaquant actif pourrait supprimer le STARTTLS. Bref, SMTP ne devrait pas se rabattre sur le texte en clair alors que du chiffrement sans authentification est possible.

Ne manquez pas également de lire la section 6, qui résume le problème de sécurité, et qui note que la sécurité opportuniste peut aussi aider contre des attaquants ayant de grands moyens, genre NSA (RFC 7258), en les obligeant à utiliser des attaques actives (comme les attaques QUANTUM).