Le 30 mars 2012 s’est tenu à la cantine,  un barcamp consacré à la sécurité et la vie privée sur internet, auquel votre serviteur a participé.  N’en déplaise à certains qui trouvent le lieu trop ‘institutionnalisé’, la cantine est un endroit que j’apprécie particulièrement, de par sa situation exceptionnelle au cœur du passage des panoramas, mais surtout à cause des gens très intéressants qu’on y rencontre en général.

Cette fois le sujet était donc à la vie privée sur internet, sujet ô combien digne d’intérêt, surtout par les temps qui courent.. L’événement était organisé par La cantine, OWNI, Mozilla et…la CNIL ! Non vous ne rêvez pas, ils font des trucs à la CNIL, et même qu’ils commencent à s’intéresser la société civile  ( La fin est proche, i’vous le dis  moi ! ) Malheureusement n’ayant pas pu me libérer, je suis arrivé 2 bonnes heures après le début. Donc ne pouvant être exhaustif sur l’événement, je m’en vais vous la faire un peu en mode gonzo   .

Après 5 bonnes minutes passées à déambuler dans le dédale du passage ( ça m’arrive à chaque fois) et m’être incrusté malgré moi chez Bearstech,  j’arrive sur place. L’ambiance est studieuse et les gens sont scindés en groupes d’une dizaine de personnes, répartis dans tous les coins et à l’étage. Le fond est quant à lui plus animé: Le rétro principal projette en grand l’application spyfiles crée par OWNI, sans doute suite à une présentation de Jean-Marc Manach sur le sujet. L’auditoire est en train d’écouter avec attention un ingénieur en sécurité qui a reversé différents types de cartes à puce et pu y extraire nombre d’informations. Je prend la discussion à la fin, trouve cela intéressant et surtout relativement inquiétant..fin du round de groupes de travail en cours !

Comme le veut le principe d’un barcamp, un rapporteur appartenant à chaque groupe de travail vient faire un résumé de ce qui s’est dit à l’assemblée. Ça parle de de technologie d’identification WebID, des implications du model gratuit dans l’exploitation des données privées, ou encore de la façon de gérer sa réputation en ligne.  Un mot revient souvent dans les rapports qui sont faits et dans les discussions: syngergie. Le besoin se fait sentir de créer des groupes d’intérêts communs et d’agir réellement de concert pour protéger la vie privée des internautes. Ding Ding ! le dernier round du barcamp va commencer. Les sujets à discuter sont de mémoire: De la bonne gestion d’identités multiples sur internet et en particulier pour les activistes, Hacking de la CNIL, la protection de la vie privée sur téléphones Androïd et les outils d’anonymisation sur Internet.

J’opterais finalement pour ce dernier avec quelques infos intéressantes à la clé. Il s’agissait avant tout de présenter quelques outils pour ne pas laisser de trace sur internet, en sécurisant les échanges et en anonymisant le contenu. On démarre sans préchauffage,  celui qui présente commence cache et lâche un bon troll velu sur la sécurité vacillante  et les problèmes de privacy chez les utilisateurs de produits Apple (qui devaient représenter +de 50% de l’assemblée). On y passe une minute ou deux, on se marre un coup, puis on passe aux outils. Outre le légendaire TOR , la distribution live tails est présentée; celle-ci facilite la prise en main de différents outils d’anonymisation en les intégrant de façon cohérente. On discute des avantages et inconvénients des différents outils, tant du point de vue technique pur que de l’utilisateur. On en vient à parler d’un autre outil qui éveillera ma curiosité : MAT, pour « Metadata Anonymisation Toolkit » : Celui-ci permet de stripper les méta-données de différents documents ( la liste des formats supportés est déjà correcte ) afin de ne conserver aucune trace de son propriétaire ou créateur d’origine. C’est un must-have, par exemple pour les whistleblowers désirant poster des documents sans qu’on ne puisse remonter jusqu’à leur source. La personne qui dirige le groupe m’indique que l’outil est encore en phase de développement intensif et aurait besoins de bras. Je me dis que ça pourrait être une bonne idée, avant de me remémorer mon schedule et de me mettre à pleurer dans mon fort intérieur .

Fin du compte à rebours, les pizzas sont arrivées avec un timing d’horloger suisse. On se chamaille pour savoir qui sera le rapporteur du groupe de travail, personne ne veut le faire et finalement c’est Nitot qui s’y colle. Chaque rapporteur passe,  On boucle les reports de workshops, puis finalement on se met a l’aise entre amis.  On picole, on papote, et on mange de la pizza en refaisant le monde. On saute du coq à l’âne, parlant tant-tôt de stratégie Martiale, de la place de la confiance dans les mécanismes de sécurité, des réseaux sociaux distribués ou encore de l’obsolescence des politiques face à l’horizontalisation rampante de la société façonnée par Internet. l’horloge s’emballe , c’est toujours le cas lorsque la conversation est stimulante. Il va falloir rentrer..Avant de partir je vais faire un tour aux commodités, et avant de sortir je fixe durant un long moment le sèche-main bardé de stickers qui se trouve devant moi..me vient alors une épiphanie durant laquelle je me dit que finalement,  je suis parfaitement à ma place dans cette partie de l’espace et du temps…

Références, Liens:

Page barcamp de l’évenement: http://barcamp.org/w/page/51552255/PrivacyCampParis => vous y trouverez les PADs sur lesquels se trouvent les résumés des différents groupes de travail.

Page la cantine: http://lacantine.org/events/privacycamp-paris

Crédit photo: Tristan Nitot

Suite et fin de notre petit tour d’horizon sur la capture de flux réseau chiffrés par SSL/TLS, nous allons voir ici 2 autres méthodes qui marchent également pas trop mal, et pas très difficiles à mettre en œuvre. C’est parti

Méthode 2:  ltrace

Le but ici va être d’intercepter les flux AVANT ( pour l’envoi) ou APRES (pour la réception) leur passage par la couche SSL, mais cette fois nous allons le faire directement au cœur des applications. ltrace est l’un de ces programmes qui fait partie des outils essentiels au développeur pour debugger ses applications. Il permet, lorsqu’on l’attache à un processus, de retracer les appels de librairies externes effectués par ce même processus, et afficher ces appels. En général ltrace s’utilise comme suit:

