Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

La crypto n'a pas que des avantages

Première rédaction de cet article le 4 octobre 2013
Dernière mise à jour le 14 février 2015


Suite aux révélations du héros Edward Snowden, bien des gens ont pris conscience de ce que tous les experts en sécurité annonçaient depuis longtemps : les services d'espionnage espionnent et ne respectent aucune limite. Notamment, tout le trafic envoyé sur l'Internet peut être écouté, si on ne prend pas de précautions particulières. La solution technique la plus souvent citée est l'usage systématique de la cryptographie. Ce choix est tout à fait justifié. Mais il ne faut pas s'imaginer qu'il va être gratuit : tout chiffrer va faire perdre certaines possibilités, notamment en matière de déboguage.

Cet article a été motivé par une formation où on programmait des accès à un service réseau, via une API qui reposait sur HTTPS. Un moment, on avait un doute sur ce qu'on envoyait, quelqu'un a dit « on va utiliser Wireshark pour examiner ce qu'on envoie vraiment » et paf : à cause du S de HTTPS, la session était entièrement chiffrée par TLS et Wireshark ne pouvait pas aider. Une décision de sécurité parfaitement justifiée (ne permettre l'accès qu'en HTTPS) a fait perdre un remarquable outil de déboguage des applications HTTP.

Bien sûr, compte tenu des révélations de Snowden citées plus haut, il n'y a guère le choix. Même si on n'est pas sûr que la cryptographie protège bien contre un adversaire de la puissance de la NSA, ne pas se protéger serait une folie, puisque la NSA et tous les espions plus petits pourraient alors regarder le contenu du trafic sans problème. Donc, il faut chiffrer. Mais, personnellement, je regrette que les géniaux outils de déboguage réseau comme tcpdump et Wireshark soient de moins en moins utiles à cause du « tout chiffrement ».

Alors, certains et certaines vont me dire « mais il existe des outils qui savent déchiffrer le trafic chiffré, si on leur fournit la(les) clés privée(s), par exemple Wireshark ». Mais ce n'est plus vrai non plus. Voyons d'abord les outils disponibles :

  • tcpdump ne sait déchiffrer que l'IPsec, protocole peu utilisé.
  • ssldump sait déchiffrer le TLS (autrefois nommé SSL).
  • Wireshark sait déchiffrer le TLS.
  • Aucun ne sait déchiffrer le SSH.

Naturellement, ssldump et Wireshark vont avoir besoin de la clé privée du serveur pour cela (autrement, TLS ne servirait à rien). Si on utilise ssldump sans cette clé privée, on voit la négociation TLS :

% ssldump -d -r /tmp/tls.pcap
...
1 1  0.2319 (0.2319)  C>S  Handshake
      ClientHello
        Version 3.1 
        cipher suites
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA
...
1 2  0.4557 (0.2238)  S>C  Handshake
      ServerHello
        Version 3.1 

Mais plus rien ensuite :

...
1 11 0.8215 (0.0110)  C>S  application_data
1 12 1.6280 (0.8065)  S>C  application_data
1 13 1.6845 (0.0564)  S>C  application_data
1 14 1.6993 (0.0148)  S>C  application_data
...

(Notez quand même que la négociation TLS se passe en clair, ce qui peut donner des informations à un espion.)

Si on copie la clé privée server.key sur le serveur TLS et qu'on permet à ssldump de s'en servir :

% ssldump -d -k server.key -r /tmp/tls.pcap

On ne récupère rien de plus ! C'est encore par la faute de la NSA. Celle-ci stocke apparemment les communications chiffrées sur ses disques durs, dans l'espoir de pouvoir les déchiffrer plus tard, soit par les progrès de la cryptanalyse, soit simplement en obtenant la clé privée (par espionnage, injonction d'un tribunal, etc). Les sessions TLS sont donc vulnérables à ces attaques du futur, ce qui a mené au concept de PFS (Perfect Forward Secrecy). La PFS est la propriété comme quoi un attaquant qui a copié la session et qui a obtenu la clé privée ne pourra quand même pas déchiffrer le message. Elle est mise en œuvre dans TLS via des algorithmes comme ceux dont le nom contient DHE (Diffie-Hellman éphémère), comme le TLS_DHE_RSA_WITH_AES_128_CBC_SHA de l'exemple plus haut. Avec cette procédure DHE, les deux parties (le client et le serveur TLS) se mettent d'accord sur des clés qui ne sont pas transmises et donc pas conservées dans les enregistrements de trafic. (Les autres algorithmes sont souvent nommés « RSA statique ». Avec eux, une clé de session est générée et envoyée, après chiffrement RSA, au pair. Elle sera donc accessible dans le trafic capturé.) Ainsi, ssldump et Wireshark ne peuvent rien faire (Wireshark affiche piteusement « Entire conversation (0 bytes) »). Les mises en œuvre modernes de TLS choisissent souvent ces algorithmes et, si vous avez du TLS récent et que vous n'avez pas changé la configuration, vous avez souvent du PFS par défaut... et donc pas de déboguage possible. Vous voyez en général qu'on a le PFS lorsque la négociation TLS comprend un ServerKeyExchange (section 7.4.3 du RFC 5246). Avec ssldump :

1 4  0.4582 (0.0025)  S>C  Handshake
      ServerKeyExchange

Au fait, pour comparaison, une session TLS où on n'a pas employé la PFS, le serveur ne la gérant pas :

...
1 8  0.7662 (0.1631)  S>C  ChangeCipherSpec
1 9  0.7664 (0.0002)  S>C  Handshake
      Finished
1 10 0.7762 (0.0097)  C>S  application_data
    ---------------------------------------------------------------
    GET / HTTP/1.0
    Host: www.example.net
    Accept: text/html, text/plain, text/css, text/sgml, */*;q=0.01
    Accept-Encoding: gzip, compress, bzip2
    Accept-Language: en
    User-Agent: Lynx/2.8.8dev.15 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/2.12.20
...

Cette fois, ssldump peut déchiffrer la communication en HTTP. Ne tentez pas cela avec le paquetage ssldump de Debian, il a une bogue énorme et jamais réparée, qui fait qu'on ne peut pas l'utiliser pour déchiffrer.

Donc, une nouvelle fois, la sécurité n'a pas été gratuite. La PFS est indispensable contre les attaquants modernes, mais elle fait perdre la possibilité d'utiliser les outils de déboguage avec déchiffrement. Le caractère très ouvert et très visible de l'Internet, qui m'avait tant facilité la vie lorsque j'avais appris TCP/IP avec un sniffer, en a pris un coup.

Des bonnes lectures :

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)