let TLS_Implementation = OCamL

Lorsque nous expliquerons à nos enfants qu’au début des années 2000 il n’était pas rare de relever ses mails au travers de flux sans chiffrement, ils nous regarderont avec un mélange d’incrédulité et de dédain. Nous sommes certainement la dernière génération à associer dans un réflexe pavlovien protocoles de messagerie à “ports TCP 110 et 143”. Certains de mes jeunes collègues ne savent même pas à quoi correspond le port 23.

Pour le plus grand malheur des administrateurs systèmes et réseaux les protocoles non chiffrés sont sur le point de disparaître.

Ç’en est fini des “tcpdump -s 0”, “wireshark” et autres “ngrep” pour débugger ce qui cloche entre un client et un serveur. Remplacer une analyse du flux par un “strace” sur les processus client et serveur risque de dégrader le game play…

Et puis non seulement le débogage va devenir un peu plus touchy, mais l’ajout de mécanismes cryptographiques va rendre la configuration parfois beaucoup plus complexe. Vous rechigniez déjà à modifier et débugger votre serveur DNS ? Adoptez DNSSEC pour voir...

L’usage du chiffrement dégrade également fortement les performances. L’initialisation d’une session TCP semblait trop longue pour un protocole interactif comme HTTP, ce n’est rien à côté d’un handshake TLS. Essayez un “ab” vers une page statique en utilisant ou pas TLS et vous verrez l’ampleur du problème. Je vous invite d’ailleurs à lire le billet du concepteur de “varnish”, le reverse proxy haute performance, expliquant pourquoi il n’implémentera pas TLS [1]. Pourtant, avec le renforcement de la sécurité au niveau des navigateurs interdisant progressivement le chargement de contenus en clair sur une page chiffrée [2], il va falloir sérieusement se pencher sur les performances des objets statiques servis en HTTPS.

Si passer votre webmail en HTTPS protège vos utilisateurs lorsqu’ils lisent leurs messages depuis le hotspot d’un McDo, votre UTM^W “Next-Generation Firewall” risque de devenir assez peu regardant sur le trafic vers vos serveurs web. Ceci à moins de désencapsuler le trafic TLS au niveau des équipements de sécurité avec les problèmes de configurations et de performances que cela peut induire... Aux considérations purement techniques, s’ajoutent les problèmes éthiques, voire la susceptibilité de Google [3], si vous voulez inspecter la navigation de vos utilisateurs. Votre proxy web avec ses listes d’URL et son antivirus vont pouvoir reposer en paix.

Enfin, cerise sur le gâteau, la bibliothèque sur laquelle s’appuie la quasi-totalité des applications serveur n’est autre que la tristement célèbre OpenSSL. Dans vingt ans, le soir d’Halloween, on effraiera les enfants en leur racontant comment OpenSSL gérait sa mémoire. Essayez de lister les dépendances d’Apache, nginx, Postfix, Cyrus, Dovecot, VsFTPd, OpenSSH sur votre distribution préférée et vous vous rendrez compte du succès tout relatif de GnuTLS (qui a aussi son lot de casseroles). Heureusement, la communauté a vigoureusement réagi en sortant de nouveaux forks en pagaille : LibreSSL [4] soutenu par OpenBSD, BoringSSL [5] chez Google et une implémentation en OcamL [6] que l’ANSSI va certainement adorer. Pendant ce temps-là, OpenSSL, recevait 840 dollars de dons [7]. Royal !

Bonne lecture !

Cedric Foll
@follc
@MISCRedac

[1] https://www.varnish-cache.org/docs/3.0/phk/ssl.html
[2] https://developer.mozilla.org/en-US/docs/Security/MixedContent
[3] http://www.zdnet.fr/actualites/des-faux-certificats-de-l-anssi-detectes-et-bloques-par-google-39796159.htm
[4] http://www.libressl.org/
[5] A priori ce n’est pas une blague : https://www.imperialviolet.org/2014/06/20/boringssl.html
[6] https://github.com/mirleft/ocaml-tls
[7] http://www.hsc-news.com/archives/2014/000118.html

Au sommaire de ce numéro :

Exploit corner

p.04 MS14-012, « Operation SnowMan »

Pentest corner

p.10 Extraire le code assembleur d'un système embarqué en analysant le courant consommé : possible ?

Malware corner

p.20 Analyse du malware Tuscas

Dossier : Les objets connectés : De nouveaux usages partout, la sécurité nulle part ?

p.28 Préambule
p.29 Quelques enjeux de l’Internet des Objets
p.34 Télévisions connectées : des objets branchés sécurité ?
p.44 Les défis de sécurité de l'internet des objets pour le B2B et B2C
p.52 La médecine connectée : les implications juridiques et éthiques derrière une révolution scientifique

Système

p.58 La sécurité des SAN (partie 1)

Science & technologie

p.70 Surveillance généralisée : aux limites de PGP

Société

p.77 Threat Intelligence is a box of cookies