A10

Protocoles de scurit

FAUVET Romain GEORGE Paul LONG Weiquan VU Xuan

UTC A10

Protocoles de scurit

A10

1. Introduction ...............................................................................................................5 2. PPTP ........................................................................................................................... 5 2.1. Introduction ........................................................................................................5 2.2. PPP ...................................................................................................................... 5 2.2.1. Contenu........................................................................................................6 2.2.1.1. Protocole dencapsulation ....................................................................6 2.2.1.2. Link Control Protocol (LCP) ...................................................................6 2.2.1.3. Network Control Protocol (NCP)........................................................... 6 2.2.2. Droulement dune communication ........................................................... 6 2.2.2.1. Configuration et tablissement de la liaison ........................................6 2.2.2.2. Opration de communication ............................................................... 6 2.2.2.3. Fermeture de la liaison .........................................................................6 2.2.3. Format des trames ....................................................................................... 7 2.2.4. Exemple de communication ........................................................................7 2.2.5. LCP................................................................................................................8 2.2.5.1. Rle .......................................................................................................8 2.2.5.2. Format des paquets ..............................................................................8 2.2.5.3. Diffrents types de trames ...................................................................8 2.2.5.3.1. LCP Link Configuration ...................................................................8 2.2.5.3.1.1. Format..................................................................................... 8 2.2.5.3.1.2. Droulement dun change .................................................... 9 2.2.5.3.2. LCP Link Maintenance ....................................................................9 2.2.5.3.3. LCP Link Termination .....................................................................9 2.2.6 NCP ................................................................................................................9 2.3. PPTP .................................................................................................................... 9 2.3.1. Introduction .................................................................................................9 2.3.2. Le tunnel PPTP ........................................................................................... 10 2.3.3. Architecture PPTP ...................................................................................... 10 2.3.3.1. Etablissement de la connexion entre le client et le NAS .................... 10 2.3.3.2. Etablissement dune connexion entre le client et le serveur PPTP ....10 2.3.3.3. Crer les paquets PPP contenant les datagrammes ........................... 11 2.3.3.3.1. Authentification ...........................................................................11 2.3.3.3.2. Chiffrement des donnes ............................................................ 11 2.3.3.3.3. Action de filtrage .........................................................................12 3. L2TP (Layer 2 Tunnel Protocol) ................................................................................12 3.1. Introduction ......................................................................................................12 FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

Protocoles de scurit

A10

3.2. Fonctionnement gnral................................................................................... 12 3.3. Description du protocole .................................................................................. 12 3.3.1. Les messages de contrle ..........................................................................13 3.3.2. Etablissement du tunnel ............................................................................13 3.3.2.1. Etablissement de la connexion de contrle........................................14 3.3.2.2. Etablissement d'une session L2TP ...................................................... 14 3.3.2.3. Fermeture de la session ......................................................................14 3.3.2.4. Fermeture de la connexion de contrle .............................................14 3.3.2.5. Rcapitulatif ........................................................................................ 15 3.3.3. Scurit dans L2TP ..................................................................................... 15 4. IPsec ......................................................................................................................... 15 4.1. Architecture de scurit ................................................................................... 17 4.1.1. Mode dchange ........................................................................................ 17 4.1.2. SA (Association de scurit).......................................................................17 4.1.3. AH ...............................................................................................................18 4.1.4. ESP..............................................................................................................19 4.1.5. IKE ..............................................................................................................20 4.2. Fonctionnement................................................................................................ 20 4.3. Inconvnients et problmes .............................................................................21 4.4. Conclusion .........................................................................................................22 5. TLS/SSL ..................................................................................................................... 22 5.1. Introduction ......................................................................................................22 5.2. Droulement des changes SSL ........................................................................23 5.3. Les sous-protocoles de SSL ...............................................................................24 5.3.1. Le protocole Handshake ............................................................................24 5.3.2. Le protocole ChangeCipherSpec (CCS) ...................................................... 24 5.3.3. Le protocole SSLAlert .................................................................................24 5.3.3.1. Erreurs fatales ..................................................................................... 25 5.3.3.2. Warnings ............................................................................................. 25 5.3.4. Le protocole SSLRecord .............................................................................25 5.4. Les attaques et faiblesses de SSL ......................................................................25 5.5. Conclusion .........................................................................................................26 6. SSH ........................................................................................................................... 27 6.1. Introduction ......................................................................................................27 6.1.1. Contexte .....................................................................................................27 6.1.2. Dfinition ...................................................................................................27 FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

Protocoles de scurit

A10

6.2. Survol des caractristiques des SSH .................................................................28 6.2.1. Connexions scurise distance ............................................................... 28 6.2.2. Transfert scuris de fichier ......................................................................29 6.3. Droulement dune session SSH2 .....................................................................29 6.4. Architecture du protocole SSH-2 ......................................................................30 6.4.1. La couche de transport (SSH-TRANS)......................................................... 31 6.4.2. La couche dauthentification (SSH-AUTH) .................................................31 6.4.3. La couche de connexion (SSH-CONN) ........................................................ 31 7. DNSSEC ..................................................................................................................... 32 7.1. Introduction ......................................................................................................32 7.2. DNS.................................................................................................................... 32 7.2.1. Utilit..........................................................................................................32 7.2.2. Exemple......................................................................................................32 7.2.3. Fonctionnement......................................................................................... 32 7.2.3.1. Hirarchique ....................................................................................... 32 7.2.3.2. Distribu .............................................................................................. 33 7.2.3.3. Optimis .............................................................................................. 33 7.2.4. Enregistrements DNS ou Resource Records (RR) ......................................34 7.3. Failles de scurit.............................................................................................. 35 7.3.1. Interception des paquets et fabrication dune fausse rponse ................35 7.3.2. Attaque de type man in the middle ..................................................... 35 7.3.3. Corruption de donnes ..............................................................................36 7.3.4. Empoisonnement du cache DNS................................................................ 37 7.3.5. Usurpation didentit du DNS primaire ..................................................... 38 7.3.6. Attaque de type DDos ................................................................................39 7.3.7. Inventaire ...................................................................................................39 7.3.7.1. Attaque par dictionnaire .....................................................................39 7.3.7.2. Attaque par force brute ......................................................................40 7.4. DNSSEC ..............................................................................................................40 7.4.1. Prsentation ............................................................................................... 40 7.4.2. Chaine de confiance ................................................................................... 40 7.4.3. Nouveaux types denregistrements DNS ................................................... 40 7.4.4. Gestion des cls ......................................................................................... 42 7.5. Conclusion .........................................................................................................42 8. Conclusion ................................................................................................................42 9. Bibliographies...........................................................................................................42 FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

Protocoles de scurit

A10

1. Introduction
A lpoque de la cration des premiers protocoles rseaux (il y a moins dun demi sicle), les enjeux taient darriver faire communiquer des machines connectes. Les premiers protocoles furent donc btis avec pour seul et unique but de fonctionner. Puis, ils servirent relier des laboratoires trs loigns, les enjeux devinrent donc damliorer leurs performances. Il sagit ensuite dinterconnecter des rseaux entre eux, cest alors quInternet fut lanc et avec lui une plthore de protocoles lui permettant de fonctionner. Internet et les ordinateur grand public sont alors devenus accessibles financirement et les entreprises et les gouvernements commencrent ouvrir leur rseau sur Internet. Les premiers hack qui ont fait grand bruit eurent lieu cette poque l. Les enjeux du rseau avaient volus, et taient dsormais tournes vers la scurit. Par consquent les protocoles de scurit ont souvent t btis au dessus des protocoles originaux dInternet, et tentent de succder leurs prdcesseurs ou de les corriger. Nous allons vous prsenter des protocoles de scurit qui sont aujourdhui utiliss. Quelle meilleure faon de procder que de suivre le modle OSI pour nous guider dans notre dmarche. Nous partirons donc des protocoles des couches basses pour arriver aux couches hautes. Modle OSI Couche dapplication Couche de prsentation Couche de session Couche de transport Couche de rseau Couche de liaison Couche physique Protocoles de scurit SSH, DNSSec TSL/SSL IPsec L2TP, PPTP

2. PPTP
2.1. Introduction
Le protocole PPTP (Point to Point Tunneling Protocol) est bas sur le protocole PPP, il a t dvelopp par des entreprises telles que Microsoft, 3com, Ascend, etc. Pour comprendre le rle du protocole PPTP et de ses successeurs L2TP et IPsec, il convient de dcrire le fonctionnement du protocole quils scurisent c..d. PPP.