#ltrace --library=/chemin/vers/librairie.so -e appel_1,appel_2,..,appel_n programme args

Maintenant que nous avons expliqué ce que faisait grosso-modo ltrace, faisons un bref rappel de comment SSL s’intègre au sein d’un programme. Comme son nom ne l’indique pas, SSL n’est pas une socket au sens ou nous l’entendons, mais est un layer supplémentaire au dessus d’une socket standard. En d’autres termes, lorsque vous écrivez un programme qui utilise  SSL, l’envoi et la réception des flux sur le réseau n’est pas délégué à la librairie SSL mais reste sous le giron de la socket réseau définie au départ.

on a donc les schémas suivant à l’intérieur de notre programme:

Pour l’ envoi:

Pour la réception:

Pour capturer les flux pré-chiffrement/post-déchiffrement de notre programme(les flux cleartext sur les schémas du haut), nous allons devoir chercher les appels externes à une librarie SSL au sein de celui-ci. Les deux librairies les plus utilisées pour la gestion de SSL étant OpenSSL et GnuTLS, nous allons donc regarder si le programme que nous cherchons a analyser fait appel à l’une de ces deux librairies.

A noter que le choix de l’implémentation est souvent subordonné à des problèmes de licence ( GnuTLS, publiée sous GPL, convient aux programmes édités sous cette même licence, tandis que OpenSSL, publiée sous licence BSD, convient à tous )

Le meilleur moyen de savoir quelle implémentation SSL votre programme utilise est d’utiliser l’outil ldd. Celui ci va vous retourner l’ensemble des librairies dynamiques utilisées par le binaire qui lui est passé en argument. prenons le cas de wget:

#ldd /usr/bin/wget

linux-gate.so.1 => (0×00765000)
libssl.so.0.9.8 => /lib/libssl.so.0.9.8 (0x00eb6000)
libcrypto.so.0.9.8 => /lib/i686/cmov/libcrypto.so.0.9.8 (0×00110000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x006dd000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x006e4000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00d43000)
libz.so.1 => /lib/libz.so.1 (0×00262000)
/lib/ld-linux.so.2 (0x00a5c000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x002af000)

ldd nous retourne libssl.so.0.9.8: Bingo! Notre programme utilise bien la librairie OpenSSL.Note: les programmes utilisant GnuTLS sont quand à eux linkés avec la librairie « libgnutls ».

Une fois que nous avons ces informations, il nous faut connaître les opérations d’entrées/sorties principales de l’implémentation TLS utilisée dans notre programme à écouter.

Pour OpenSSL par exemple, nous avons SSL_read , SSL_write , BIO_read, BIO_write.

Ok allons y: cherchons ces appels de fonction au sein d’un programme, puis regardons ce qu’on a. Nous utiliserons de nouveau wget, et nous lui demanderons de fetcher une page https:

# ltrace --library=/lib/libssl.so.0.9.8 -e SSL_read,SSL_write,BIO_read,BIO_write wget https://monsite.ssl_enabled.tld

>SSL_write(0x81ad2a0, 0xbfb15bf0, 115, 2, 0x81ad900)
>SSL_read(0x81ad2a0, 0x81c0920, 175, 0x80782e2, 512)
>SSL_read(0x81ad2a0, 0x809efa0, 16384, 0, 0x465f7266)
>SSL_read(0x81ad2a0, 0x809efa0, 16384, 0, 0xbfb15c08)
>SSL_read(0x81ad2a0, 0x809efa0, 16384, 0, 0xbfb15c08)
>SSL_read(0x81ad2a0, 0x809efa0, 16384, 0, 0xbfb15c08)

Ah, il semblerait que nous ayons un petit problème: Les informations ne nous apparaissent pas en clair, et en lieu et place des données tant espérées, nous nous retrouvons avec des adresses mémoire..

pourquoi tant de haine ?

lorsqu’on regarde la signature des fonction SSL, on a:

int SSL_read(SSL *ssl, void *buf, int num);
int SSL_write(SSL *ssl, const void *buf, int num);

Nous y sommes, le problème vient du fait que ltrace est incapable de déréferencer les pointeurs de type void* pour les appels non système, même lorsque leur taille est indiquée dans la variable juste après (int num)

comment s’en sortir ?

Le fait est que nous sommes pratiquement sur qu’à un moment ou à un autre,
ces tampons mémoire seront utilisés au sein d’appels système, avant ou après leur passage dans les fonctions SSL. Nous allons donc chercher les appels système en périphérie des appels SSL, car pour ceux-là ltrace sera capable de déréférencer les arguments.
Essayons quelque chose:

# ltrace -S -s4096 --library=/lib/libssl.so.0.9.8 -e SSL_read,SSL_write,BIO_read,BIO_write wget https://monsite.ssl_enabled.tld

Nous avons ajouté le flag -S, qui fait en sorte que ltrace puisse également tracer nos appels système..alors,qu’avons nous la ?

