Je suis en train de rajouter de l’onion routing à mon moteur de recherche MySearch. Je me suis donc penché sur comment Twisted (13.2) gérait les connexions SSL.
Tout d’abord, il faut savoir qu’une connexion web HTTPS dans Twisted ne fait aucune vérification de certificat par défaut. C’est écrit dans la doc et dans l’API.
Enfin « par défaut », il faut comprendre « sans mettre les mains dans le cambouis ». Car quand on regarde plus en profondeur dans le code de Twisted, on voit que les connexions SSL reposent sur PyOpenSSL , qui est comme vous vous en doutez un binding pour la fameuse librairie OpenSSL.
Dans Twisted, voici ce qu’on trouve de plus exhaustif pour vérifier la sécurité de sa connexion SSL. Là, le premier truc qui choque, c’est que le hostname de destination n’apparaît pas dans le code de vérification des certificats.
On se dit qu’on loupe quelque chose, on va voir du coté de la doc de PyOpenSSL . Pareil, pas de fonction qui vérifie la correspondance du hostname demandé avec le certificat présenté. Et pas un mot sur le sujet.
Allons donc voir ce qu’en dit OpenSSL. Et là c’est beau, je vous le donne en mille :
One very common mistake made by users of OpenSSL is to assume that OpenSSL will validate the hostname in the server’s certificate. Currently, it does not, although a future version (1.1.0?) will include this functionality.
C’est écrit noir sur blanc là et là.
Sérieusement, vous pensez qu’il est sain de forcer des programmeurs lambda à coder une fonction si critique qui va vérifier le hostname de destination avec toutes les règles de subject alt name encodées en ASN.1 sans faire le moindre faux positif ni faux négatif ?
Je serai amusé de voir le code de cette partie de quelques applications reposant sur OpenSSL. On risque de trouver des manières élégantes de faire du MITM avec un simple certificat adapté…
Par pur hasard, une nouvelle version de Twisted (14.0) est sortie ces jours-ci. Les notes de mise à jour indiquent de grandes améliorations autour des communications SSL (enfin dirais-je !).
Je vais donc, curieux, voir comment ils se sont sorti de ce piège. Le code de vérification du hostname est en fait externalisé à un module Python externe : service_identity , module créé en mars 2014 (semble t il par des codeurs de Twisted). Ca c’est du code sûr, vérifié et testé… qui prend quand même environ 430 lignes de Python (avec beaucoup de lignes blanches je vous l’accorde).
Voici d’autres exemples du joli cadeau sue nous lègue OpenSSL :
- Code C++ dans le navigateur Chrome (ligne 509)
- Code C++ dans Boost
- Code Python dans le module Python « ssl » (ligne 202) Ajouté à Python 3.2 et déja modifié en 3.3.3