{"id":157,"date":"2012-07-02T18:16:44","date_gmt":"2012-07-02T16:16:44","guid":{"rendered":"http:\/\/blog.asafety.fr\/?p=157"},"modified":"2015-11-11T01:31:31","modified_gmt":"2015-11-10T23:31:31","slug":"dechiffrer-un-flux-ipsec-ikev2-de-racoon2","status":"publish","type":"post","link":"https:\/\/www.asafety.fr\/en\/prog-and-dev\/dechiffrer-un-flux-ipsec-ikev2-de-racoon2\/","title":{"rendered":"D\u00e9chiffrer un flux IPsec IKEv2 de Racoon2"},"content":{"rendered":"

<\/p>\n

IPsec, pour “Internet Protocol Security<\/em>” est un des standards en termes de protocoles s\u00e9curis\u00e9s. Tr\u00e8s d\u00e9ploy\u00e9 dans le monde de l’entreprise, ce protocole permet d’assurer des communications s\u00e9curis\u00e9s (int\u00e8gres, authentifi\u00e9es et confidentielles) au travers de r\u00e9seaux jug\u00e9s non-s\u00e9curis\u00e9s tel l’Internet.<\/p>\n

Cet article n’a pas la vocation de pr\u00e9senter finement le fonctionnement d’IPsec ni de ses multiples configurations, mais de s’attarder sur le d\u00e9chiffrement de tels flux, notamment au travers du tr\u00e8s c\u00e9l\u00e8bre\u00a0analyseur r\u00e9seau Wireshark<\/a>.<\/p>\n

Le protocole IPsec se compose de plusieurs sous-protocoles.\u00a0Le protocole de n\u00e9gociation IKE pour “Internet Key eXchange”<\/em>, fond\u00e9 sur le framework<\/em> protocolaire ISAKMP (“Internet Security Association and Key Management Protocol”<\/em>). IKE existe en deux versions dont les sp\u00e9cificit\u00e9s et fonctionnalit\u00e9s sont tr\u00e8s diff\u00e9rentes. La premi\u00e8re version est jug\u00e9e beaucoup plus complexe \u00e0 mettre en place que la seconde notamment via ses modes de fonctionnement (“main”<\/em>, “agressive”<\/em>, “quick mode”<\/em>…). Ce protocole de n\u00e9gociation sert \u00e0 accorder les deux partis d’une liaison s\u00e9curis\u00e9e autour des algorithmes cryptographiques \u00e0 employer (sym\u00e9trique, asym\u00e9trique, de hachage…), du type de lien \u00e0 \u00e9tablir (“tunnel<\/em>” ou “transport”<\/em>) et du protocole d’acheminement de donn\u00e9es \u00e0 utiliser (AH pour “Authentification header<\/em>” qui assure l’authentification des \u00e9changes, et\/ou ESP pour “Encapsulated Security Payload<\/em>” qui ajoute la confidentialit\u00e9).<\/p>\n

Au niveau de la pile OSI, IPsec \u00e9volue \u00e0 divers niveaux. La n\u00e9gociation via IKE\/ISAKMP s’effectue au niveau de la couche 4 applicative, via un transport UDP alors que l’acheminement des donn\u00e9es en tant que telles se fait via la couche 3 r\u00e9seau, prot\u00e9geant ainsi toutes les couches sup\u00e9rieures (dont TCP et UDP).<\/p>\n

\"Pile<\/a>

Pile OSI et protocoles s\u00e9curis\u00e9s<\/p><\/div>\n

Lors d’analyse r\u00e9seau, de mise en place d’architecture s\u00e9curis\u00e9e, de troubleshooting<\/em>, de pentest<\/em>, de fuzzing<\/em> ou d’audit d’intrusion, il est souvent n\u00e9cessaire de s’attarder sur des flux chiffr\u00e9s via IPsec.<\/p>\n

Le d\u00e9chiffrement de flux IPsec d\u00e9pend du sous-protocole cibl\u00e9. Est-ce l’acheminement de donn\u00e9es qui doit \u00eatre d\u00e9chiffr\u00e9 pour de l’analyse? Ou la n\u00e9gociation des param\u00e8tres de s\u00e9curit\u00e9? Pour chacun de ces cas, diverses difficult\u00e9s interviennent. L’outil de r\u00e9f\u00e9rence de visualisation des flux chiffr\u00e9s et d\u00e9chiffr\u00e9s est Wireshark. Celui-ci dispose des facult\u00e9s de :<\/p>\n