Alors que des rumeurs de bridage, déjà en place, du moins en expérimentation chez certains fournisseurs d’accès font leur chemin, les internautes cherchent logiquement une parade et plus globalement des solutions contournement de toute cette faune nouvelle de la surveillance. Parmi les solutions les plus extrêmes que les ayants-droit aimeraient mettre en place pour « dépoluer » Internet, il y l’inspection en profondeur de paquets. Les VPN peuvent paraître une réponse séduisante au DPI, car l’usage d’une technologie de reconnaissance de contenu serait soit disant inopérante sur des flux chiffrés. Et bien j’en doute.
Il faut d’abord que nous soyons d’accord sur le périmètre du DPI pour comprendre de quoi on parle. Le Deep Packet Inspection est une technique faisant appel à plusieurs outils. Ces outils analysent des flux réseaux aussi bien que les paquets eux mêmes. On demande ensuite à une puissance de calcul d’exécuter des actions de routage, de drop, de trafic shaping, de QoS, sur des flux, en fonction de règles prédéterminées. Si on lui dit de faire quelque chose de débile, il fera quelque chose débile, il s’agit d’une loi cybernétique. Et à votre avis, comment réagit une IA quand on lui demande « drop moi tous les paquets illégaux ? »…. Et bien la machine vous demandera de définir le terme qu’elle ne comprend pas, le terme « illégal ». Même sans avoir à casser un chiffrement à la volée, de la simple reconnaissance de signatures, du marquage de paquets, une règle basée sur la taille… et hop, même votre DivX a du mal à passer d’un point à un autre du réseau. Il faut bien comprendre que ces règles ne s’appliquent donc pas simplement à un paquet, mais peuvent l’être à un flux réseau (le paquet et son contexte), à un protocole (bridage d’un port)…
Il y a deux points dérangeants dans cet usage du DPI :
1° les règles de filtrage qui entrainent une altération du réseau alors que celui-ci n’est physiquement pas menacé est une atteinte à sa neutralité ;
2° l’usage d’une technologie de reconnaissance de contenu c’est l’utilisation d’outils particulièrement intrusifs car détournés de leur vocation initiale.
Dans cet effort fait pour « civiliser notre Internet« , des constructeurs, qui ont senti le bon filon, annoncent des solutions d’inspection de paquets et de reconnaissance de contenus, même dans des flux chiffrés.
C’est le cas de LOPPHOLD en juin dernier qui avec son nouveau SONIC OS 5.6, annonçait capable de réaliser une inspection de paquets sur un flux chiffré en SSL.
« SonicOS 5.6 introduces SonicWALL’s new DPI-SSL feature, which does not rely on a proxy configuration on the end points to provide optimised protection against today’s encrypted threats and to enforce corporate data policies. The technology can inspect inside all SSL sessions across all ports, independently of the protocol, resulting in both encrypted and decrypted data being scanned, monitored and protected. »
Sincèrement, je ne sais trop quoi penser de cette déclaration très marketing mais techniquement, une intégration poussée de SSLSniff est loin d’être délirante. Il me semble cependant que la gamme SonicWall n’est pas adaptée à une écoute en coeur de réseau (son débit de traitement doit-être relativement limité, le haut de gamme, le E7500 annonce 8000 connexions chiffrées simultanées). Vous pouvez télécharger un PDF assez explicatif ici.
De là à se demander s’il n’existe pas des équipement de classe ISP, il n’y a qu’un pas. D’un point de vue puissance de calcul, le cassage à la volée n’est peut-être pas à l’ordre du jour, mais avec les nouvelles gammes d’équipements promises par certains équipementiers ça risque d’arriver plus tôt que prévu.
Pour m’être un peu pencher sur le DPI sur SSL, il va agir comme un proxy :
Connexion SSL entre le serveur et le DPI Device,
et une autre connexion SSL entre le DPI Device et le client.
Si c’est du HTTPS, on peut voir que l’on n’est pas directement connecter sur le site grace au certificat qui n’est pas celui du site.
Oui, c’est bien ce qu’il me semble en lisant le texte. On doit valider le certificat du proxy lors de la connexion https. Et si les certificats SonicWall ne sont pas des certificats de confiance ça va vite se savoir à mon avis…
certificat de confiance ?
le but d’une connection protégée par SSL est (entre autre) d’assurer que la destination est bien celle que je veux joindre
du coup que les certificats de ce produit soient signés par une autorité assez reconnue ou pas, mon client reseau qui démarre la connection se voit alerté que le serveur de destination que je cherche a joindre n’est pas celui auquel je suis connecté (je demande https://www.google.fr/ et je tombe sur le certificat du proxy)
c’est purement et simplement du « man in the middle » officiel puisque l’administrateur, du reseau sur lequel je suis, « se met en coupure » de ma connection et forge un certificat provisoire :
avant
moi https://google.fr
mon client dira OK la destination est validé
après :
moi proxy https://google.fr
mon client dira NON-OK la destination n’est pas celle que je veux.
Une exemple vécu : quelqu’un qui accèdait a son compte bancaire a travers un tel proxy https. Je lui ai bien expliqué que le flux était protégé jusqu’au proxy puis le proxy relayait.
Il a très vite compris la conséquence, meme si au départ il a eu du mal a y croire.
Une seule solution que les clients reseau refuse catégoriquement toutes erreurs sur le flux SSL.
les schémas sont mal passés :
avant
|moi| –certificat google –https://google.fr
mon client dira OK la destination est validé
après :
|moi| –certif proxy — |proxy| –certif google– |https://google.fr|
mon client dira NON-OK la destination n’est pas celle que je veux.
Dans le cas du web, en général on a effectivement des navigateurs qui nous signalent quand il se passe quelque chose de louche au niveau des certifs. Mais pour les autres protocoles ? Pour jabber par exemple, Pidgin propose de valider le certificat du serveur lorsque celui-ci change, mais il n’y a pas à ma connaissance de moyen simple de vérifier si ce certificat est fiable…
Oui le doc dit qu’il resigne le certif
plus précisement, il en constuit un temporairement a la volé avec le nom du serveur distant, grace a l’autorité de certitication locale (celle de l’entreprise)
du coup si le certificat de l’autorité est installé sur les machines de l’entreprise (c’est du pouvoir de l’admin qui met le proxy en place) c’est transparent pour le client (ie aucune erreur SSL)
mais si tu viens avec ta machine (tu n’as pas cette autorité de certification dans ta machine vue que s’en ai pas une pour toi) et que tu passes dans ce mecanisme, tu le saura immediatement.
reste a mailer a l’admin et lui faire comprendre que ton idée des communications protégés
Ah ok je comprends mieux.
Donc ce truc là c’est surtout une offre pour les entreprises et autres endroits où l’administrateur qui valide les certificats sur la machine est différent de l’utilisateur de la machine.
Ca donne une petite idée du « logiciel de sécurisation »… qui installera cette mécanique d’entreprise sur les machines privées!
Bienvenue au Sarkozistan…
Effectivement cela fonctionne très bien en environnement fermé (dans les entreprises disposant d’une politique de sécurité sérieuse, aucune autre machine que celles de l’entreprise n’est autorisée à se raccorder à l’infra) et pour le HTTPS ou le FTPS.
Mais se pose ensuite le souci de la confidentialité des conversations.
L’employeur est en droit de savoir ce que chaque employé fait (exemple du courriel : à qui il écrit, qui lui écrit) mais pas de lire son contenu !
Or là, clairement, l’employeur a accès aux comptes bancaires ainsi qu’aux différents mots de passe.
Pas très légal tout cela.
Enfin, il n’est pas nécessaire d’avoir un Sonic machin pour cela : un Squid configuré correctement (et sa tripotée de scripts qui vont bien) le fait également.
db
Tout cela pour dire qu’en entreprise (environnement fermé) c’est facile donc possible mais c’est limite légal (je ne suis pas juriste mais traitement automatique des données personnelles et observation des conversations personnelles … à mon avis FAIL).
Mais que chez un FAI c’est carrément rédhibitoire : comment imposerait-il sa propre hiérarchie sur votre machine ?
Grâce au logiciel mouchard de la halte au pis par exemple ?
Et donc, grâce à halte au pis le FAI espionnerait vos conversations ?
Ben tiens.
Et moi je suis la Reine d’Angleterre aussi !
db
Pas très rassurant tout ça, alors existe t-il une méthode pour contrer ce SONIC OS 5.6 ?
oui refuser le certificat SSL proposé car il contient des informations qui prouve qu’il y a une machine qui coupe la session SSL de bout en bout.
(
« Network administrators are also losing visibility into their networks as more and more encrypted applications attempt to avoid the HTTPS protocol to potentially bypass content filtering and leak valuable information or expose networks to attacks from malware. »
Mwé, dans son discours, on prend des risques d’exposer des infos confidentielles à vouloir tout décrypter.
Ce qui m’étonne, c’est de pouvoir casser un chiffrement asymétrique… Autant, le forcer à passer en HTTP je comprends, mais à moins d’une faille/oubli, l’utilisateur a de fortes chances de s’en rendre compte…
intéressant tout ça
Question à la c…n, si n’importe qui (dans le cas présent le/un transporteur) peut faire un faux certif, car il me semble qu’il est forgé à la volée dans ce cas, c’est tous les certifs qui s’écroulent, non?
Je pense pas que ça plaise à tout le monde ce genre de concept…
et que se passerait-t-il si les méchants certificats étaient intégrés dans les magasins de certificats des configs d’internet explorer et firefox par exemple ?
Firefox c’est pas le genre, la MoFo est plutôt clean là dessus.
Par contre, que se passera-t-il si un FAI, qui dispose de certificats légitimes, se met à utiliser ce genre de solutions en mettant un certificat maison?
Les CA existantes dans Firefox, IE, Opera, etc ont déjà signés des certificats ayant la contrainte CA:TRUE pour des ISP.
Je vous laisse imaginer ce qu’on faire avec 🙂
Le certificat a beau être légitime, s’il ne couvre pas le domaine que je vise, mon navigateur me le signalera quand même.
Par contre, j’ai beau chercher je ne trouve pas tes fameux certificats CA:TRUE pour ISP.
Et je vois aussi mal une organisation racine valider un certificat pour un truc générique *.* (même sous la pression du Gvt américain vu qu’il s’agit de boîtes américaines) ça ferait s’écrouler le principe de la certification et donc de facto rendrait nul leur rôle et leur « source » de revenus.
Si d’aventure ce type de chose devait se produire, il y’aurait bien des gens pour développer le « http over GPG » ou un truc du genre.
l’autorité de certification racine c’est l’admin dans ce cas..
Il installe le certificat racine sur ces machines du parc, et utilise un mécanisme de création de certificat temporaire en fonction de l’hote demandé, sur le proxy
donc tu peux créer les certificats que tu veux pour n’importe quel hote, reconnu comme correct sur la machine cliente.
Cette technique ne fonctionnera pas sur un VPN SSL bien formé et configuré, car le certificat MITM ne sera jamais valide, même s’il est signé par un root CA « classique ». Ca fera un déni de connexion certes, mais les informations ne passeront pas. SSLstrip fonctionne en redirection et en droppant la connexion cryptée ce qui ne devrait pas affecter les VPN qui ne fonctionnent pas comme des navigateurs web.
S’ils veulent mettre en place ce genre de connerie, ça va être lourd, mais pas incontournable. Encore un bon exemple que le flicage d’internet fait chier le monde mais ne règlera jamais « leur problème », la population évoluera vers des méthodes tordues pour contourner les barrières, qui amèneront d’autres barrières, qui amèneront d’autres contournements, ad infinitum… Autant garder tout cet argent pour tout ce qui va de travers dans ce pays, genre sauvegarder les industries qui elles, sont vraiment moribondes et laissent des milliers de personnes sur le carreau…
Il n’y a pas besoin d’être méchant : toute entreprise a la possibilité d’intégrer sa propre racine et sa propre hiérarchie dans les navigateurs qu’elle installe qu’ils soient IE, FF ou Safari.
db
Cool ton histoire d’halloween. On n’a plus qu’à espérer que c’est plus ou moins de la grande gueule marketting, parce qu’un truc pareil en production aurait toutes les chances de de péter la gueule tout seul.
Ce n’est pas vraiment nouveau. En fait la seule question pertinente est: avez confiance dans votre « autorité de certifiation » ?
Sinon comment rétablir cette confiance?
Pour revenir sur la fiabilité des certificats d’authentification , un article de l’EFF
http://www.eff.org/deeplinks/2010/03/researchers-reveal-likelihood-governments-fake-ssl reprenait une publication de 2 chercheurs assez effrayante intitulée Certi ed Lies: Detecting and Defeating Government Interception Attacks Against SSL qui suggère que les Etats utiliseraient de faux CA à diverses fins.
Ces entreprises qui se font (ou qui se feront) du fric en contribuant à la surveillance et au flicage de leur concitoyens et d’eux-mêmes me font gerber.
Ah?! Il est tout à fait imaginable qu’un partenariat se fasse avec une autorité de certification racine pour que cette dernière signe les certificats temporaires.
Comme la tierce partie publique est présente dans le magasin, il n’y aura même pas d’alerte!
Pfff, on vient d’inventer les autorités de certification et « autorités de certification by Orange »
Lecteur assidu de tes articles, une petite observation par rapport au passage « C’est le cas de LOPPHOLD en juin dernier qui avec son nouveau SONIC OS 5.6 ».
Selon les 1ères lignes du lien donné, « LOOPHOLD Security Distribution » » est un distributeur. SonicOS 5.6 est une création de SonicWall.
Pour ce que j’en connais, ils ont démarré dans le créneau du « petit » firewall d’entreprise, qui pousse petit à petit vers du plus gros. Leurs modèles les plus puissants ont des interfaces Gigabit et annoncent un traitement de 2,2 Gb/s max pour le DPI, ce qui me semble très vite limité pour du FAI un peu conséquent.
Ensuite, on peu empiler, gérer de manière centralisée, et il n’y a aucune raison pour que des constructeurs de matos plus gros ne puissent faire la même chose, surtout s’il y a une demande.
Le fait que le firewall est un parfait « Man in the middle » a déjà bien été évoqué, et il est clair qu’à partir de là, on fait à peu près ce qu’on veut…
Ne serait-ce que pour se rendre compte que l’on est observé, une des règles de sécurité de base, difficilement applicable pour le https, mais essentielle notamment pour les VPN, ca reste l’échange de clés/certifs par une voie tierce, autre qu’internet (poste, Fax, main à main…)
La DPI a ces limites, encore plus sur les connexions chiffrées.
Alors oui c’est possible de détecter le type de protocole passant sur une connexion chiffrée. En effet, en utilisant des stats sur la taille des packets, les SYN/ACK et autres flags, c’est relativement simple à faire.
Mais après il y a une grande marge entre savoir reconnaitre un protocol applicatif (http, torrent, etc) et savoir détecter du contenu.
Je suis sur que détecter un protocol c’est possible à large échelle. Mais je suis aussi quasiment certains que détecter du contenu dans une connexion chiffrée (genre savoir faire la différence entre un iso et un xvid) est extrêment difficile malgré les conneries marketing.
Entre ce que dit les grandes boites (Alcatel ou autres) et la réalité il y a une marge.
Je pars du fait que si Echelon ne sait pas le faire, c’est pas réaliste de croire que Orange pourra le faire.
Alors oui si on va vers ce qu’on appelle l’Internet du Futur (genre ce qu’on nous présente dans ce genre de conf: http://www.iaria.org/conferences2010/AFIN10.html) avec du content aware à tous les niveaux, je dis pas que ca sera impossible. Mais bon appart revoir l’intégralité du réseau ca ne sera pas possible.
Oui les lois sont débiles et dangereuses mais heuresement malgré les conneries marketing qu’on nous sort, on est encore assez loin (et heuresement) de la possibilité d’un DPI efficace pour le contrôle de contenu sans un coût allucinant (et je parle pas de millions mais de milliards pour la France).
@Arrouan
En effet, en utilisant des stats sur la taille des packets, les SYN/ACK et autres flags, c’est relativement simple à faire.
Non, le profilage s’appuie sur d’autres techniques : longueur moyenne des paquets, rythme, sens, etc.
Ce n’est pas parfait mais cela permet de savoir si tu fait du HTTP (gros paquets de temps en temps et majoritairement dans un sens ) ou de la voix sur IP (nombreux petits paquets très rapprochés et dans les 2 sens).
Mais le profilage se contourne aisément (lorsqu’on a la maîtrise du protocole) en ajoutant ce qu’on appelle du bourrage (des données sans aucun sens qui sont détruites et par le serveur et par le client).
Cela ne fait pas ressembler un protocole de voix sur IP à du HTTP mais ça déroute les profileurs.
db
Donc on peut tout à fait faire de la détection protocolaire avec le DPI mais de la détection de contenu dans une connexion chiffrée est impossible.
Le DPI c’est très dangereux mais ca ne permet pas tout non plus.