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.