…
SSL_read(0x91472a0, 0x809efa0, 16384, 0x75380b, 0x465f7266 <unfinished …>
SYS_read(3, « \027\003″, 5)                                                                                                       = 5
SYS_read(3, « &sL\330|\302′\217\223\201\033\343\364]N\333\251BN|\332\026\210\214\024\331\223/\241\223~\014V\017m?H\206\374\206\036\332PC\301\333y\031\224\240\215\005\270\311C\234K@w\t\355\003\036>’\344X\372-a}\231\026\311\362N\202\304by\266/]_#\177\334T=\277\364\033\272*I\366P\352{\275\3611\344\b\306p\251\016}\303\020\212)\316\274\031{\345\220acSAjU\367\037\024\303Nr\377l\304E\n\246!\322]\036\222~5\342\031d6\276\317\213T\027\355c\033;@\252l\003JL\343@-r\200\365\217%\210E\215\252)\020\366\266@;\225%\312\345\035\300\2724\006O\243\356s\226+\216\333\313\244+v \335\317\207b\224Gf\333z\342o\244\204\361\27046;\014\354\252f\255Q\247\220b\034]\005\255\205)\377\221\215\334s\306k\324\215\213c\274\244\263\b\215g\340\275t\215\030^\246\263>EE\267\n\267LT\2060\016/kx\233\003\216″, 1404) = 1404
<… SSL_read resumed> )                                                                                                         = 4255
SYS_265(1, 0xbf8191f8, 0x117ff4, 0x91457e0, 0×9145918)                                                                           = 0
SYS_write(4, « \n\n\n<!DOCTYPE HTML>\n<html>\n<head>\n\n\n  <META http-equiv= »Content-Type » Content= »text/html;…

et ba voilà ! Une fois le stream SSL déchiffré via SSL_read, celui-ci est bien sur manipulé et repasse donc dans un syscall SYS_write. Avec un peu de patience, cette méthode peut vous permettre de reconstituer les flux SSL de vos applications pour éventuellement reverser leur protocole de communication.

Méthode 3: socat style, the ultimate way

C’est personnellement la méthode que je préfère, car elle est simple et surtout n’impose presque aucune contrainte hormis celle de pouvoir désactiver la couche SSL sur l’une des terminaisons. Si vous pouvez faire ça, et que vous n’avez pas besoin de récupérer les informations d’enveloppes ( arp/ip/tcp|udp) , alors cette solution est faite pour vous.

socat ( disponible dans tout bon système de packages) est un programme fort sympathique qui a la capacité de créer des canaux de communication bidirectionnels entre différents descripteurs de fichiers, fussent-ils des sockets,  des flux d’I/O d’applications ( stdin/stdout/stderr ), des fichiers ouverts…et Cerise sur le gâteau, socat gère également les flux SSL !! Le but ici est de déléguer le layer SSL à socat, sur une des extrémités du flux. La communication apparaitra alors comme par magie, en clair, sur la sortie standard de socat, et pourra être redirigée dans un fichier au besoin.

Nous aurons alors:

ou:

Notez que dans ce cas, socat aura besoin des certificats et clés (root cert, cert et clé du cert) utilisés par l’application serveur en temps normal, lorsque le flux lui arrive directement chiffré.

Exemple 1: couche SSL déléguée coté client. Nous allons établir une liaison en branchant une socket qui écoute en local sur tcp/80, à une autre socket qui elle sera connectée à un serveur Web distant par SSL.

Dans un terminal (en root, parce que les port < 1024 ne sont normalement bindables que par root) , taper:

socat TCP-LISTEN:80 OPENSSL:mon_site_https:443,verify=0

Note 1: l’option « verify=0″ permet de à socat de bypasser les contrôles de certificats. On pourrait le mettre à 1 mais dans ce cas il faudrait lui fournir les root CA qui vont bien ( verisign, ipsca,diginotar…oh Wait ! )

Note 2: On pourrait également utiliser la commande suivante:

socat TCP-LISTEN:80 EXEC:'openssl s_client -connect mon_site_https:443'

mais la première solution est plus élégante car elle se passe du binaire OpenSSL.

Le moment de vérité:

Maintenant que notre socat est prêt, nous allons faire une requête http sur notre socket local bindée sur le port 80, dans un autre terminal:

telnet 0 80
GET http://mon_site_https HTTP/1.0

( oui je sais, c’est bas, mais ne dit-on pas que feignantise est mère de toutes les vertues ? )

Et là oh miracle ! socat affiche le flux totalement clair sur sa sortie standard, n’est ce-pas magnifique ? Alors biensur, l’exemple n’a pas grand intérêt parce que votre navigateur sait aussi vous recracher le contenu en clair…mais le concept est applicable à n’importe quel flux SSL et le flux est ensuite redirigeable vers n’importe ou, et c’est ça qui est important !

Exemple 2: couche SSL déléguée coté serveur. Nous allons à nouveau établir une liaison en branchant une socket qui écoute en local sur tcp/80, à une autre socket qui elle sera connectée à un serveur Web distant par SSL.

socat OPENSSL-LISTEN:443,cafile=mon_fichier_ca,certificate= \
mon_certificat,key=mon_fichier_clé,fork TCP:localhost:80

Expliquons un peu cette ligne: les options cafile, certificate et key sont les parametres de de certificat et de clé , comme dans n’importe quel service SSL. cafile etant le fichier de certificat racine de l’autorité , certificate le fichier de certificat du serveur, signé par l’autorité, et key, la clé privée du serveur, pair de la clé publique qui est fourni avec le certificat du serveur. L’option fork permet, (vu que nous sommes en mode listen) , de dupliquer le processus afin pourvoir rouvrir d’autres sockets dessus ultérieurement.

Voilà, je crois avoir à peu près fait le tour de la question. Évidemment, ce howto est loin d’être exhaustif et il existe encore moult solutions pour pouvoir capturer du trafic SSL/TLS en clair depuis sa station de travail ou son serveur, dont certains outils qui sont spécialement dédiés à ça. Cela dit, je pense vous avoir donné les premières clés pour pouvoir reluquer tranquillement sous les jupes de vos applications et protocoles préférés utilisant le chiffrement SSL .

Liens connexes:

RFC TLS: http://tools.ietf.org/html/rfc5246

OpenSSL API Réference: http://www.openssl.org/docs/ssl/ssl.html

GnuTLS API Réference: http://www.gnu.org/software/gnutls/reference/

GnuTLS, couche de compatibilité OpenSSL source-level : http://www.gnu.org/software/gnutls/reference/gnutls-openssl.html

Page Wikipedia sur RSA: http://fr.wikipedia.org/wiki/Rivest_Shamir_Adleman

Aujourd’hui je vais proposer un sujet un petit peu technique, histoire de coller à la thématique du blog .J’avais prévu au départ d’écrire ce billet d’une traite, puis le contenu s’allongeant au fil de l’écriture, j’ai finalement décidé de traiter le sujet en 2 parties, pour ne pas trop alourdir le tout et conserver un format billet. Ok, c’est parti mon kiki !

Si il est courant de vouloir extraire du trafic réseau à des fins de troubleshooting par exemple, l’opération peut sembler moins évidente lorsqu’il s’agit de flux chiffrés. A vrai dire cela n’a pas grande importance si les informations que l’on recherche se trouvent dans les enveloppes, mais il vous faudra utiliser un « la ruse » (le truc que le barbare déteste ) si ce que vous cherchez se trouve dans le payload.

Comme le titre de ce billet l’indique clairement,  nous ne parlons pas ici d’attaques MITM ,mais nous nous proposons simplement de regarder des flux chiffrés sur lesquels nous avons de l’emprise (nous sommes ici Alice ou Bob ).  Aussi pour décrire la couche de chiffrement, nous emploierons indistinctement les termes SSL et TLS, le premier étant l’ancien nom du second. Ne soyez donc pas surpris si vous voyez l’un ou l’autre terme dans l’article.

Nous parlerons de 3 méthodes, plus ou moins faciles à mettre en œuvre, dont certaines ont leur utilité dans des cas précis.  Aussi Il faut savoir que ce howto ( comme tous les autres à suivre ) , a été conçu pour être mis en pratique avec les systèmes GNU/Linux. Toutefois celui-ci est parfaitement reproductible sur les systèmes *BSD, et Windows au prix de quelques modifications.

Banalités sur SSL :

SSL/TLS est le système de sécurisation des communications réseau probablement le plus utilisé sur internet. Utilisé par exemple pour les solutions de payement en ligne et de nombreux autres systèmes nécessitant la confidentialité des échanges, Il repose sur un ensemble d’algorithmes de chiffrement asymétriques ET symétriques, ainsi que sur l’utilisation de certificats signés par un tiers de confiance pour l’authentification des parties ( certificats qu’on éludera dans la mesure du possible dans cet article, car ce n’est pas le propos )

Aussi contrairement a une idée qui a la peau dure, les échanges cryptographiques d’une session SSL se font principalement au travers d’algorithmes de chiffrement symétriques ( Blowfish, CAST, CAST5,DES, triple-DES,….) et ce pour une raison simple: Pour réduire la latence  induite par la couche de chiffrement. Les algorithmes de chiffrement asymétriques comme RSA sont plus gourmand  en ressources. Par conséquent les utiliser sur l’ensemble d’une session SSL augmenterait considérablement la puissance requise sur les équipements et ordinateurs sensés traiter ce genre de flux. Le choix de l’algorithme (« ciphersuite ») à utiliser se fait selon les capacités du client, les 2 parties se mettant d’accord sur l’algorithme lors des échanges ClientHello/ServerHello (voir schéma « négociation d’une Session SSL ») .

Alors, quand SSL utilise-il le chiffrement asymétrique ?

Pendant la négociation de la session. En simplifiant, le client va récupérer la clé publique du serveur, puis va générer un nombre aléatoire appelé « premaster secret ».

Celui-ci va ensuite envoyer le premaster secret au serveur, en le chiffrant avec la clé publique qu’il vient de récupérer ( c’est l’étape ClientKeyExchange, voir schéma « négociation d’une Session SSL ») .

Le serveur va donc récupérer le premaster secret dans sa version chiffrée, puis va le déchiffrer avec sa clé privée.

A partir de là, client et serveur vont tous deux dériver le premaster secret pour aboutir à un même résultat des deux cotés: ce sera la clé utilisée plus tard pour les échanges chiffrés de façon symétrique ( AES, RC4, etc..).

Note: Si vous souhaitez avoir plus de détails, je vous invite à consulter la section des liens connexes, les pages sur TLS/SSL.

Négociation d’une session SSL:

Ok, maintenant passons à la pratique:

Méthode 1:  utuliser directement un logiciel de capture de trames: le cas de wireshark / tshark.

Wireshark est un outil diabolique, que tous les ingénieurs réseau et autres experts en sécurité connaissent. la methode proposée ici se base sur la capacité qu’a wireshark à interpreter ( entre autres, yen a beaucoup en fait ) les flux SSL encapsulés dans les trames Ethernet qu’il capture .Toutefois, cette méthode nécessite de réunir deux conditions:

La première est que l’on doit disposer de la clé privée du serveur vers lequel on tente d’établir la session SSL, et la seconde est que l’échange de clés doit se faire suivant l’algorithme RSA (ne fonctionne pas, par exemple avec un échange de secret Diffie-Hellman). Si on lui donne la clé privée du serveur SSL avec qui l’on va négocier la session, wireshark sera capable de déchiffrer la couche SSL et donc d’afficher les données en clair au sein des trames \o/.

Pour arriver à faire cela, votre version de wireshark doit être linkée avec la librairie GnuTLS. Pour s’en assurer, tapez dans un terminal:

# wireshark -v|grep -oi gnutls
 
ou
 
# ldd /usr/bin/wireshark |grep  gnutls

Si la commande vous renvoie la chaine « GnuTLS » (ou libgnutls.so.X dans le second cas), alors c’est que notre wireshark supporte bien le déchiffrement des flux SSL.

Pourquoi ai-je besoin de la clé privée ? : Parce que wireshark capture ses données au niveau de la couche la plus basse du système, avant même que le paquet ne soit placé dans un tampon réseau ( sk_buff sous linux ). Par conséquent il n’a aucune idée des clés symétriques entrant en jeu dans les échanges SSL des paquets qu’il capture (celles-ci sont stockées en mémoire des applications client et serveur)  . Pour retrouver ses billes, wireshark va donc utiliser la clé privée du serveur pour avoir accès au Prémaster secret transmis au serveur lors de l’étape ClientKeyExchange ( voir section « Banalités sur SSL » ) .

Format de la clé privée: Wireshark attend des clés privées au format PEM, contenant l’entete:

-----BEGIN RSA PRIVATE KEY-----

Si votre clé est sous un autre format, il faudra sans doute la convertir convertir ( voir http://wiki.wireshark.org/SSL , section « Key FIle Format Conversion » pour plus de détails). Une fois que nous avons notre clé privée de serveur  au bon format, il n’y a plus qu’a mettre en pratique.

Les options wireshark pour le déchiffrement SSL:

Wireshark doit être lancé avec quelques options pour pouvoir faire son oeuvre:

# wireshark -o "ssl.desegment_ssl_records: TRUE" -o "ssl.desegment_ssl_application_data: TRUE" \
-o "ssl.keys_list: serveur_hote,port_serveur,protocole,/chemin/vers/cléprivée.pem"

Nous prendrons bien sur soin de changer les paramètres serveur_hote, port_serveur et protocole suivant la nature du protocole et les paramètres tcp/ip du serveur TLS.

Pour l’exemple nous allons déchiffrer du trafic http encapsulé dans un flux SSL provenant du serveur web qui heberge ABO,mais sur un autre vhost. on aura donc la commande wireshark suivante:

# wireshark -o "ssl.desegment_ssl_records: TRUE" -o "ssl.desegment_ssl_application_data: TRUE" \
-o "ssl.keys_list: 88.191.75.35,443,http,servkey.pem"

Il n’y a ensuite plus qu’a lancer la capture de trame sur la bonne interface avec le filtre qui va bien ( par exemple tcp.port == 443 ) et laisser la magie s’opérer Il faut à présent lancer son navigateur Web préféré, puis interroger notre serveur avec une url en https://

Une fois la négociation de session terminée, wireshark va de lui même déchiffrer le flux SSL et afficher les trames reconstruites:

w00t-w00t !! Affichage d'une trame http reconstruite depuis un flux SSL

Pour voir le contenu entier d’un échange, on peut également faire un click droit sur l’une des trames SSL et utiliser la fonction « Follow SSL stream ». Wireshark popera alors une nouvelle fenêtre qui contient le flux complètement déchiffré..magique !

Fenêtre de suivi de flux SSL dans wireshark

Comme nous l’avons dit plus haut, cette méthode ne fonctionne pas dans tous les cas et requiert de posséder la clé privée du serveur distant, ce qui fait beaucoup de contraintes finalement.. Heureusement d’autres solutions existent, comme récupérer le trafic en amont et en aval de la couche TLS, et  c’est ce à quoi nous allons nous atteler dans le prochain épisode 

Liens connexes:

Page de wireshark sur SSL: http://wiki.wireshark.org/SSL

RFC TLS: http://tools.ietf.org/html/rfc5246

Page Wikipedia sur RSA: http://fr.wikipedia.org/wiki/Rivest_Shamir_Adleman

J’entend dire en ce moment et depuis quelques temps déjà beaucoup de choses, pas toutes vrais sur ce que l’on appel le DPI, ou deep packet inspection. J’aimerais donc par ce modeste billet rétablir un peu les choses , afin d’aborder l’avenir avec lucidité et sérénité.

Le DPI, qu’est ce que c’est ?

Le DPI, acronyme de Deep Packets Inspection ( Pour « inspection des paquets en profondeur » ) , est un principe technique qui consiste à analyser le contenu entier d’un paquet réseau afin de le discriminer par rapport aux autres . Pour résumer simplement, on prend chaque paquet qui transite sur le réseau, et on va l’ouvrir pour regarder ce qu’il y a dedans. Si ce qu’il y a dedans nous plait, on va le laisser continuer sa route jusqu’a sa destination. Sinon, le paquet termine sa course.  Concretement c’est comme si la poste ouvrait votre courrier et decidait de vous le delivrer uniquement si son contenu repond à certains critères ( le caractere légale ou illegale du contenu serait probablement le premier critère )

Le DPI est une chose démoniaque qu’il faut absoluement combattre.

Le DPI n’est en soi ni bon ni mauvais: Ce n’est qu’une solution technologique apres tout . Tout va dépendre, comme dans de nombreux cas,de  la facon dont on va s’en servir. De la meme maniere que l’on peut utiliser un cutter pour découper des carrés de moquette , ou pour égorger des gens…Si il parait tout à fait légitime et meme necessaire de se battre pour que ce genre de systèmes ne servent pas à baffouer la vie privée des gens ni à les censurer, on peut néanmoins estimer que dans certains cas cette technologie peut s’averer utile, par exemple lorsqu’il s’agit de controle parental, pour proteger les enfants du contenu choquant qu’ils pourraient trouver sur le net. La difference est qu’ici nous ne nous trouvons pas dans une logique de censure ni d’infraction au droit à la vie privée, mais plus dans une logique de creer un service d’utilité publique, sous l’impulsion des parents ( qui decident ou non de l’utilisation du filtre, celui-ci n’etant jamais imposé au client )

Une solution applicable tout de suite ou dans un futur très proche.

Parmis toutes les anneries qui m’aient été donné de lire sur le DPI, c’est probalement la plus grosse. Les tenants d’une généralisation de la solution de DPI à tout le trafic internet, ainsi que certains alarmistes  voudraient  bien nous faire croire que c’est le cas …mais en fait il n’en n’est rien.

Admettons une première solution ou le filtrage serait centralisé en un unique point. Une sorte de plateforme ( sous l’autorite de l’Hadopi ?? )  vers laquelle tout le trafic internet « francais » devrait  cheminer pour être « passé aux rayons x », pour ensuite soit être directement rerouté vers sa destination finale, soit retourner dans le cœur de réseau du FAI d’ou provient le trafic.

Alors là permettez moi de vous le dire, on nage en plein delire !!  Non content d’introduire une énorme singularité de panne ( autrement appelée « Single Point Of Failure »),  cette plateforme devrait pouvoir analyser en temps réel plusieurs térabit de trafic par seconde  ( pour l’audience non technique, 1 terabit = 1000 gigabit ). A titre de comparaison, AMS-IX ( Amsterdam) , qui est l’un des plus gros points d’échange mondiaux , gère environ 1 térabit de trafic par seconde en pointe et avec des équipement déjà très performants. Et là on ne parle même pas de filtrage..juste d’acheminer du trafic d’un bout à l’autre du point d’échange…le réseau bête et méchant que l’on connait ( et que l’on souhaiterait conserver aussi du coup ) .  Mais c’est la que ça devient intéressant: Le traitement d’un paquet réseau suivant son contenu plutôt qu’uniquement sur ses entêtes , est 10 à 100 fois plus couteux en temps , suivant la profondeur d’analyse ( facteur 10 à 20 pour L4, facteur 100 pour L7 ). Donc, pour conserver un débit suffisant et ne pas provoquer de goulet d’étranglement sur cette plateforme, il faudrait deployer un réseau plusieures centaines de fois plus puissant que celui d’AMS-IX , et donc empiriquement, plusieures centaines de fois plus couteux !! Aussi je doute que quiconque, gouvernements comme FAIs, ne soit prêt à injecter une quantité si herculéenne de pognon pour une solution qui, ne serait peut-être même pas efficace ( IE chiffrement SSL )

Maintenant si on envisage une solution un peu plus raisonable ou chaque opérateur dispose de son propre dispositif de filtrage en coeur de réseau, on s’apercoit que ca ne tient guerre mieux la route. On se  retrouve face à la  meme problematique que précedement: la quantité demesurée d’equipements necessaires (et donc d’hommes pour la maintenance, de frais de locaux, d’électricité….) pour pouvoir filtrer sans provoquer de bottlenecks sur le réseau.  Pour arriver a faire ce genre de chose il faudrait que chaque Opérateur augmente la puissance de traitement de son backbone d’un facteur d’environ 10 ( et les équiepents de traitement des couches 4-7  coutent extremement cher …à acheter seulement si l’on a pas peur d’y laisser ses couilles ).

l’analyse de contenu est deja en production chez les FAI pour certains flux, on peut donc la generaliser.

Voici encore une belle betise répetée à tort et à travers. Meme si effectivement l’analyse de contenu est déjà en place pour certains services et dans des cas bien particuliers,  nous ne sommes pas ici sur la meme échelle volumetrique, lorsque l’on parle de filtrer l’integralité du trafic !!

Pour moi  il est donc clair que si l’inspection des paquets en profondeur est bel et bien le fantasme absolu de petits dictateurs et autres rapaces de l’industrie culturelle, nous ne sommes pas pret de le voir etre généralisé à l’ensemble du trafic Internet. Aussi m’est avis que si il est necessaire d’alerter l’opinion publique sur les dangers que representent le DPI, il est tout aussi contre-productif de faire paniquer les gens  outre mesure, que de leur cacher la verité.

Tout à l’heure je lisais un article sur Global Sécurity Mag, intitulé « La sécurité, un monde en pleine mutation ». J’aimerais donc discuter rapidement de cet article dans ce billet, car tout naturellement je ne suis pas d’accord avec son contenu

L’article en question reprend un communiqué de presse de Baracuda Networks (fournisseur d’appliances sécurité)  qui dit en substance que la société proposera dorénavant de rémunérer les découvertes de vulnérabilités sur ses produits,  sur un montant grosso-modo proportionnel à la criticité de la vulnérabilité. Évidemment cette rémunération est subordonnée à un « non disclosure agreement » jusqu’a ce que la faille ai été corrigée dans le produit:  C’est un point clé car c’est là que réside tout le vice de cette méthode.

Un phénomène marginal

La première erreur d’analyse de l’auteur vient du fait qu’il a pris l’exemple de Baracuda, l’a corroboré avec quelques autres acteurs plus ou moins importants de l’internet et en a fait une généralité. Or , si effectivement quelques entreprises et organisations commencent à adopter ce genre de pratiques, on est encore loin d’un changement de comportement massif.

Et l’utilisateur dans tout ça ?

Lorsqu’on y réflichit bien, du point de vue de l’utilisateur il n’y a pas grande différence entre un pirate qui fait commerce d’un 0day qu’il a trouvé,  et un chercheur qui  révèle une faille à un éditeur, en échange d’une récompense pécuniaire.  Pourquoi ? Simplement parce qu’en se faisant rémunérer pour sa découverte, le chercheur ne pourra bien sur rien publier sur la faille en question avant sa correction effective, ce qui laisse plein de temps au dit éditeur pour trainer des pieds. Et dans ces conditions, il n’est pas farfelu de penser que la vuln sera redécouverte entre temps par quelqu’un d’autre, qui pour le coup sera beaucoup moins intentionné. Dans ces deux cas, l’utilisateur se retrouve potentiellement vulnérable.

La seule différence notable réside donc ici: En rémunérant les découvertes de vulnérabilité,  Les éditeurs qui peuvent se l’offrir, s’achètent une certaine tranquillité en s’assurant que la vulnérabilité ne se propage pas. Mais pour moi le Full Disclosure reste le seul vrai moyen de pousser les éditeurs à patcher leurs solutions dans un délais suffisamment court…même si l’on peut admettre quelques « dommages collatéraux » , dans le laps de temps ou la vulnérabilité est en cours de correction.

Une solution non pérenne

Maintenant essayons de faire une projection, et d’envisager un monde ou tous les acteurs utilisent cette pratique. Que ce passerait-il ? Le monde de la sécurité informatique, comme tout autre domaine, n’échappant ni à l’économie de marché ni à la loi de l’offre et de la demande, on pourrait assister à une escalade dans la rémunération entre les personnes mal intentionnées à la recherche de 0days ( ie les codeurs de malwares), et les entreprises voulant récupérer les failles de leur produits à des fins légitimes. L’homme étant par défaut enclin à maximiser son profit au détriment de la communauté , je vous laisse imaginer la perversité de la chose…..

Que faut-il faire ?

Selon moi il existe une solution pour limiter les effets de bord d’une telle pratique. Ajouter une close de Full disclosure dans le cas ou l’éditeur n’aurait toujours pas patché la vulnérabilité au bout d’une certaine durée, Durée qui serait établie en fonction de la sévérité de la faille en question.

En tous cas je suis peut-être paranoïaque, mais pour moi ces annonces relèvent plus de tentatives pour reprendre le contrôle de l’information/communication produits  que d’ efforts sincères pour en améliorer la sécurité et la qualité. Le monde de la sécurité informatique  n’est donc pas en pleine mutation. Il est juste égale à lui même , avec ses hauts et ses bas….

Je vais me permettre encore une fois un petit hors sujet ( le « et autres digressions » n’est pas là pour rien ) . Vous savez surement que la semaine dernière, notre gouvernement a lancé en grande pompe la nouvelle carte musique jeune à destination des 12-25ans. Je ne vais pas m’appesantir sur le sujet, il a déjà été moultement discuté ici, là ou encore là.  Par contre j’aimerais revenir sur la campagne de communication qui va avec.

En tous temps,  les services de com’ des gouvernements Français qui se sont succédés ont toujours été archi-nuls, surtout en ce qui concerne la jeunesse. Rappelez vous…. On nous a servi de petites pépites comme « La sécu c’est bien, en abuser ça craint « , ou plus récemment « Sam, le capitaine de soirée », ou encore cette campagne de lutte contre le tabagisme chez les jeunes qui a fait scandale. On savait donc déjà que l’état ne savait pas parler aux jeunes… mais là je crois qu’on a décroché le gros lot, le super Jackpot !!

Pour promouvoir sa « carte à 25 patates » , le ministère de la culture et de la COMMUNICATION nous gratifie donc de 4 « teasers » d’environ 30 secondes chacuns, tous plus ridicules les uns que les autres. On y dépeint des jeunes complètement débiles, qui ne savent pas s’habiller et qui écoutent de la musique ringarde. Bref, le publique cible en prend pour son grade, de sorte qu’au final on ne sait plus trop à qui ils espèrent vendre leur carte. Cette plaisanterie en vidéo émanant des services de communication étatiques (surement aidés par des agences de com’ payées outrageusement cher),  je ne me suis pas trop inquiété car après tout ce n’est pas la première fois qu’ils commettent ce genre de maladresses.

Une tendance générale ?

C’est quand deux jours plus tard j’ai vu la nouvelle campagne « Back2School » de Microsoft  à destination des étudiants sur Dailymotion, que je me suis dit qu’il y avait peut-être un problème plus profond, qui mériterait qu’on s’y intéresse.  Un mot me vint à l’esprit en regardant cette pub :

« 10 lettres:  lamentable ! »

« pas mieux. »

Langage d’ados à deux balles (« tu vas trop kiffer, ça va être l’éclate à donf !! » ),  accoutrements ridicules de teenagers ( blousons de football américains, casquettes à l’envers ), vannes au raz des pâquerettes… bref on a pris tous les clichés du teenager et on les a mis dans une pub. Ces messieurs sont même allés jusqu’a repêcher des épaves du PAF (Le morning live, c’etait le bon temps hein !) pour jouer les acteurs de cette farce.  Après le flop du « Windows, c’était mon idée », on se retrouve plus bas que terre. On peut toutefois se demander : S’agit-il d’une erreur de targeting ou d’un rabaissement délibéré de la cible ? C’est tellement gros que je n’ose croire à la première option.

Finalement je me suis posé la question de savoir si ce n’était pas la lubie marketing du moment de vouloir prendre les jeunes adultes pour des crétins finis.A force de les décerveler à coups de Télé-Réalité et de leur donner de la culture de bas étage à consommer,  Nos jeunes en seraient-ils venus à se gratifier de leur  stupidité ? Je ne suis moi même pas du tout expert en communication mais la question mérite d’être posée.  Car si le publicitaire a toujours dépeint l’adolescent comme quelqu’un d’un peu irresponsable et benêt,  il franchit ici une étape supplémentaire qui le fait déroger à l’une de ses sacro-saintes règles,  pour la transformer en: « N’oubliez jamais que les gens sont cons et surtout n’oubliez jamais de le leur rappeler »

L’autre jour,  j’étais avec un ami en train de boire une bière dans un bar Parisien. Lui même étant un enthousiaste d’internet,  nos sujets de conversation tournent souvent autour du réseau . C’était le soir ou deux tables rondes sur la neutralité du net étaient organisées au Sénat. Comme à leur habitude , les amis Spyou, bluetouff et bayardb avaient eu la bonne idée de commenter les débats en direct depuis twitter.  Je ne commenterais pas ici la teneur de ces débats, eux s’en sont déjà très bien chargés, d’autant plus que ce n’est pas tout à fait le sujet de ce billet .

A un moment donc, entre deux gorgées de bière,  je prend nonchalamment mon téléphone mobile entre les mains et décide de checker mon fil de tweets. Puis de dire à mon ami « tiens, il y a en ce moment au Sénat des débats sur la neutralité du net ! ». D’un coup, mon acolyte leve les yeux de sa pinte puis me regarde avec des yeux de poisson, tout en me rétorquant « la quoi ? » . Je dois avouer que je fus dans un premier temps un peu choqué par cette réaction. Mais au delà du choc, il fallait corriger le tir immédiatement ! C’est alors que j’entrepris de lui expliquer simplement, en quelques phrases, de quoi il retournait lorsqu’on parlait de neutralité du Net.

« Tu vois, la neutralité du net, c’est un ensemble de principes qui ont bati le réseau et qui lui ont permis de devenir ce qu’il est;  Mais qui sont aujourd’hui remis en question. Avoir un internet neutre, c’est par exemple s’assurer qu’il n’y ai pas de discriminations suivant la source, le destinataire, le protocole ou le contenu  de l’information. Avoir un internet neutre c’est assurer un équilibre entre les acteurs, de sorte par exemple que l’abonné Free puisse voir le même internet que l’abonné SFR…enfin, qu’ils voient tous les 2 le vrai internet quoi « .  Il n’a pas mis longtemps à comprendre que ce que je lui racontait était important, mais nous en sommes restés là.

En y réfléchissant plus tard dans la soirée, j’en suis venu à la conclusion que comme pour la DADVSI et autres saloperies en « i », si mon ami pourtant technophile n’avait jusqu’a présent pas entendu parlé de neutralité du net, il y avait de grandes chances pour que Mme Michu n’en entende elle jamais parler. Et pourtant ce débat la concerne autant que Michel, le mec poilu qui bosse sur un backbone d’opérateur tier 1.

La neutralité du réseau est un principe qui ne devrait même pas être sujet à débat . La neutralité EST internet, sans elle ce n’est plus internet. Mais non contents de la remettre en cause, les gens qui ont porté ce débat  l’enrobent à présent avec de fausses problématiques techniques,  le cachent sous des « c’est trop compliqué, c’est trop technique, ça ne concerne que les gens qui savent ».

Pourtant Madame Michu n’a guerre besoin de travailler à la poste pour comprendre que si on lui ouvre son courrier avant de lui délivrer, ce comportement n’est pas acceptable et doit être sanctionné. Au final, il n’y a aucun consensus sur ces sujets car la grande majorité des citoyens est écartée d’emblée, et volontairement maintenu dans l’ignorance.

Les médias  « traditionnels » ont une grande part de responsabilité dans cet état de fait. Ils faillissent tout à fait sciemment à leur devoir d’information et de vulgarisation, car il n’est pas dans du tout dans l’intérêt des grands groupes de communication ni de l’état d’avoir un internet neutre, libre et ouvert. Trop dangereux . Trop subversif . Trop…. Libertaire .

Il suffit de voir la couverture médiatique quasi nulle,  ou mensongère lorsqu’elle existe, qui a été faite dernièrement sur HADOPI.  Et malheureusement les débats sur la neutralité du net sont en train de prendre le même funeste chemin. La situation serait encore pire si des organisations comme la quadrature du net, FDN ou meme l’APRIL, ne s’échinaient pas à essayer de porter le débat sur la place publique.

Mon ami m’a rappelé qu’il est de notre devoir, à nous qui sommes déjà sensibilisés à ces problématiques , et qui sommes attachés à la neutralité du réseau, de suivre l’exemple de ces associations et d’en parler tout autour de nous.

Et c’est bien ce à quoi je compte m’employer à partir de maintenant.

Je pari qu’il vous est tous arrivé au moins une fois, de vous réveiller au lendemain d’une soirée très arrosée , avec la tête si profondément rentrée dans les fesses, que vous vous êtes demandé si vous verriez un jour le bout du tunnel ? Avec une barre tellement rentrée dans le crane que vous vous êtes interroge sur la façon dont celle-ci a pu rentrer sans provoquer une hémorragie cérébrale ? C’est un peu l’état dans lequel je me suis réveille, bien malgré moi en ce fameux mercredi 15 septembre, date d’ouverture du repository diaspora* sur github.

Des mois  de travail, et des centaines de milliers de dollars pour ça…merde ! je crois qu’il n’y pas d’autres mots pour qualifier le désappointement qui m’envaillit ce jour là . Cela fait maintenant près de 3 mois  que c’est arrivé,  ce billet peut donc paraitre un peu « réchauffé ».  Toutefois il me semble important d’analyser ce qui s’est passé et d’envisager l’avenir du projet de façon réaliste.

Comme beaucoup d’autres gens, j’avais fondé énormément d’espoir en ce projet. J’étais près. J’avais même décidé de démarrer un petit service d’hosting de profils diaspora* , basé sur ngnix et RoR. Le résultat n’etait biensur pas a la hauteur de mes attentes. la pauvreté du code donnait l’impression que l’équipe s’était dit deux semaines avant la release: « Merde les gars, on a plus que 15 jours..faudrait peut-être qu’on se bouge et qu’on ponde un truc ! »

1. Un mauvais départ ?

je regardais récemment un talk de ted , qui disait en substance: « Lorsque vous avez un projet et que vous le révélez, puis qu’on vous congratule pour votre initiative, alors votre cerveau le considère d’or et déjà comme achevé car vous en avez déjà tiré la récompense/reconnaissance . » Je pense que c’est un peu ce qui c’est passé avec notre jeune équipe New-Yorkaise. L’engouement sucité par le projet , matérialisé par une levée de fonds bien au delà des attentes, est très certainement monté à la tête de nos développeurs ( ce qui peut sembler normal ). Selon moi, l’approche qu’il aurait mieux fallu adopter ( bien que peut-être financièrement irréaliste ) aurait été de coder en mode « gus dans un garage » , puis de faire exploser sa bombe une fois le projet bien entamé.

2. la release qui ne fallait pas rater

L’equipe avait prévenu: il s’agissait d’une release de développement, par conséquent uniquement destinée à l’attention des développeurs. Mais qui a déjà pris le train d’un projet communautaire en marche sait comment cela fonctionne: la première impression est essentielle. Si vous voulez attirer des développeurs sur un projet, vous devez mettre toutes les chances de votre coté, et pour ça vous devez les « bluffer » sur le travail déjà accompli. Il est beaucoup plus facile d’attirer les gens sur quelque chose de concret et qui marche déjà à moitié, que sur un concept qui n’existe que dans votre tête, aussi brillant soit-il.

3. Un avenir plus radieux

Malgré la douche froide provoquée par la sortie de cette première version,  les temps à venir s’annoncent plus cléments. Les commits s’enchainent a un rythme soutenu et nul doute que la déception provoqué par leur première mouture a plus que jamais motivé nos compères. Reste à présent à convaincre une masse plus conséquente de développeurs de se joindre à l’aventure, et surtout à convaincre les utilisateurs que le passage à diaspora leur apportera un vrai plus par rapport à la concurrence,  ce qui n’est pas impossible mais loin d’être gagné…

Il y a bien longtemps, alors que la « culture hackers » baignait encore dans la soupe primitive du système universitaire Américain, les gens comprirent que les concepts qu’ils appliquaient aux ordinateurs et aux programmes les controlant, pouvaient s’appliquer à n’importe quel domaine. Que les principes philosophiques qui sous-tendent la culture hackers peuvent etre extrapolés à n’importe quel aspect de notre societé .

Malheureusement cet état de fait semble avoir été oublié, et depuis un moment maintenant le terme Hacker ne subsiste plus dans l’inconscient collectif qu’en tant que « pirate informatique » .

Mais l’espoire subsiste ! En organisant en ce week-end de toussaint le Plastic Hackerspace Festival , Les membres du  /tmp/lab veulent nous rafraichir la memoire, et nous montrer que l’integralité du monde qui nous entoure peut être hacké, modifié, remodelé selon nos désirs et que cela ne necessite souvent pas grand chose si ce n’est de la motivation et un peu d’huile de coude . Construire le futur c’est aussi analyser le présent avec pertinence, et croyez moi les ptits gars du /tmp/lab n’en manquent pas.

Donc si apprendre et partager sur une multitude sujets, avec des gens ouverts et intelligents est dans vos cordes, alors je vous conseil de ne pas hésiter une seconde et de venir ce Week-end à vitry, dans les locaux du /tmp/lab. See you there