2.2. PPP
Le protocole PPP (Point to Point Protocol) appartient la couche 2 du modle OSI. Il permet la dtection derreur, lauthentification, la compression et le chiffrement des donnes. PPP a t { lorigine conu pour transporter des datagrammes IP mais est capable de transporter tout type de datagramme de la couche 3 du modle OSI. Il assure que les trames envoyes, sont reues dans le mme ordre qu{ lmission. FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

Protocoles de scurit

A10

La dtection des erreurs est effectue { laide dun code CRC. PPP autorise le multiplexage de plusieurs protocoles de niveau 3 sur un mme lien physique, supporte plusieurs protocoles dauthentification et permet galement dutiliser plusieurs liens physiques pour augmenter le dbit de communication entre les deux interlocuteurs. 2.2.1. Contenu 2.2.1.1. Protocole dencapsulation Il sert encapsuler les trames des couches suprieures afin de les faire transiter sur le lien physique. Le format de ces trames, driv du protocole HDLC, a t conu pour maximiser le temps de traitement. 2.2.1.2. Link Control Protocol (LCP) Il permet dtablir, maintenir et terminer la liaison entre les deux protagonistes. Tout au long de la communication, les interlocuteurs peuvent schanger des paramtres via ce protocole. 2.2.1.3. Network Control Protocol (NCP) Une fois la liaison tablie, le protocole NCP permet de dfinir des paramtres supplmentaires. Il existe un NCP pour chacun des protocoles de niveau 3. Pour IP, il sappelle IPCP. 2.2.2. Droulement dune communication Une communication PPP stablit en trois tapes : 2.2.2.1. Configuration et tablissement de la liaison Les deux interlocuteurs schangent des messages LCP afin de se mettre daccord sur les modalits de communication, comme par exemple, le type dauthentification, le besoin de compression. Une fois la connexion tablie, cest le NCP correspondant la couche 3 qui prend le relai. Ce dernier suit les mmes tapes que LCP pour tablir une liaison entre les deux interlocuteurs et ngocier des paramtres spcifiques au protocole de niveau 3. 2.2.2.2. Opration de communication Une fois ltape prcdente franchie, les machines peuvent communiquer. Les datagrammes de la couche 3 sont encapsuls, compresss et chiffrs si ncessaire puis envoys au destinataire. Lorsque le paquet est reu, les tapes inverses sont effectues afin de remettre le datagramme la couche 3 du destinataire. 2.2.2.3. Fermeture de la liaison Lorsque lune des deux machines na plus besoin denvoyer de donnes, elle envoie un message LCP de terminaison son homologue. Si elle accepte de fermer la liaison, elle lui envoie un message dacquittement. En rsum, pour tablir une liaison point point, il faut tablir une liaison LCP puis une liaison NCP. Mme si toutes les liaisons NCP sont termines, la liaison LCP reste active. Pour y mettre fin, il faut que les deux machines se mettent daccord pour fermer la liaison (en senvoyant des messages LCP de

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

Protocoles de scurit

A10

terminaison). Il est galement possible de terminer la liaison LCP sans fermer explicitement la ou les liaisons NCP. 2.2.3. Format des trames Les trames PPP sont inspires du protocole HDLC. Une trame contient 7 champs : 1. Flag : les trames sont dlimites par un flag. 2. Address : contient la valeur 0xFF. 3. Control : pour indiquer le type de mode, par dfaut le mode non numrot est slectionn. 4. Protocole : comme plusieurs protocoles peuvent tre encapsuls dans PPP, il faut prciser quel protocole les donnes du champ information appartiennent. 5. Information : contient les donnes transmettre. Il contient les datagrammes des protocoles rseau utilisant la liaison 6. Padding : champ de bourrage. 7. Frame Check Sequence (FCS) : ce champ contient un code dtecteur derreur. 2.2.4. Exemple de communication

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

Protocoles de scurit 2.2.5. LCP

A10

2.2.5.1. Rle LCP est le protocole majeur dans ltablissement dune communication. Tous les autres protocoles de la suite PPP dpendent de lui. LCP est en charge de : La configuration La maintenance La terminaison de la liaison 2.2.5.2. Format des paquets Un paquet LCP contient 4 champs : 1. Code : Ce champ sert indiquer le type de paquet (configuration, maintenance ou terminaison) 2. Identifier : chaque paquet possde un numro (en cas de demande de retransmission, cest ce numro qui permet didentifier le paquet) 3. Length : pour indiquer la taille du paquet (puisque la taille du champ Data est variable) 4. Data : contient les options ngocier (le format des options est dfini cidessous) Les options ont le format suivant (3 champs) : 1. Type : pour indiquer le type doption dont il sagit (pour ngocier un MRU ou une authentification) 2. Length : longueur de loption 3. Data : les donnes si ncessaires 2.2.5.3. Diffrents types de trames Il existe 11 trames LCP diffrentes, reparties dans trois catgories (4 pour la configuration, 5 pour la maintenance, et 2 pour la terminaison). 2.2.5.3.1. LCP Link Configuration 2.2.5.3.1.1. Format Il existe 4 trames de ce type. Elles permettent aux deux couches physiques dchanger et de ngocier des paramtres de communication. Voici les principaux paramtres de configuration : MRU (Maximum Receive Unit) : Spcifier la taille maximum des datagrammes transporter. Authentication Protocol : Indique le protocole dauthentification souhait (lauthentification sous PPP nest pas exige). Quality Protocol : Indique si la qualit du lien doit tre gre (il nexiste pour linstant quun seul protocole pour effectuer cette tche : LQR). MagicNumber : Permet de dtecter les boucles. Compression : pour indiquer que le datagramme est compress. Address Control Field Compression : Indique que ladresse et le champ contrle sont compresss.

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

Protocoles de scurit

A10

2.2.5.3.1.2. Droulement dun change Lorsque le destinataire reoit la trame de configuration (Configure Request), il a plusieurs possibilits : Si les paramtres lui conviennent, il retourne un Configure Ack la source et la ngociation prend fin Si les paramtres ne lui conviennent pas et sil est capable dentamer une ngociation sur ces derniers, il retourne un Configure Nak dans le lequel il ajoute tous les paramtres qui ne lui conviennent pas. Si des paramtres ne sont pas reconnus, un Configure Reject est retourn et ltablissement de la liaison se termine 2.2.5.3.2. LCP Link Maintenance Une fois la connexion tablie, des messages LCP peuvent tre envoys pour tester la liaison : Code Reject et Protocol Reject : messages envoys lorsquune machine reoit une trame avec un code LCP invalide ou un identifiant de protocole inconnu Echo Request, Echo Reply ou DiscardRequest : pour tester la liaison 2.2.5.3.3. LCP Link Termination Pour fermer la liaison, lune des machines envoie un TerminateRequest son homologue qui, rpond par un TerminateAck. 2.2.6 NCP Les protocoles de type NCP (IPCP ou IPXCP) tablissent une liaison en suivant les mmes tapes que dans LCP, savoir configuration, maintien et fermeture de la liaison. Pour ltablissement de la liaison, ils utilisent des Configure Request, Configure Ack, Configure Nak et Configure Request, pour le maintien de la liaison, des messages Code Reject et enfin pour la terminaison, des messages Terminate Request et Terminate Ack.

2.3. PPTP
2.3.1. Introduction PPTP permet un client de se connecter au rseau de son entreprise via un rseau public comme Internet en toute scurit, en cryptant les messages. Un VPN est tabli entre un client et le serveur de son entreprise quils soient sur un mme LAN ou spars par un rseau de type WAN. PPTP supporte les protocoles de niveau 3 sur le rseau priv suivants : IPX, IP et NetBEUI. Gnralement, il y a trois entits impliques dans le dploiement dune architecture PPTP : Un client PPTP Un NAS (Network Access Server) Un serveur PPTP

Si le client et le serveur sont sur un mme LAN, le NAS nest pas ncessaire.

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

Protocoles de scurit

A10

Ltablissement de la connexion entre le client PPTP et le serveur PPTP suit les tapes suivantes. Le client tablit une connexion PPP au NAS puis une deuxime connexion est tablie entre le client et le serveur PPTP en utilisant la premire. Cette dernire est appele tunnel . 2.3.2. Le tunnel PPTP Le terme tunnel dsigne le fait de pouvoir envoyer des messages destination dun nud dun rseau prive en empruntant un rseau public comme Internet. Or les routeurs du rseau public ne connaissent pas la destination puisquil appartient { un rseau priv. Sur le rseau public ladresse destination est le serveur PPTP. Lorsque le serveur PPTP reoit un message du rseau public, il le redirige vers le nud destination du rseau priv. Ladresse de destination est prsente dans la trame PPP. Pour protger les donnes, PPTP crypte les paquets PPP et les encapsule dans des datagrammes IP. Ces derniers sont routs sur Internet. Une fois que le serveur PPTP est atteint, les paquets PPP sont dcrypts puis achemins vers leur destination. 2.3.3. Architecture PPTP Ltablissement dune communication PPTP se fait en 3 tapes : 1. Etablissement dune connexion entre le client et le NAS : pour encrypter les paquets. 2. Etablissement dune connexion entre le client et le serveur PPTP : en utilisant la connexion prcdente, PPTP cre une connexion de contrle entre le client et le serveur PPTP appele tunnel . 3. Emission des donnes : les paquets PPP sont crypts puis transitent via le tunnel jusquau serveur PPTP qui les dcrypte et les envoie destination sur le rseau priv. 2.3.3.1. Etablissement de la connexion entre le client et le NAS Cette tape se fait en 3 sous-tapes: 1. Etablissement de la connexion entre le client et le NAS en utilisant le protocole PPP. 2. Authentifier le client PPTP : le client est authentifi en utilisant le protocole PPP (PAP ou CHAP). 3. Crer les paquets PPP contenant les datagrammes (IP, IPX ou NetBEUI) crypts. 2.3.3.2. Etablissement dune connexion entre le client et le serveur PPTP Pour tablir le tunnel, un ensemble de messages de contrles sont envoys entre le client et le serveur PPTP. Ces messages transitent dans des datagrammes au format suivant : un entte PPP, un entte IP, et le message de contrle. La cration dun tunnel PPTP ne seffectue que sil y a des donnes { transporter du NAS jusquau serveur PPTP (ou inversement). Le nud ayant des donnes envoyer demande ltablissement dun tunnel. Il initie ensuite louverture dune session afin de faire transiter les paquets PPP. Il peut ensuite envoyer ses trames PPP via le tunnel, compltes par une encapsulation GRE. Il est possible douvrir plusieurs sessions simultanment. Les paquets des diffrentes sessions peuvent arriver dans le dsordre au niveau du serveur PPTP. Ce dernier peut FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

10

Protocoles de scurit

A10

rassembler les messages dans le bon ordre grce { lidentifiant de session contenu dans len-tte GRE. Les messages rordonns sont ensuite routs vers la bonne destination. Une fois toutes les sessions termines dans un tunnel, cest--dire quand tous les paquets ont t transmis, la connexion de contrle prend fin. Le schma suivant rcapitule les diffrentes tapes suivre pour tablir le tunnel :

2.3.3.3. Crer les paquets PPP contenant les datagrammes Une fois le tunnel tabli, les donnes encryptes transitent entre le client et le serveur PPTP via le rseau Internet. Le paquet PPP encrypt voyage dans un datagramme IP au format suivant :

Les parties grises reprsentent les donnes cryptes. Lentte IP permet { la trame dtre rout sur lInternet et lentte GRE (Generic Routing Encapsulation) est utilis pour encapsuler la trame PPP. 2.3.3.3.1. Authentification Il y a deux authentifications dans une connexion PPTP. Une, entre le client et le serveur NAS qui ne concerne pas directement la connexion scurise, et une entre le client et le serveur PPTP. En effet, ce dernier joue le rle de frontire entre domaine public (interface connecte Internet) et le domaine priv (interface connecte au rseau priv de lentreprise). Les protocoles dauthentification supports sont PAP (Password Authentication Protocol) et CHAP (Challenge Handshake Authentication Protocol). 2.3.3.3.2. Chiffrement des donnes Il existe deux types de chiffrement pour ce protocole, lutilisation dun secret partag connu des deux interlocuteurs ou bien lutilisation dune cl publique de chiffrement. La cl publique permet de chiffrer les messages et est connu des deux homologues alors que la cl prive nest connue que de la destination et permet de dchiffrer le message.

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

11

Protocoles de scurit

A10

2.3.3.3.3. Action de filtrage Le serveur PPTP peut filtrer les paquets PPTP en ne laissant passer que ceux issus dutilisateurs authentifis pour augmenter la scurit.

3. L2TP (Layer 2 Tunnel Protocol)

3.1. Introduction
Le protocole L2TP est un protocole de niveau 2. Il a t conu pour remplacer les protocoles PPTP de Microsoft et L2F (Layer 2 Forwarding) de Cisco. Il est capable dencapsuler des paquets PPP. Les extrmits du tunnel sont appeles LAC (L2TP Access Concentrator) et LNS (L2TP Network Access). Le NAS (Network Access Server) joue gnralement le rle du LAC. L2TP permet dtablir un VPN entre le client et le rseau priv de lentreprise. Le client peut galement obtenir une adresse IP appartenant au rseau de son entreprise.

3.2. Fonctionnement gnral

Un tunnel L2TP est constitu de deux nuds le LAC et le LNS.

Le LAC reoit les paquets PPP mettre, y ajoute une encapsulation L2TP et les envoie sur le tunnel. Le LNS effectue le travail inverse, cest--dire retire lencapsulation L2TP, rcupre les donnes et transmet le contenu la destination se trouvant sur le rseau priv. Lorsquun nud souhaite envoyer des donnes, un tunnel L2TP et une ou plusieurs sessions sont tablies. Le nombre de sessions est gal au nombre de sessions PPP de chaque utilisateur connect au LNS.

3.3. Description du protocole

Le protocole L2TP permet le transport des sessions PPP travers un tunnel. Lorsque des messages ont besoin de transiter travers celui-ci, il y a tablissement dune connexion de contrle entre le LAC et le LNS. Ensuite, il y a tablissement dune session entre ces deux homologues. Les donnes peuvent ensuite tre envoyes travers ce canal. Des messages sont rgulirement envoys pour vrifier le bon fonctionnement du tunnel. Sur le tunnel transite 2 types de messages : 1. Les messages de contrle : pour grer ltablissement, le maintien et la fermeture. 2. Les donnes. Ces messages nempruntent pas le mme canal. Il y a un canal fiable pour lmission des messages de contrle et un, non fiable pour les donnes. Cest-dire quen cas de perte, il ny a aucune demande de retransmission. La fiabilit est assure par les champs Ns et Nr de lentte L2TP. Le champ Ns indique le FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

12

Protocoles de scurit

A10

numro de squence du message envoy tandis que Nr indique le numro de squence du prochain message attendu. Ces deux champs sont obligatoires pour les messages de contrle. Mme prsents dans les messages de donnes, ils nimpliquent pas de retransmission en cas de perte. Les trames PPP qui arrivent au niveau du LAC sont encapsules dans des trames L2TP. Le LNS retire lencapsulation L2TP et envoie le message son destinataire. Le protocole L2TP ne prvoit aucune forme de contrle dintgrit. 3.3.1. Les messages de contrle Ils sont au nombre de 13. 1. Message Start Control Connection Request : pour tablir le tunnel L2TP 2. Message Start Control Connection Reply : pour signaler la rception du message prcdent 3. Message Start Control Connection Connected : pour signaler que le tunnel est tablit 4. Message Stop Control Connection Notification : pour prvenir lautre extrmit que le tunnel est en cours de fermeture 5. Message Hello : pour vrifier que le tunnel fonctionne bien, des messages Hello sont changes entre le LAC et le LNS Les 3 messages suivants permettent dtablir une session entre LNS et LAC, session initie par le LNS 6. Message Outgoing Call Request : message envoy par le LNS destination du LAC pour signaler quune connexion PPP est demande vers lutilisateur distant 7. Message Outgoing Call Reply : pour notifier le LNS que son message a bien t reu 8. Message Outgoing Call Connected ( destination du LAC) : pour indiquer que la session est maintenant active Les 3 messages suivants permettent dtablir une session entre LNS et LAC, session initie par le LAC 9. Message Incoming Call Request : pour indiquer que lutilisateur distant veut initier une session PPP vers le LNS 10. Message Incomining Call Reply : pour indiquer que le prcdent message a bien t reu 11. Message Incoming Call Connected ( destination du LNS) : pour indiquer que la session est dsormais tablie

12. Message Wan Error Notify : envoy par le LAC vers le LNS, pour indiquer une erreur au niveau du LAC 13. Message Set Link Info : pour prciser les paramtres du lien 3.3.2. Etablissement du tunnel Pour transporter des trames PPP entre les deux homologues, il faut assurer : Ltablissement dune connexion de contrle entre le LAC et le LNS pour permettre la gestion (cration, maintien, fermeture) du tunnel et des sessions FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

13

Protocoles de scurit Ltablissement dune session sur le tunnel

A10

Il peut exister plusieurs sessions sur un mme tunnel et plusieurs tunnels entre LAC et LNS. 3.3.2.1. Etablissement de la connexion de contrle Cette connexion est tablie par lune des extrmits du tunnel (soit le LAC soit le LNS). Linitiateur de ltablissement envoie un Start Control Connection Request, lautre extrmit y rpond par un Start Control Connection Reply et linitiateur envoie un Start Control Connection Connected afin dofficialiser louverture de la connexion de contrle. Le LNS retourne un accus de rception (message ZLB). Ces messages permettent lidentification et lauthentification des extrmits du tunnel, de connaitre la version de L2TP des deux instigateurs. 3.3.2.2. Etablissement d'une session L2TP Ltablissement de session est initi par lextrmit qui { demander ltablissement de la connexion de contrle. Il y a donc 2 cas de figures : 1. LAC initie la session: Il met un message Incoming Call Request vers le LNS qui retourne un Incoming Call Reply. Le LAC indique que la session est dsormais oprationnelle en envoyant un message Incoming Call Connected. 2. LNS initie la session : Il met un message Outgoing Call Request vers le LAC qui retourne un Outgoing Call Reply puis si la session est active, envoie un message Outgoing Call Connected. 3.3.2.3. Fermeture de la session Lune des extrmits peut demander la fermeture de session. Cette dernire envoie un message Call Disconnect Notify, contenant la raison de la fermeture (erreur ou fin de session). Lautre extrmit envoie en retour un message ZLB. Lorsque la dernire session est ferme, le tunnel doit galement tre ferm. 3.3.2.4. Fermeture de la connexion de contrle La fermeture est effectue en deux tapes : envoie dun message Stop Control Connexion Notify pour indiquer les causes de la fermeture et mission de la part de lautre extrmit dun message ZLB pour valider la fermeture. NB : Une demande de fermeture de la connexion de contrle peut avoir lieu mme sil reste des sessions sur le tunnel. Ces sessions sont fermes implicitement.

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

14

Protocoles de scurit 3.3.2.5. Rcapitulatif

A10

3.3.3. Scurit dans L2TP LIETF recommande dutiliser conjointement L2TP et IPsec pour amliorer la scurit. Il existe deux authentifications dans ltablissement dune connexion L2TP, au niveau PPP entre le client et le LAC et au niveau L2TP entre le LAC et le LNS. IPsec propose des mcanismes de chiffrement robustes comme ESP (Encapsulating Security Payload) et de gestion de cls de cryptages comme IKE (Internet Key Exchange). Pour amliorer le mcanisme dauthentification de L2TP qui nintervient quau dbut de la communication, IPsec propose avec le protocole AH (Authentication Header), une authentification de chaque paquet reu. Le client ngocie directement avec le LNS pour choisir les paramtres de scurit (protocole de cryptage, authentification des paquets, ). Le client utilise IPsec pour crypter les trames PPP avant de les envoyer au LAC. Ce dernier ajoute ces trames une encapsulation L2TP et les envoie au LNS. Celui-ci vrifie que la trame PPP a bien t code avec IPsec, quil na pas circul en clair (protocole ESP) et que lexpditeur est bien authentifi (protocole AH). Il retire les encapsulations IPsec et L2TP de la trame avant de lenvoyer au destinataire. Les donnes transitent sur le tunnel L2TP et sont protges par la suite de protocole IPsec.

4. IPsec
A lorigine de sa conception, le protocole IP na pas t pens dans une optique de scurit. Les donnes transites sur le rseau ne sont pas cryptes. Un paquet IP transitant sur le rseau est aisment cout et/ou modifi. Le protocole IP est sujet aux attaques de type rejeu (Un paquet IP est intercept par un tiers FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

15

Protocoles de scurit

A10

malveillant puis retransmis), par exemple une demande dauthentification par mot de passe. IP nassure pas que le message provient bien de lexpditeur indiqu dans lentte du paquet, il nassure pas non plus que le paquet na subit daltrations. IPsec est une suite de protocoles de scurit destine la scurisation de la couche rseau et donc des couches suprieures par encapsulation. Il ft { lorigine dvelopp pour le protocole IPv6. Ce dernier ayant mis du temps tre adopt, il fut adapt pour le protocole IPv4. IPsec est implment au niveau 3, niveau rseau, du modle OSI. Cela lui permet de se distinguer des protocoles de scurit antrieurs qui furent essentiellement dvelopps au niveau de la couche dapplication. La configuration pour chaque application nest donc plus ncessaire. A linstar de ses prdcesseurs, IPsec ne se limite pas { lutilisation dune seule mthode dauthentification ou dun seul algorithme de chiffrement. Cest la raison pour laquelle il est considr comme un cadre de standards ouverts, une solution volutive. Cependant sa grande complexit rend son implmentation dlicate. IPsec est souvent utilis en tant que composant des rseaux privs virtuels ou VPN (Virtual Private Network). Le but de cette technologie est dtablir une communication scurise (ou un tunnel) en chiffrant les donnes changes par des entits loignes, spares par un rseau non-scuris, ventuellement publique. Les deux machines ont limpression dtre sur un mme rseau local. IPsec fournit de multiples services de scurit, notamment afin dassurer les proprits des tunnels VPN : Authentification des extrmits : permet { chacun de sassurer de lidentit de son interlocuteur. Confidentialit des donnes changes : permet de chiffrer les donnes afin dviter que quelquun ne puisse les lire. Authenticit des donnes : permet de sassurer, pour chaque paquet chang, quil a bien t mis par la bonne machine (inbound packets) et quil est bien { destination de la seconde machine (outbound packets). Intgrit des donnes changes : permet de sassurer quaucun paquet na subit de modification pendant le trajet. Protection contre le rejeu des anciens paquets IP : permet de protger contre les attaques consistant capturer un ou plusieurs paquets pour ensuite le retransmettre. Bien que le protocole se veuille tre capable de supporter nimporte quelle combinaison dentits (nuds dun rseau), les implmentations ne sont pas tenues doffrir de telles possibilits. Nanmoins, la plupart supporte les 4 configurations suivantes: Dialogue entre deux htes Dialogue entre deux LAN { laide de passerelles de scurit (routeur, pare-feu) Dialogue entre deux htes traversant deux passerelles de scurit FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

16

Protocoles de scurit Dialogue entre un hte et une passerelle de scurit

A10

A noter que, IPsec peut tre aussi bien tre implment sur un systme final que sur une passerelle de scurit. La protection des datagrammes IP ou des protocoles suprieurs repose sur lun des protocoles IPsec, ESP (Encapsulating Security Payload) ou AH (Authentification Header). AH fournit lauthentification, lintgrit des donnes et lanti-rejeu. ESP fournit en plus des services offerts par AH la confidentialit optionnelle des donnes. Ces protocoles peuvent tre appliqus individuellement ou combins avec dautres. ESP et AH, sappuient sur les SA (security association) qui sont gnres et gres par le protocole IKE (Internet Key Exchange). Ils seront dtaills dans la partie suivante.

4.1. Architecture de scurit

4.1.1. Mode dchange Les protocoles AH ou ESP peuvent tre utiliss pour protger entirement un datagramme IP en lencapsulant dans un autre datagramme IP, ou bien pour protger les protocoles des niveaux suprieurs. Cette distinction est issue de deux modes diffrents de communication entre deux htes : le mode transport et le mode tunnel.

Fig. Paquet IP protg par IPsec avec le mode transport et le mode tunnel. Le mode transport nest utilis que dans le cas ou lentit de communication est aussi celle de cryptographie. Dans un paquet IPsec, on peut avoir deux adresses IP diffrentes, par exemple ladresse externe qui dsigne une passerelle de scurit dun rseau et ladresse interne qui dsigne une machine de ce rseau. 4.1.2. SA (Association de scurit) Lassociation de scurit est une connexion protge { laide dIPsec. Elle contient toutes les informations requises pour caractriser et changer des donnes protger. Ainsi, chaque SA contient des lments permettant de dterminer quel type de trafics ou paquets elle sapplique (adresse source, adresse destination, protocole de transport, ports). On outre, elle est unidirectionnelle. Alors, pour assurer un trafic bidirectionnel, lactivation de deux SA est ncessaire.

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

17

Protocoles de scurit

A10

Chaque SA est identifie par un unique SPI (Security Parameters Index), par ladresse IP de la destination (ventuellement une adresse de broadcast ou de multicast), ainsi que par le protocole utilis (AH ou ESP). Une SA est une entre dune SPD (security policy database). La SPD est consulte pendant le traitement de tous les datagrammes IP, entrants ou sortants, y compris les datagrammes non-IPsec. Pour chaque datagramme, trois comportements sont envisageables : le rejeter, l'accepter sans traitement IPsec, ou appliquer IPsec. Dans le troisime cas, la SPD prcise quels traitements IPsec appliquer (ESP, AH, mode tunnel ou transport, quel(s) algorithme(s) de signature et/ou chiffrement utiliser). Les SA actives sont regroupes dans une SAD (Security Association Database). 4.1.3. AH
AH est le premier et le plus simple des protocoles de protection des donnes qui font partie de la spcification IPsec (RFC 2402). Il a pour vocation de garantir : L'authentification L'unicit dun datagramme (Ce qui prvient les attaques par rejeu). L'intgrit vrifie que certains champs du datagramme IP n'ont pas t modifis pendant leur transmission : version (4 en IPv4, 6 en IPv6), longueur de l'en-tte (en IPv4), longueur totale du datagramme (en IPv4), longueur des donnes (en IPv6), identification, protocole ou en-tte suivante(en IPv6), adresse IP de l'metteur, adresse IP du destinataire. En mode tunnel, cest la totalit des champs, y compris les donnes du datagramme IP encapsul dans le datagramme protg par AH. AH n'assure pas la confidentialit. En effet, les donnes sont signes mais pas chiffres. Les algorithmes de signature supports sont: Requirement ----------MUST SHOULD+ MAY Authentication Algorithm (notes) ------------------------------HMAC-SHA1-96 [RFC2404] AES-XCBC-MAC-96 [RFC3566] HMAC-MD5-96 [FRC2403]

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

18

Protocoles de scurit

A10

Fig. Datagrammes IPSec AH 4.1.4. ESP

ESP est dtaille dans la RFC 2406. Contrairement AH, ESP ne protge pas les en-ttes des datagrammes IP utiliss pour transmettre la communication. Seules les donnes sont protges. En mode transport, il assure : L'intgrit, qui assure que les donnes n'ont pas t modifies depuis leur mission. La confidentialit des donnes, qui assure que les donnes ne peuvent pas tre lues par une autre entit que la partie de donnes. L'authentification L'unicit

Dans le mode tunnel, il fournit deux avantages supplmentaires : La confidentialit des flux de donnes : si la communication entre deux sousrseaux est chiffre l'aide d'un tunnel ESP, le volume total de donnes changes entre ces deux sous-rseaux est calculable par un attaquant, mais pas la rpartition de ce volume entre les diffrents systmes de ces sous-rseaux. La confidentialit peut s'tendre l'ensemble des champs, y compris les en-ttes du datagramme IP.

ESP ne spcifie pas non plus d'algorithme de signature ou de chiffrement particulier. Voici les algorithmes dencryptions et dauthentification disponibles : Requirement ----------MUST MUST MUSTSHOULD SHOULD NOT Encryption Algorithm (notes) --------------------------NULL [RFC2410] AES-CBC with 128-bit keys [RFC3602] TripleDES-CBC [RFC2451] AES-CTR [RFC3686] DES-CBC [RFC2405]

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

19

Protocoles de scurit
Requirement ----------MUST SHOULD+ MAY MAY Authentication Algorithm (notes) ------------------------------HMAC-SHA1-96 [RFC2404] AES-XCBC-MAC-96 [RFC3566] NULL [RFC2410] HMAC-MD5-96 [FRC2403]

A10

Fig. Datagrammes IPSec ESP 4.1.5. IKE Le protocole IKE (Internet Key Exchange) [RFC2409] tablit les connexions IPsec (ESP ou AH) aprs une ngociation des paramtres appropris (algorithmes utiliss, cls partages, dure de connexion) utilises par ces connections. Ce protocole permet deux types d'authentification, PSK (PreShared Key ou secret partag) pour la gnration de clefs de sessions ou l'aide de certificats/signatures RSA.

4.2. Fonctionnement
1. Echange des cls : Les deux systmes ngocient et tablissent une connexion bidirectionnelle de type IKE dans laquelle ils vont grer et mener les ngociations pendant ltape suivante, une telle SA peut administrer plusieurs tunnels. En utilisant IKE, les deux htes ngocient les IPsec SA afin dtablir des tunnels servant { transfrer des donnes. Comme IPsec SA est unidirectionnel, ces connexions sont toujours ngocies par paires pour tenir un trafic bidirectionnel. Une clef diffrente est utilise pour chaque direction. Le protocole UDP et le port 500 sont employs pendant cette tape de ngociation.

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

20

Protocoles de scurit

A10

2. Transfert de donnes : Une fois que la phase de ngociation est termine, nous avons les IPSec SA pour transfrer nos donnes encryptes, signes en utilisant ESP et/ou AH protocoles.

4.3. Inconvnients et problmes

Gestion manuelle des clefs : Les services d'unicit offerts par AH et ESP s'appuient sur des numros de squence initialiss 0 lors de la cration d'une SA et incrments lors de l'envoi de chaque datagramme. Ces numros de squence sont stocks dans un entier de 32 bits, qui ne doit jamais tre diminu. Pass 2^32, il est ncessaire de crer une nouvelle SA et donc une nouvelle clef. Ceci rend pnible la mise en uvre simultane de la gestion manuelle de clefs et de la protection contre la duplication de datagrammes. Broadcast et multicast : Dans le cas de multicast ou de broadcast, il y a multiple systmes finals associs une seule SA. Il faut donc des systmes ou des personnes pour coordonner tous les groups pour associer un SPI chaque groupe et communiquer ensuite les IPsec informations du groupe aux ses membres lgitimes. Par consquence, des problmes de performances d'une part, et des difficults qu'une simple augmentation de la puissance de calcul ne saurait rsoudre, comme la vrification des numros de squence. Firewalls : Le filtrage de datagrammes IPsec est dlicat pour 2 raisons : 1. Les RFC ne prcisent pas si, sur un systme remplissant simultanment les fonctions de passerelle de scurit et de firewall, le dcodage de l'IPsec doit avoir lieu avant ou aprs l'application des rgles de firewalling. 2. Il n'est pas possible au code de firewalling de lire certaines donnes, par exemple des numros de port, dans des donnes chiffres, ou transmises dans un format qu'il ne connat pas.

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

21

Protocoles de scurit

A10

NAT : Thoriquement, toute translation d'adresse sur un datagramme IPsec devrait tre vite, car ce type d'opration modifie le contenu des datagrammes, ce qui est incompatible avec les mcanismes de protection de l'intgrit des donnes d'IPsec.

4.4. Conclusion
Le protocole IPsec est destin la protection des datagrammes IP en utilisant une famille de sous-protocoles (AH, ESP) avec le protocole IKE. Il peut tre utilis en mode transport ou bien en mode tunnel. LIPsec ne soccupe pas de lauthentification de lutilisateur mais de la machine. IPsec est en constante volution. Il existe de nombreux drafts son sujet ou sur des sujets annexes, par exemple IPsec NAT-Traversal.

5. TLS/SSL
5.1. Introduction
Transport Layer Security (TLS), anciennement nomm Secure Sockets Layer (SSL), est un protocole de scurisation des changes sur Internet, dvelopp l'origine par Netscape (SSL version 2 et SSL version 3). Il a t renomm en Transport Layer Security (TLS) par l'IETF suite au rachat du brevet de Netscape par l'IETF en 2001. SSL fonctionne de manire indpendante par rapport aux applications qui l'utilisent, il est obligatoirement au dessus de la couche TCP et certains le considrent comme un protocole de niveau 5 (couche session). SSL permet d'assurer les services de scurit suivants: Confidentialit : elle est obtenue par l'utilisation d'algorithmes de chiffrement symtrique : ceux de blocs comme DES, FORTEZZA, IDEA, 3DES ou RC2 ; ceux de flots comme RC4.

Intgrit : l'intgrit des donnes est assure par l'utilisation de MAC (Message Authentification Code) bass sur les fonctions de hachage MD5 (16 octets) ou SHA-1 (20 octets). Authentification : SSL permet l'authentification des 2 extrmits (authentification client facultative) bas sur des certificats X.509, et l'authentification des donnes grce aux MAC.

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

22

Protocoles de scurit

A10

5.2. Droulement des changes SSL

1. Le client envoie un message ClientHello proposant des options SSL. 2. Le serveur rpond avec un message ServerHello slectionnant les options SSL. 3. Le serveur envoie ses informations de cl publique dans le message ServerKeyExchange. 4. Le serveur conclut sa part de la ngociation avec le message ServerHelloDone. 5. Le client envoie les informations de cl de session (chiffre avec la cl publique du serveur) dans le message ClientKeyExchange. 6. Le client envoie un message ChangeCipherSpec pour activer les options de ngociation pour tous les futurs messages qu'il enverra. 7. Le client envoie un message Finished afin de laisser au serveur le soin de vrifier les options nouvellement actives. 8. Le serveur envoie un message ChangeCipherSpec pour activer les options de ngociation pour tous les futurs messages qu'il enverra. 9. Le serveur envoie un message Finished pour permettre au client de vrifier les options nouvellement actives.

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

23

Protocoles de scurit En rsum, les changes dfinis par le protocole SSL se droulent en deux phases: 1) Authentification du serveur

A10

Suite la requte d'un client, le serveur envoie son certificat au client et lui liste les algorithmes cryptographiques qu'il souhaite ngocier. Le client vrifie la validit du certificat l'aide de la cl publique du CA (Certificate Authority) contenue dans le navigateur. Si le certificat est valide, le client gnre un prmaster secret (PMS) de 48 octets qui servira driver le master secret (MS) de mme taille, 48 octets, ce qui reprsente l'entropie maximale de la cl. Ce PMS est chiffr avec la cl publique du serveur puis transmis ce dernier. Les donnes changes par la suite entre le client et le serveur sont chiffres et authentifies l'aide de cls drives de la cl matre. 2) Authentification du client (optionnelle) Le serveur (et seulement lui) peut demander au client de s'authentifier en lui demandant tout d'abord son certificat. Le client rplique en envoyant ce certificat puis en signant un message avec sa cl prive (ce message contient des informations sur la session et le contenu de tous les changes prcdents). Remarques L'authentification du client est facultative et au bon vouloir du serveur. Elle est en fait rarement utilise dans la vie courante (qui possde une paire de cls RSA certifie). L'authentification du rseau intervient dans tous les cas avant celle du client, ce qui est un gage de scurit accrue. Comme dans IPSec (IKE phase 1), l'authentification reprend les changes prcdents et valide ainsi tous les handshake (triple poignes de main). Notez enfin que seule la cl publique du serveur est utilise pour faire du chiffrement, celle du client ne sert que pour de la signature.

5.3. Les sous-protocoles de SSL

Le protocole SSL est constitu de quatre sous-protocoles: 5.3.1. Le protocole Handshake Ce protocole permet l'authentification obligatoire du serveur, celle du client est optionnel, de mme il permet de ngocier les suites de chiffrement qui seront utilises lors de la session. 5.3.2. Le protocole ChangeCipherSpec (CCS) Ce protocole comprend un seul et unique message (1 octet) qui porte le mme nom que le protocole, il permet d'indiquer au protocole Record la mise en place des algorithmes de chiffrement qui viennent d'tre ngocis. 5.3.3. Le protocole SSLAlert Ce protocole gnre des messages d'alerte lorsque des erreurs surviennent sur la liaison client/serveur. Les messages sont composs de 20 octets, le premier FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

24

Protocoles de scurit tant soit fatal soit warning. Si le niveau de criticit du message est fatal, la connexion SSL est abandonne. Le deuxime octet est utilis pour le code d'erreur. Messages du protocole SSLAlert: 5.3.3.1. Erreurs fatales bad_record_mac : rception d'un MAC erron (Message Authentification Code) decompression_failure : les donnes appliques la fonction de compression sont invalides handshake_failure : impossibilit de ngocier les bons paramtres illegal_parameter : un paramtre chang au cours du protocole Handshake ne correspondait pas avec les autres paramtres unexpected_message : message non reconnu. 5.3.3.2. Warnings bad_certificate : le certificat n'est pas bon certificate_expired : certificat prim certificat_revoked : certificat rvoqu certificat_unknown : certificat invalide pour les raisons prcises prcdemment close_notify : la fin d'une connexion no_certificate : rponse ngative une demande de certificat unsupported_certificate : le certificat reu n'est pas reconnu 5.3.4. Le protocole SSLRecord Ce protocole intervient aprs l'mission du message ChangeCipherSpec. Il permet de garantir : la confidentialit l'aide du chiffrement des donnes l'intgrit l'aide de gnration d'un condenst (un hash)

A10

5.4. Les attaques et faiblesses de SSL

SSL est thoriquement vulnrable aux attaques par force brutes en cas d'utilisation de cls 40 bits, il est donc conseill d'utiliser des cls de 128 bits. SSL est trs vulnrable aux attaques par le milieu (man in the middle): l'attaquant intercepte (physiquement) la requte du client et se fait passer pour le serveur auprs de lui, tout en se faisant passer pour un client auprs du serveur lgitime. Il reoit donc la totalit du flux suppos protger. SSL est faible dans le sens o il n'impose pas l'authentification client (ce serait d'ailleurs difficilement grable en pratique). SSL est faible enfin car il prsente des lacunes dans son implmentation, notamment en ce qui concerne la vrification des certificats des serveurs. En effet, le client devrait vrifier la signature, la validit ainsi que le statut de rvocation du certificat (au moyen de CRL ou du protocole OCSP) et devrait FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

25

Protocoles de scurit

A10

s'assurer que le CA concern appartient bien aux CA auxquels il fait confiance. Or cela n'est pas obligatoire, et peut permettre un attaquant de substituer sa propre cl publique celle du serveur original puis de rediriger le trafic vers un site de phishing tout en faisant croire au client qu'il communique bien avec son serveur lgitime. Il est donc important de bien vrifier les URL. SSL est galement vulnrable des attaques plus pousses, bases sur des proprits cryptographiques. L'utilisation de certificats par exemple ncessite une grande vigilance (date de validit, multitude de CA inconnus certifiant tout et n'importe quoi... Il suffit de jeter un coup d'il { la liste contenue dans votre navigateur pour s'en rendre compte). Il existe galement des attaques par force brute sur l'change de la cl symtrique (2^20 essais) ou des attaques dites de rollback dans lesquelles l'attaquant cherche modifier le choix des algorithmes d'changes de cls de faon ce que les 2 entits n'utilisent pas les mmes (RSA et DH par exemple). Ainsi, cet attaquant pourra dchiffrer le message car les paramtres fournit par le serveur dans le cas d'un algorithme n'offrent aucune scurit si on les applique un autre... Cette attaque peut-tre ralise si une session 3.0 est rsume en session 2.0 par exemple.

5.5. Conclusion
Le protocole SSL est actuellement le seul protocole de scurisation dploy et utilis grande chelle, son grand avantage tant sa transparence par rapport au protocole TCP. Il garantit l'authentification, la confidentialit et l'intgrit des donnes. Avec son architecture modulaire, il ne se limite pas des applications traditionnelles, puisque il intgre les rseaux sans fil comme le WAP (Wireless Access Protocol)

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

26

Protocoles de scurit

A10

6. SSH
6.1. Introduction
6.1.1. Contexte Les protocoles standards de la couche application ne supportent que peu de proprits scurises : en gnral lidentification et lauthentification par mot de passe, rarement la confidentialit, lintgrit, Exemples : FTP (File Transfer Protocol) Lauthentification par mot de passe est le plus souvent ralise en clair Le fichier est transmis en clair POP (Post Office Protocol) Lauthentification par mot de passe est le plus souvent ralise en clair Les messages sont transmis en clair Le protocole SSH a donc t conu dans loptique de remplacer certaines applications (rlogin, telnet, rsh) et de rendre les autres applications plus scurises. 6.1.2. Dfinition SSH (Secure Shell) est un protocole de communication scuris situ la couche dapplication du modle OSI. Ce protocole couvre l'authentification, le chiffrement et l'intgrit des donnes transmises sur un rseau. On dfinit les termes ci-dessous : Authentification : Elle dtermine de manire fiable l'identit de quelqu'un. Si vous tentez de vous connecter sur un compte situ sur un ordinateur distant, SSH vous demande une preuve numrique de votre identit. Si vous russissez ce test, vous pourrez vous connecter, dans le cas contraire, SSH rejette la connexion. Chiffrement : Il chiffre les donnes pour quelle soit incomprhensible sauf pour les destinataires voulus. Cela protge les donnes lorsquelles passent sur le rseau. Intgrit : Elle garantit que les donnes passant sur le rseau ne seront pas modifies. Si un tiers capturait et modifiait des donnes en transit, SSH le dtecterait. En bref, SSH impose un change de cls de chiffrement en dbut de connexion. Par la suite toutes les trames sont chiffres. Il devient donc impossible d'utiliser un sniffer pour voir ce que fait l'utilisateur.

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

27

Protocoles de scurit

A10

6.2. Survol des caractristiques des SSH

Que peut donc faire SSH ? Parcourons quelques exemples illustrant les caractristiques principales de SSH, telles que les connexions distantes scurises, la copie de fichier scurise et lappel scuris de commandes distantes. 6.2.1. Connexions scurise distance Supposons que vous ayez des comptes sur plusieurs ordinateurs connects Internet. Puis vous utilisez un programme tel que telnet pour vous connecter sur vos comptes. Malheureusement, telnet transmet en clair votre identifiant et votre mot de passe sur linternet, ou une personne malicieuse peut les intercepter. De plus, votre session entire est lisible par un espion du rseau. SSH vite totalement ces problmes. Le client vous authentifie sur le serveur SSH de lordinateur en utilisant une connexion chiffre, ce qui signifie que votre identifiant et votre mot de passe sont chiffrs avant de quitter votre machine locale. Puis, le serveur vous autorise vous connecter et votre session entire est chiffre lorsquelle circule entre le client et le serveur. Comme ce chiffrement est transparent, vous ne verrez pas de diffrence entre telnet et SSH

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

28

Protocoles de scurit

A10

6.2.2. Transfert scuris de fichier Supposons que vous souhaitiez transfrer un fichier qui contient des secrets industriels, devant tre protgs des regards indiscrets. Un programme classique de transfert de fichiers, comme FTP, ICP ou mme le courrier lectronique noffre pas de solution scurise car un tiers peut intercepter et lire les donnes. Avec SSH, le fichier peut tre transfr en toute scurit entre les machines laide dune seule commande de copie scurise.

6.3. Droulement dune session SSH2

1) Le client contacte le serveur En tablissant une connexion TCP sur le port 22 (SSH) 2) Serveur et client schangent les versions de SSH quils supportent

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

29

Protocoles de scurit

A10

3) Client et Serveur schangent : des informations sur les algorithmes utiliser par la suite algorithme pour lchange de cl algorithmes de chiffrements symtriques pour assurer la confidentialit algorithmes de hachage pour le contrle dintgrit une cl secrte de session cette cl est transmise en utilisant un algorithme dchange de cl scuris

4) Client et Serveur sauthentifient mutuellement travers le canal scuris le serveur est authentifi par un challenge utilisant sa cl prive le client vrifie le challenge avec la cl publique du serveur le client est authentifi soit : par un mot de passe par un challenge utilisant sa cl prive (le serveur vrifie le challenge avec la cl publique du client) 5) Le client peut ensuite demander lexcution de commandes distantes protocole bas sur lchange en requte rponse de paquets chiffrs 6) Lorsque le client a termin, il met fin la connexion

6.4. Architecture du protocole SSH-2

La version actuelle est SSH2, elle est plus volu mais demeure compatible avec SSH1. SSH2 est divis en 3 couches : la couche transport, la couche dauthentification et la couche de connexion.

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

30

Protocoles de scurit

A10

6.4.1. La couche de transport (SSH-TRANS) Elle gre lchange initial des cls et lauthentification du serveur Elle met en place le cryptage, la compression et la vrification d'intgrit. Elle expose la couche suprieure une interface pour envoyer et recevoir des paquets en clair. 6.4.2. La couche dauthentification (SSH-AUTH) Elle est base sur la couche de transport. Elle gre l'authentification des clients et fournit un certain nombre de mthodes d'authentification. L'authentification est axe sur le client. Le serveur rpond simplement aux demandes d'authentification du client. Les mthodes d'authentification largement utilises sont les suivants : Mot de passe: L'authentification par mot de passe est simple. Tous les programmes nutilisent nanmoins pas cette mthode. Cl publique: une mthode d'authentification par cl publique, contient en gnral au moins un DSA ou une paire de cls RSA. Il existe d'autres implmentations qui utilisent des certificats de type X.509.

6.4.3. La couche de connexion (SSH-CONN) Elle est base sur les couches transport et authentification et dfinit le concept de canaux. Les canaux standards incluent: shell terminal, SFTP et SCP direct-tcpip pour les connexions du client vers le serveur forwarded-tcpip pour les connexions du serveur vers le client

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

31

Protocoles de scurit

A10

7. DNSSEC
7.1. Introduction
Domain Name System Security Extensions (DNSSEC) est une suite de spcifications de lIETF ayant pour buts de scuriser les informations fournies par le protocole DNS et de combler les failles de scurit de ce dernier. Dans la pratique, DNSSEC se prsente comme un panel dextensions du protocole DNS garantissant aux clients dun serveur DNS lauthentification des sources de donnes, le dni dexistence authentifi, lintgrit des donnes, mais pas la disponibilit ou la confidentialit. Pour prsenter DNSSEC, il convient de rappeler le fonctionnement de DNS afin de mettre en vidence les failles de scurit qui ont conduit { llaboration de DNSSEC.

7.2. DNS
7.2.1. Utilit DNS permet de rsoudre des noms de domaines, c'est--dire de faire la correspondance entre un nom de domaine et une adresse IP. 7.2.2. Exemple Lorsque lon souhaite tlphoner { quelquun, on utilise son numro de tlphone, or il est souvent difficile de retenir ce dernier, on se souvient plutt du nom de la personne que lon souhaite contacter. On utilise donc un annuaire pour rsoudre le nom de la personne, c'est--dire de trouver son numro de tlphone partir de son nom. 7.2.3. Fonctionnement Le systme de noms de domaines repose sur une architecture hirarchique et distribue. 7.2.3.1. Hirarchique Un nom de domaine se dcompose en sous-domaines formant ainsi un arbre Exemple : rsolution de http://ent.utc.fr (Le point symbolise la racine)
.

net

com

fr

uk

utc

ent

tice

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

32

Protocoles de scurit

A10

7.2.3.2. Distribu Larchitecture hirarchique des noms de domaine fait quil est ais de proposer un algorithme permettant de dlguer la rsolution de sous-domaines plusieurs serveurs DNS diffrents. La rsolution est alors effectue par un serveur DNS rcursif. Exemple : rsolution de http://ent.utc.fr
c.gtld-servers.net

Serveur DNS racine

ns0.pasteur.fr

fr NS ? 1

2 ns0.pasteur.fr utc.fr NS 3 4 orion.utc.fr NS

Serveur DNS rcursif 5 ent.utc.fr NS 6 195.83.155.151 ent.utc.fr A ? 0 7 195.83.155.151

orion.utc.fr

Client 7.2.3.3. Optimis Lorsquun serveur DNS parvient rsoudre une adresse, il la place en cache, de cette manire, la prochaine fois quon lui demandera de rsoudre la mme adresse, il fournira la rponse quil a mmorise. La dure de vie (TTL) dune rsolution dans le cache peut tre de plusieurs jours. Cela permet doptimiser et de limiter le nombre de requtes. On comprend bien lintrt de la mise en cache en prenant lexemple du site google, sans cesse consult. FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

33

Protocoles de scurit

A10

7.2.4. Enregistrements DNS ou Resource Records (RR) La plus petite entit de donnes qui peut circuler entre un serveur DNS et une autre entit sur le rseau est lenregistrement. Nous allons dtailler son format : Zone TTL Classe Type RData ent.utc.fr. 1D IN A 195.83.155.151 Zone : IP ou nom de domaine. TTL (Time To Live) : Dure de vie dans le cache Classe : IN pour Internet, CH pour Chaos. Les requtes de type CH permettent de connaitre la version du logiciel et la liste de ses auteurs. SOA (Start Of Authority) : Ce champ dcrit le serveur DNS faisant autorit sur la zone. Nom du DNS Email de la personne en charge Numro de srie (Il change chaque mise jour) RDATA Temps de rafraichissement des transferts de zones (synchronisation entre DNS secondaire et primaire) Dlai dexpiration dune tentative de transfert de zone Le TTL par dfaut si il est omis dans les autres enregistrements Type NS (Name Server) : Ce champ dsigne les serveurs de noms qui peuvent permettent de rsoudre le nom de la zone interroge. Liste des noms des serveurs DNS qui peuvent permettent de rsoudre RDATA le nom de la zone interroge Type Type MX (Mail Exchange) : Ce champ dsigne les serveurs de messagerie. RDATA Liste des serveurs de messagerie et de leur priorit A (Address) : Ce champ fait correspondre un nom de domaine et une adresse IP. RDATA LIP correspondant au nom de domaine spcifi dans Zone. Type PTR (Pointer) : Ce champ fait correspondre une adresse IP et un nom de domaine. Ce mcanisme sappelle la rsolution inverse. RDATA Le nom de domaine correspondant { lIP spcifie dans Zone. Type CNAME (Canonical Name) : Ce champ permet de faire correspondre Type un nom canonique avec un alias. Cela est fort utile pour lhbergement mutualis. RDATA Le nom de domaine correspondant { lalias spcifi dans Zone. NB : Nous avons uniquement dtaill les enregistrements principaux qui permettent de comprendre le fonctionnement global de DNS.

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

34

Protocoles de scurit

A10

7.3. Failles de scurit

Nous allons dsormais dtailler plusieurs types dattaques. Non pas dans le but dtre exhaustifs mais plutt dans loptique de donner une ide des problmes de scurit de DNS, cela afin de mieux comprendre les apports de DNSSEC. 7.3.1. Interception des paquets et fabrication dune fausse rponse Les serveurs DNS communiquent par paquets uniques sans aucune forme de chiffrement ou de signature. Linterception dune requte DNS est donc aise. La fabrication dune fausse rponse lest encore plus, en effet, les paquets DNS sont seulement authentifis par un numro de requte. 7.3.2. Attaque de type man in the middle Lattaquant intercepte une requte DNS et y rponds avant le serveur DNS. Sa rponse peut contenir ladresse IP dun site de phishing. Exemple : 1. Lutilisateur tape http://www.mabanque.fr dans son navigateur. 2. Le navigateur envoie une requte au serveur DNS pour connaitre ladresse du site mabanque.fr. 3. Lattaquant lintercepte et rponds au client avant le serveur, sa rponse contiendra ladresse IP dun site malveillant imitant en tout point le site mabanque.fr et permettant { lattaquant de rcuprer les identifiants de connexion de lutilisateur.

Serveur DNS

Interception Pirate

IP de mabanque.fr

www.mabanque.fr A ? IP dun site de phishing

Client

NB : Lattaquant peut galement avoir pour but dempcher laccs { certains quipements, de perturber ou bloquer le service DNS (Notamment en reniant lexistence dun nom de domaine).

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

35

Protocoles de scurit

A10

7.3.3. Corruption de donnes Si lun des maillons de la chaine DNS trahit en rpondant une rponse errone au serveur DNS rcursif, de mme que dans lexemple prcdent, lutilisateur recevra une rponse errone. Exemple : 1. Lutilisateur tape http://www.mabanque.fr dans son navigateur. 2. Le navigateur envoie une requte au serveur DNS pour connaitre ladresse du site mabanque.fr. 3. Le serveur DNS rcursif interroge rcursivement les serveurs DNS, lorsque lun deux contrl par lassaillant rpond ladresse dun serveur DNS frauduleux, ce qui condamne.

Serveur DNS racine

c.gtld-servers.net

Pirate

fr NS ? 1

2 ns0.name.fr

Piratage

mabanque.fr NS ? 3 Serveur DNS rcursif 4 IP dun site de phishing

jour frauduleuse s

ns0.name.fr

Traitre

mabanque.fr A ?

IP dun site de phishing

Client

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

36

Protocoles de scurit

A10

7.3.4. Empoisonnement du cache DNS Nous avons vu prcdemment que le serveur garde en cache les rsultats des rsolutions quil a dj{ effectues rcemment. Par consquent, en utilisant les techniques prcdentes, on peut corrompre le cache dun DNS en lattaquant au moment ou le cache dun site { expir. Exemple : Le pirate interroge le serveur DNS pour connaitre lIP du site mabanque.fr. Le serveur DNS interroge rcursivement les autres serveurs DNS. Lun des serveurs est pirat et rend donc un rsultat erron. Le serveur DNS rcursif garde en cache le rsultat erron de la rsolution. NB : La encore lattaquant peut galement avoir pour but dempcher laccs { certains quipements, de rediriger un lien de tlchargement vers un virus, de perturber ou bloquer le service DNS (attaque par dni de service) pour tous les utilisateurs du DNS. Serveur DNS racine
c.gtld-servers.net

fr NS ? 1

2 ns0.name.fr

mabanque.fr NS ? 3 Serveur DNS rcursif 4 IP de mabanque.fr + Mises jour dun domaine errones mabanque.fr A ? 0

ns0.name.fr

Traitre

IP de mabanque.fr Piratage

Pirate FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

37

Protocoles de scurit 7.3.5. Usurpation didentit du DNS primaire Elle permet dempoisonner le cache du DNS secondaire en passant par les transferts de zone du DNS primaire.

A10

NB : Le transfert de zone consiste en la rpercussion sur le DNS secondaire des modifications apportes au DNS primaire. Priodiquement, le secondaire interroge le primaire pour savoir sil y a des mises jour dans la table de correspondance des noms, ce dernier lui rpond la liste des modifications. Exemple : 1. Le serveur DNS secondaire interroge le serveur DNS primaire propos des modifications faites sur la table de correspondance des noms. 2. Le pirate intercepte cette demande, et rponds une liste de correspondance errone. Serveur DNS redonds 1 Secondaire Demande de transfert de zone Primaire

Rsolutions

Rponse Interception Rponse corrompue

Pirate NB : Il peut y avoir plusieurs serveurs DNS secondaires pour un primaire, cependant, dans la pratique, il ny a gnralement quun seul DNS secondaire. Il est de bon ton de situer ces derniers sur un segment diffrent du rseau.

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

38

Protocoles de scurit

A10

7.3.6. Attaque de type DDos Une attaque de type DDoS (Distributed Denial Of Service ou dni de service distribu) consiste en linondation coordonne dun rseau par un lancement massif de requtes { laide dun parc entier de machines. Dans lexemple prcdent, les utilisateurs interrogeront le DNS secondaire seulement si le primaire vient tomber, cette attaque est donc incomplte, il faudrait par exemple poursuivre avec une attaque de type DDoS sur le DNS primaire qui permettrait de le faire tomber. ce moment la, le serveur que lon a prcdemment corrompu prendra le relai et diffusera des informations errones.

Serveur DNS redonds 2 Secondaire corrompu Primaire

Attaque DDos

Pirates

NB : La puissance dune attaque de type DDos est quantifie par le dbit sortant de lattaquant et dirig vers le serveur DNS. Elle se chiffre en Gbits/s. A titre dexemple, le 7 Aout 2010, a eut lieue une attaque de type DDos de 50Gbits/s sur le fournisseur de services DNS Made Easy. 7.3.7. Inventaire Linventaire consiste { dresser une liste des ressources dun domaine en interrogeant son serveur DNS, on mmorise les noms de domaine quon a russi rsoudre. Etant donn que ces noms de domaines illustrent souvent leurs fonctions ou leur emplacement, un individu malveillant peut se servir de cette cartographie du rseau pour planifier une attaque. 7.3.7.1. Attaque par dictionnaire Cette attaque consiste en lutilisation dun dictionnaire de mots courants afin de dresser linventaire dun domaine (par exemple on pourrait essayer de dresser linventaire du domaine utc.fr. en essayant des noms de domaine comme comptabilite.utc.fr, paiement.utc.fr, ftp.utc.fr, etc.). FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

39

Protocoles de scurit Des petits logiciels comme txdns permettent de dresser linventaire dun domaine en spcifiant un dictionnaire.

A10

7.3.7.2. Attaque par force brute Comme la prcdente, cette attaque teste une partie des combinaisons possibles de noms de domaine sur un serveur DNS. En revanche, ici on teste toutes les combinaisons de chaines alphanumriques. Txdns permet galement de raliser ceci.

7.4. DNSSEC
7.4.1. Prsentation DNSSEC repose sur lutilisation de la cryptographie asymtrique. Nous avons vu prcdemment quun nom de domaine tait en fait une branche dun arbre appel domaine. Typiquement, un serveur DNS rcursif interrogera tour tour les serveurs DNS afin de retrouver ladresse IP dun nom de domaine. Avec lutilisation de DNSSEC, les serveurs DNS possdent chacun un couple cl publique/cl prive permettant ainsi de signer numriquement les informations changes. NB : Outre laspect de la scurit, DNSSEC apporte galement la compatibilit avec IPv6 et linteroprabilit entre les deux systmes dadressage. 7.4.2. Chaine de confiance La chaine de confiance consiste en lauthentification en cascade des diffrents serveurs DNS consults par un serveur rcursif en partant dun TLD (Top Level Domain ou Serveur DNS racine, il en existe 13 en tout, ce sont eux qui soccupent des domaines de premier niveau tels que .fr, .com, .net, etc.). 7.4.3. Nouveaux types denregistrements DNS DNSSEC apporte de nouveaux types denregistrement : Type DNSKEY : Cet enregistrement contient la cl publique du serveur DNS. Un flag permettant de savoir si la cl est de type ZSK ou KSK. Lidentifiant du protocole : Ici 3 pour DNSSEC. Lalgorithme de cryptage : DSA/SHA1, RSA/SHA-256, RSA/SHA-512 RDATA etc. numrots de 0 255 avec bien sur des plages didentifiants libres pour les algorithmes de cryptage du futur. La cl publique. Les cls de type ZSK sont utilises pour signer les enregistrements, elles ne sont pas publies et doivent tre changes rgulirement. Les cls de type KSK sont utilises pour signer les cls de type ZSK, elles sont plus grandes et peuvent donc tre changes moins souvent. DS (Delegation Signer) : Cet enregistrement contient un hash de la cl publique du serveur DNS. Lidentifiant de la cl hache. RDATA Lalgorithme de cryptage utilis par la cl hache. Lalgorithme de hachage : SHA-1, SHA-256, etc. numrots de 0 255 Type FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

40

Protocoles de scurit

A10

avec bien sur des plages didentifiants libres pour les algorithmes de hachage du futur. Le hash de la cl. Lenregistrement DS est contenu au sein de la zone parente. Typiquement un client interrogera le champ DNSKEY dun serveur DNS et vrifiera son authenticit en comparant son hash au champ DS de la zone parente. En procdant ainsi depuis un point dentre scuris, on construit une chaine de confiance. RRSIG (Resource Records Signature) : Cet enregistrement contient Type la signature numrique dun enregistrement afin de garantir son authenticit. Le type de lenregistrement sign (A, NS, PTR, etc.). Lalgorithme utilis pour gnrer la signature (Suivant la mme nomenclature que pour un enregistrement de type DNSKEY). RDATA Lidentifiant de la cl publique { utiliser pour vrifier lenregistrement. La priode de validit de la signature. Le nom du propritaire de la cl. La signature. NB : Tous les enregistrements sont signs et sont donc associs un champ RRSIG except les enregistrements de type RRSIG (On ne va pas signer une signature) et les Glue Records (Ce sont les enregistrements mis en cache, le DNS qui en possde na pas lautorit de les signer). NSEC (Next SECure) : Cet enregistrement contient les noms de Type domaine du prcdent et du prochain nom de domaine sign du serveur (dans lordre lexicographique). RDATA Le prochain nom dans la zone. Lors dune rponse ngative, on nenvoie aucun contenu, donc on ne peut rien signer, par consquent on ne peut pas garantir la vracit de la non-existence du nom de domaine. Pour remdier cela, on utilise une rponse de type NSEC. Cet enregistrement contient les noms de domaine du prcdent et du prochain nom de domaine sign du serveur, ainsi, le rsolveur na qu{ vrifier linformation de non existence en interrogeant le prcdent nom de domaine. Puis avec une RR (Record Request) de type NXT (Next) on obtiendra le nom du prochain nom de domaine, on en dduira quil ny a pas de noms de domaines dans cet intervalle. NSEC ouvre une faille de scurit de type Inventaire. On essaie de rsoudre une adresse qui nexiste pas, on obtient le nom de domaine qui suit, on incrmente ce nom, et on ritre. A lissue de cet algorithme on possde une cartographie du rseau. Pour parer cette nouvelle vulnrabilit (qui ft dcouverte seulement en 2008), NSEC3 ft mis en place. FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

41

Protocoles de scurit

A10

NSEC3 (Next SECure) : Cet enregistrement contient le prochain hash dun nom de domaine dans lordre lexicographique. RDATA Le prochain hash et le prcdent hash dun enregistrement de la zone. Type 7.4.4. Gestion des cls DNSSEC utilise plusieurs cls, cependant, une cl tant toujours cassable au bout dune certaine dure en tirant partie de systmes distribus. Il faut mettre en place un systme de roulement des cls.

7.5. Conclusion
Lutilisation de tous ces nouveaux enregistrements permet de garantir lauthentification des sources de donnes, le dni dexistence authentifi ainsi que lintgrit des donnes, mais pas la disponibilit ou la confidentialit.

8. Conclusion
En conclusion, on remarque que la cryptographie asymtrique est la pierre angulaire de la scurit et est la cl de voute de tous les protocoles que nous avons prsents. La puissance des machines augmentant sans cesse et la cryptanalyse avanant de paire avec la cryptographie, il semble que les enjeux des rseaux seront encore tourns vers la scurit pendant de nombreuses annes.

9. Bibliographies
The Secure Shell The Definitive Guide IPSec: The New Security Standard for the Internet, Intranets, and Virtual Private Networks, Second Edition Naganand Doraswamy, Dan Harkins www.laissus.fr www.cgsecurity.org www.ietf.org www.freeswan.org www.frameip.com www.securiteinfo.com www.commentcamarche.net wapiti.telecom-lille1.eu www.tcpipguide.com www.idsa.prd.fr en.wikipedia.org fr.wikipedia.org

FAUVET Romain - GEORGE Paul - LONG Weiquan - VU Xuan

42