Protocoles

Protocoles

Cette page est un résumé des protocoles courants.

Protocoles de couche 2

Ethernet

Ethernet

Protocoles de couche 3

IP : Internet Protocol

Principal protocole de communication sur les réseaux, protocole de la couche 3, protocole « typique » des routeurs, permet le routage et les sous-réseaux. Il donne les adresses IP, est responsable de l’encapsulation des données en datagrammes (paquets).
Chaque paquet a une en-tête et un contenu, l’en-tête change selon le procotole de couche 4 utilisé (TCP, UDP).

L’en-tête d’un paquet contient entre autres le MTU (Maximum Transmission Unit) de chaque PDU (Protocol Data Unit), soit la taille maximale que peut avoir un paquet sur une liaison donnée.

Le protocole IP peut être configuré pour donner des priorités aux paquets : Urgent, Débit Important, Haute Fiabilité…

 

IPv4:

cf IPv4

IPv6:

cf : Cisco (Chap 7)

ARP (Adress Resolution Protocol) :

ARP fait correspondre les adresses MAC aux adresses IP afin de permettre la communication au sein d’un réseau. ARP remplit deux fonctions:

• La résolution des adresses IPv4 en adresses MAC
• La tenue d'une table des mappages (table ARP ou cache ARP), stockée dans la RAM.

Une machine qui arrive sur un réseau commence par récupérer une IP via DHCP (ou utilise la sienne), puis elle broadcast des demandes ARP sur le broadcast ff:ff:ff:ff:ff:ff pour remplir sa table (elle ne le fais pas systématiquement, mais seulement quand elle doit communiquer avec une autre machine). En effet elle a besoin des MAC pour pouvoir communiquer sur le réseau : Elle connaît normalement déjà la gateway et le serveur DNS, soit par configuration manuelle soit par DHCP, mais pas forcément leurs adresses MAC. Les messages sont de type « Who has 192.168.1.15 ? Tell 192.168.1.1 ».  Si la machine doit communiquer sur le même réseau, elle demande l'adresse MAC de son correspondant; sinon elle demande celle de la passerelle (elle sait qu'il faut demander l'adresse MAC de la passerelle si l'adresse réseau de l'IP dest est différente de la sienne).

UNe requête ARP est encapsulée dans une trame ethernet sans en-tête IPv4. Il contient : L'adresse IPv4 de la cible, l'adresse MAC cible qui n'est pas connue est donc pas renseignée (le champ est vide), l'adresse MAC source, et celle de destination (le broadcast), ainsi que le type (0x806). Seul le périphérique concerné répond (si il ne répond pas, le paquet est abandonné), en contenant les mêmes champs mais remplis correctement.

Les entrées de la table ARP sont supprimées au bout d'un certain temps si elles ne sont pas utilisées (2 minutes pour Windows, par exemple). Il est à noter qu'un réseau dont on allume toutes les machines en même temps sera innondé par les requêtes ARP, et donc ralenti pendant un certain temps, si celles-ci accèdent toutes aux ressources du réseau.

ARP spoofing : l'usurpation ARP consiste à répondre aux requêtes ARP en se faisant passer pour un périphérique que l'on est pas, pour aspirer du trafic. Les switches d'entreprise ont des méthodes de prévention de l'ARP spoofing appellées inspections ARP dynamiques.

Protocoles de couche 4

 

TCP (Transfer Control Protocol)

L’un des principaux protocoles de la suite IP. TCP permet un transfert de données fiable, ordonné et avec contrôle des erreurs ; il fonctionne par un système de sessions, généralement sous un format client/serveur.

La session est ouverte par des paquets SYN / ACK, similaires à un contrôle radio. Les paquets numérotés sont ensuite envoyés.

La suite de protocoles IP est généralement connue sous le nom TCP/IP.

TCP est généralement utilisé pour les données dont il faut s’assurer qu’elles arrivent entières, tandis que son pendant UDP est généralement utilisé pour les données devant arriver rapidement, quitte à perdre en fiabilité (streaming, jeux en ligne…).

En-tête TCP

Celle-ci fait 20 octets sans les options.

 

Les champs sont :

• Port source et destination (16 bits chacun) : identifient l'application
• Numéro de séquence /numéro d'ordre (32 bits) : Pour réorganiser les données, est fonction du nombre d'octets envoyés
• Numéro de reçu / numéro d'accusé de réception (32 bits): indique les données reçues, correspond au prochain numéro d'ordre attendu
• Longueur d'en-tête (4 bits) : connu sous le nom "décalage de données". Indique la longueur de l'en-tête.
• Réservé (6 bits) : future reserved
• Bits de contrôle (6 bits) : comprennent les indicateurs indiquant l'objectif et la fonction du segment TCP.
• Taille de fenêtre (16 bits) : Indique le nombre de segments pouvant être acceptés en même temps.
• Somme de contrôle (16 bits) : Checksum pour le contrôle d'erreur dans l'en-tête ET les données.
• Urgent (16 bits) : Indique si les données sont urgentes.
• Les options prennent 0 ou 32 bits, le cas échéant.
• Les flags sont :
  • SYN
  • ACK
  • FIN
  • RST pour réinitialiser une connexion
  • PSH : ne pas bufferiser les données mais les envoyer de suite
  • URG : Informer d'une donnée prioritaire

UDP (User Datagram Protocol)

UDP fournit une communication sans session, avec un fonctionnement simplifié. Il n’utilise pas de handshaking, ce qui le rend plus vulnérable aux variations de qualité du réseau, mais il évite l’absence d’overhead (transfert de données inutile), ce qui le rend plus rapide. Il permet cependant du multiplexage et la vérification d’intégrité (checksum) ; comme TCP. Il est parfois nomme Unreliable Data Protocol pour souligner son système d’acheminement.

Protocoles de couche 5 et plus

Protocoles mail

Le MTA est chargé de transporter les mails vers d’autre MTAs ou des MDAs ;  le MDA stocke (généralement) les emails des utilisateurs qui peuvent alors les récupérer par leur MUA. Le MTA a une fonction de routage de mails avant tout. Les serveurs de messagerie utilisent des enregistrements DNS type MX (Mail eXchanger).

SMTP (Simple Mail Transfer Protocol)

Ports 25, 465 (SSL), 587 (TLS)

RFC 821

Protocole par excellence des MTAs et d’ENVOI de courrier depuis un MUA vers un MTA. Les clients de messageries utilisaient aussi le port 25 pour l’envoi mais la nécessité de contrôle et d’auth a conduit à l’utilisation du port 587 (le port submission). Le port 465 (était?) en violation des spécifications RFC. SMTP est un protocole et un test sur le port 25 via telnet donne ceci :

<html>
telnet smtp.xxxx.xxxx 25
Connected to smtp.xxxx.xxxx.
220 smtp.xxxx.xxxx SMTP Ready
HELO client
250-smtp.xxxx.xxxx
250-PIPELINING
250 8BITMIME      
MAIL FROM: <auteur@yyyy.yyyy>
250 Sender ok
RCPT TO: <destinataire@xxxx.xxxx>
250 Recipient ok.
DATA
354 Enter mail, end with "." on a line by itself
Subject: Test

Corps du texte
.
250 Ok
QUIT
221 Closing connection
Connection closed by foreign host.
</html>

 

Serv en rouge, client en vert. Les codes chiffrés utilisés par le serv sont standardisés.
SMTP ne permettant pas d’authentifier les utilisateurs, il pose alors le problème du spam et (spoofing?). SMTP-Auth n’as pas réussi à s’imposer. Les FAI sont alors priés de bloquer le port 25 en réception, pour forcer les utilisateurs à passer par leur fournisseur de messagerie (et pas par leur propre serveur « sauvage »). TLS ne sert pas à authentifier, mais simplement à chiffrer.

Codes d'erreur

Le premier chiffre signifie:

• 2 : Pas d'erreur
• 3 : Demande en cours d'exécution
• 4 : Erreur temporaire
• 5 : Demande invalide

POP (Post Office Protocol)

Ports 110, 995 (SSL)

POP sert à récupérer du courrier sur un serveur : il se connecte, s’auth, récupère le courrier et peut effacer le courrier du MDA. Il ne sert qu’à la réception de courrier. Exemple :

<html>
S: <en attente de la connexion TCP sur le port 110>
C: <ouverture de la connexion>
S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
C:    APOP mrose 682949bee6805d9b611b82395e342cad
S:    +OK mrose's maildrop has 2 messages (320 octets)
C:    STAT
S:    +OK 2 320
C:    LIST
S:    +OK 2 messages (320 octets)
S:    1 120
S:    2 200
S:    .
C:    RETR 1
S:    +OK 120 octets
S:    <le serveur POP3 envoie le message 1>
S:    .
C:    DELE 1
S:    +OK message 1 deleted
C:    RETR 2
S:    +OK 200 octets
S:    <le serveur POP3 envoie le message 2>
S:    .
C:    DELE 2
S:    +OK message 2 deleted
C:    QUIT
S:    +OK dewey POP3 server signing off (maildrop empty)
C: <fermeture de la connexion>
S: <en attente de la prochaine connexion>
</html>

POP ne fonctionne qu’avec un MUA, soit un logiciel spécialisé.

IMAP (Internet Message Protocol)

Ports TCP: 143 (IMAP2/4), 220 (IMAP3), 993 (IMAPS en SSL)

Apparu pour permettre de récupérer les mails directement sur le serveur de messagerie (contrairement à POP), IMAP permet aujourd’hui de les récupérer aussi localement. Sont utilité est de pouvoir consulter les message directement sur le serv comme avec les webmails. Il permet aussi de créer des dossiers ou manipuler les messages directement sur le serveur.  Son inconvénient est qu’il nécessite une connexion permanente au serv pour la lecture des mails. IMAP4 a un mode hors ligne et permet aussi de n’avoir qu’une partie des mails, ou de par exemple effacer des mails sans les récupérer. IMAPS utilise SSL pour chiffrer.

HTTP (HyperText Transfer Protocol)

Ports TCP : 80, 443 (https)
Protocole des navigateurs web, il permet le transfert de pages web html et d’autres communications propres au web. Protocole client-serveur. Il utilise des méthodes, comme la méthode GET qui sert à demander une ressource au serveur.

GET

C'est la méthode la plus courante pour demander une ressource. Une requête GET est sans effet sur la ressource, il doit être possible de répéter la requête sans effet.

HEAD

Cette méthode ne demande que des informations sur la ressource, sans demander la ressource elle-même.

POST

Cette méthode est utilisée pour transmettre des données en vue d'un traitement à une ressource (le plus souvent depuis un formulaire HTML). L'URI fourni est l'URI d'une ressource à laquelle s'appliqueront les données envoyées. Le résultat peut être la création de nouvelles ressources ou la modification de ressources existantes. À cause de la mauvaise implémentation des méthodes HTTP (pour Ajax) par certains navigateurs (et la norme HTML qui ne supporte que les méthodes GET et POST pour les formulaires), cette méthode est souvent utilisée en remplacement de la requête PUT, qui devrait être utilisée pour la mise à jour de ressources.

OPTIONS

Cette méthode permet d'obtenir les options de communication d'une ressource ou du serveur en général.

CONNECT

Cette méthode permet d'utiliser un proxy comme un tunnel de communication.

TRACE

Cette méthode demande au serveur de retourner ce qu'il a reçu, dans le but de tester et effectuer un diagnostic sur la connexion.

PUT

Cette méthode permet de remplacer ou d'ajouter une ressource sur le serveur. L'URI fourni est celui de la ressource en question.

PATCH

Cette méthode permet, contrairement à PUT, de faire une modification partielle d'une ressource.

DELETE

Cette méthode permet de supprimer une ressource du serveur.

HTTP utilise un système de sessions, lors de laquelle le client utilise des méthodes et le serveur répond. Note : Apache utilise une instance de lui-même par session, NginX n’utilise qu’une seule instance pour toutes les sessions.
HTTPS est le même protocole sécurisé par SSL.

Lorsque un serveur HTTP répond à une requête demandant une page web, une fois qu'il a récupéré la page web, il ne l'envoie pas telle quelle : il va d'abord effectuer des traitements sur celle-ci : par exemple, du code PHP pourrait demander de récupérer des informations sur une base de données , ce que le serveur fera avant de mettre la réponse sous format de HTML à renvoyer au sein de la page.

Le header http

Une requête ou une réponse, dans le protocole HTTP, est constitué d'un header (ou en-tête) avant le contenu. Ce Header contient de nombreux champs et peut se réveler intéressant. Voici un extrait simplifié d'un Header (ici une requête):

<source> GET /tutorials/other/top-20-mysql-best-practices/ HTTP/1.1 Host: net.tutsplus.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=r2t5uvjq435r4q7ib3vtdjq120 Pragma: no-cache Cache-Control: no-cache </source>

Et sa réponse:

<source> HTTP/1.x 200 OK Transfer-Encoding: chunked Date: Sat, 28 Nov 2009 04:36:25 GMT Server: LiteSpeed Connection: close X-Powered-By: W3 Total Cache/0.8 Pragma: public Expires: Sat, 28 Nov 2009 05:36:25 GMT Etag: "pub1259380237;gz" Cache-Control: max-age=3600, public Content-Type: text/html; charset=UTF-8 Last-Modified: Sat, 28 Nov 2009 03:50:37 GMT X-Pingback: https://net.tutsplus.com/xmlrpc.php Content-Encoding: gzip Vary: Accept-Encoding, Cookie, User-Agent

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Top 20+ MySQL Best Practices - Nettuts+</title> </source>

Le Header peut contenir de nombreux champs : https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

FTP (File Transfer Protocol)

Ports : 21 (écoute), 20 (données)

FTP sert à transférer des ressources de tous types sur un réseau TCP/IP. Il est souvent utilisé pour alimenter un serveur web. FTP fonctionne en client/serveur, le serveur stockant généralement les données. Comme HTTP, le client établit une session et effectue des requêtes. Une connexion FTP peut s’effectuer en mode actif, où le client choisit le port utilisé pour le transfert de données (pose des problèmes par rapport au NAT, puisque le serveur va se connecter au port de réception choisi du routeur, potentiellement pas configuré… vu que c’est le serv qui initialise la connexion de transfert de données), ou en mode passif, dans lequel le serveur choisit le port lui même, le communique au client, et le client ouvre la session. Cela permet la compatibilité avec NAT. Un transfert commence par une connexion de contrôle (commandes), suivie d’une connexion de données.

 

DNS (Domain Name System)

Ports : 53 (UDP)

Pas seulement un protocole, DNS le service informatique distribué qui traduit les IP en nom et vice-versa. DNS fonctionne selon une hiérarchie:

La résolution d’un nom de domaine se fait de façon itérative :

 

Le serveur récursif interroge successivement les serveurs selon la hiérarchie en commençant par la racine (comme quand on lit un FQDN, de droite à gauche avec la racine représentée par un point : fr.wikipedia.org. : racine, org (qui est un top-level-domain), wikipedia, puis sa section francophone. Le serveur récursif a une connaissance limitée : le DNS de mon domaine connaîtra les machines de mon réseau, puis il cherchera les autres adresses par itération. Il est à noter qu’il existe aussi un fonctionnement nommé non récursif ou itératif dans lequel le DNS ne renvoie que le nom du DNS suivant dans la hiérarchie et c’est le client qui effectue la nouvelle demande.
Un resolver est le serv nommé sur le schéma « Serveur DNS récursif ». Si il ne fait que faire des requêtes et stocker les résultats dans sa mémoire, c’est un serveur cache. Si il se contente de faire suivre les requêtes à un autre serv sans les résoudre, il est un forwarder esclave qui s’adresse à un forwarder Maître. Enfin si il répond lui même aux requêtes sur une zone, il fait authorité sur la zone (serveur autoritaire).
Pour les résolutions inverses, on sait que contrairement à un nom de domaine, une IPv4 se lit de droite à gauche, c’est pour ça qu’elles sont renversées : 91.198.174.2 devient 2.174.198.91.IN-ADDR.ARPA. Le fonctionnement suit le même principe.

Le VLSM pose des problèmes car comme on ne coupe plus les réseaux à l’octet, il n’est plus possible de déléguer un bloc à une seule personne (si deux clients ont 192.168.0.0/25 et 192.168.0.128/25, le bloc est 0.0.168.192.IN-ADDR.ARPA. ). On utilise alors des domaines intermédiaires et des CNAMES (mais j’ai rien compris).

DNS connaît plusieurs types d’enregistrements dans ses fichiers de configuration :

    •A record ou address record (également appelé enregistrement d’hôte) qui fait correspondre un nom d'hôte ou un nom de domaine ou un sous-domaine à une adresse IPv4 de 32 bits distribués sur quatre octets ex: 123.234.1.2 ;
    • AAAA record ou IPv6 address record qui fait correspondre un nom d'hôte à une adresse IPv6 de 128 bits distribués sur seize octets ;
    • CNAME record ou canonical name record qui permet de faire d'un domaine un alias vers un autre. Cet alias hérite de tous les sous-domaines de l'original ;
    • MX record ou mail exchange record qui définit les serveurs de courriel pour ce domaine ;
    • PTR record ou pointer record qui associe une adresse IP à un enregistrement de nom de domaine, aussi dit « reverse » puisqu'il fait exactement le contraire du A record ;
    • NS record ou name server record qui définit les serveurs DNS de ce domaine ;
    • SOA record ou Start Of Authority record qui donne les informations générales de la zone : serveur principal, courriel de contact, différentes durées dont celle d'expiration, numéro de série de la zone ;
    • SRV record qui généralise la notion de MX record, mais qui propose aussi des fonctionnalités avancées comme le taux de répartition de charge pour un service donné, standardisé dans la  278221 ;
    • NAPTR record ou Name Authority Pointer record qui donne accès à des règles de réécriture de l'information, permettant des correspondances assez lâches entre un nom de domaine et une ressource. Il est spécifié dans la  340322 ;
    • TXT record permet à un administrateur d'insérer un texte quelconque dans un enregistrement DNS (par exemple, cet enregistrement est utilisé pour implémenter la spécification Sender Policy Framework) ;
    • d'autres types d'enregistrements sont utilisés occasionnellement, ils servent simplement à donner des informations (par exemple, un enregistrement de type LOC indique l'emplacement physique d'un hôte, c'est-à-dire sa latitude et sa longitude). Certaines personnes disent que cela aurait un intérêt majeur mais n'est que très rarement utilisé sur le monde Internet.

Les enregistrements type NS (Name Server) servent à pointer un sous-domaine vers plusieurs servs. Par exemple le serveur DNS de .org aurait dans ses fichiers :
wikipedia NS ns1.wikimedia.org.

Glue records :
Quand un domaine est délégué à un serveur de noms qui appartient à ce sous-domaine, il est nécessaire de fournir également l'adresse IP de ce serveur pour éviter les références circulaires. Ceci déroge au principe général selon lequel l'information d'un domaine n'est pas dupliquée ailleurs dans le DNS. Par exemple, dans la réponse suivante au sujet des NS pour le domaine wikimedia.org :

wikimedia.org. IN NS ns2.wikimedia.org.
wikimedia.org. IN NS ns1.wikimedia.org.
wikimedia.org. IN NS ns0.wikimedia.org.

Il est nécessaire de fournir également les adresses IP des serveurs indiqués dans la réponse (glue records25), car ils font partie du domaine en question :

ns0.wikimedia.org. IN A 208.80.152.130
ns1.wikimedia.org. IN A 208.80.152.142
ns2.wikimedia.org. IN A 91.198.174.4

DNSSEC est un ensemble de procédés ayant pour but de sécuriser cette chaîne hiérarchique par un systèmes d’authentification (des signatures avec des clefs). Il a pour but de contrer les nombreuses failles de sécurités de DNS : cache poisoning, spoofing...

Note : Les TTL fournis par les serveurs DNS sont indicatifs (un jour en général), certains serveurs cache ou autres ont tendance à les ignorer.
Les mises à jour DNS se font en partant du serveur faisant autotité sur la zone concernée ; les serveurs secondaires recopient les changements par un transfert de zone.

DHCP (Dynamic Host Configuration Protocol)

Ports : 67 (serv), 68 (client)

Protocole réseau dont le rôle est d’assurer la configuration automatique des paramètres IP d’une station ou d'une machine, notamment en lui attribuant automatiquement une adresse IP et un masque de sous-réseau. DHCP peut aussi configurer l’adresse de la passerelle par défaut, des serveurs de noms DNS et des serveurs de noms NBNS (connus sous le nom de serveurs WINS sur les réseaux de la société Microsoft).

L’acquisition d’une adresse par DHCP se fait en plusieurs étapes.
-Le client non configuré envoie en broadcast sur le port 67 un DHCP DISCOVER. Il comporte l’adresse MAC du client.
-Un serveur répond avec un DHCP OFFER sur l’adresse MAC port 68 du client, qui contient IP, masque.
-Le client retient la première offre reçue et diffuse un DHCP REQUEST qui contient l’IP du serv, celle du client dont il demande l’assignation, la demande des valeurs des paramètres, etc. Il informe aussi les autres serv que leurs offres n’ont pas été retenues.
-Le serv répond par DHCP ACK qui assigne au client IP, masque, durée du bail, et les autres infos (@ gateway, DNS, etc).
-Le client est sensé commencer à demander le renouvellement du bail à la valeur T1, et à T2 il redemande une adresse en broadcast.

SNMP (Simple Network Management Protocol)

Ports : 161 UDP (agent) et 162 (traps)

Protocole de communication qui permet aux administrateurs réseau de gérer les équipements du réseau, de superviser et de diagnostiquer des problèmes réseaux et matériels à distance.
Basé sur trois élements : UIl semblerait qu'il ait disparu sans mon intervention !n superviseur (ou manager), des nœuds et des agents. Le manager est la console qui permet à l’admin de demander des requêtes de gestion. Les agents sont les entités au niveau de chaque interface et permettent de connecter l’équipement géré (le nœud) au réseau de supervision. SNMP permet de surveiller et gérer les nœuds (les administrer). Les ordis et équipements réseau contiennent des objets gérables qui peuvent être des infos sur le matos, des paramètres de config, des stats de performances et d’autres liés au comportement de l’équipement en question. Les objets sont classés dans une base de données arborescente, la Management Information Base ou MIB, définie par la norme ISO. SNMP fait dialoguer le superviseur et les agents afin de récupérer les objets souhaités dans la MIB.
Une requête SNMP v1 ou 2 contient un nom de communauté, généralement appellé public ou private. Il est recommandé de n’utiliser que la v3 car les 1 et 2 comportent des failles. La v3 est chiffrée en DES-64, avec une clef pour l’auth et une clef pour le chiffrement.

SNMP a aussi un concept de traps (ou interruptions). Si un évènement prédéfini se produit, l’agent envoie un paquet UDP sur le port 162 du serveur.

SNMP est aussi utilisé en informatique industrielle pour des informations ne concernant pas le réseau mais des applications industrielles. Il peut aussi servir à rétablir l’accès à un pare-feu.

SIP (Session Initiation Protocol)

5060, 5061 (SIPS)

Protocole standard ouvert de gestion de sessions souvent utilisé dans les télécommunications multimédia (son, image, etc.) Il est depuis 2007 le plus courant pour la téléphonie par internet (la VoIP).
Il est un protocole de la couche applicative (et pas de la couche session, attention), normalisé par IETF. Il sert à établir, modifier, terminer des sessions multimédia. Il localise et authentifie les participants. Il négocie ensuite sur les types de médias utilisables par les participants. SIP ne transporte pas les données, mais c’est généralement RTP qui assure les sessions audio et vidéo.

SIP remplace H323, mais il a certaines faiblesses et Skype est fermé, ce qui pose des problèmes. Le protocole ouvert Jabber est étudié pour le remplacer, il est meilleur pour les messageries instantanées.

SIP ressemble à HTTP avec ses méthodes et ses codes de réponse. Les requêtes comme INVITE, ACK, etc. sont envoyées par le client et le serveur renvoie des codes de réponse.

Les User Agents sont les agents présent dans les téléphones SIP, softphones et autres ; mais comme ils nécessitent l’IP du correspondant, il sont généralement enregistrés auprès d’un registrar. Le registrar est un serveur qui contient les IP des UA et gère les requêtes REGISTER envoyées par les agents qui veulent enregistrer leur emplacement courant (leur IP). Ces requêtes contiennent donc une IP associée à une URI, qui ressemble à une adresse mail : [[[[[[[1]]]]]]]. Il y’a généralement un mécanisme d’authentification en place.
Deux agents qui ne se connaissent pas l’un l’autre peuvent être mis en relation grâce à des proxies SIP. Les proxies va interroger la bdd dans laquelle un registrar a stocké les informations pour rediriger ensuite les messages. Le proxy ne fait qu’établir la connexion ; le transfert de données se fait directement entre les UA.

Un B2BUA (Back 2 Back user agent) se comporte un peu comme un proxy, sauf qu’il se place directement sur la communication entre les deux participants pour gérer la qualité, offrir des services supplémentaires…

SSL (Secure Sockets Layer) et TLS (Transport Layer Security)

SSL a été développé à la base par Netscape puis l’IETF, qui l’as renommé TLS. On parle parfois de SSL/TLS sans distinction.
Fonctionne en mode client/serveur, il sert à :
l'authentification du serveur ; la confidentialité des données échangées (ou session chiffrée) ; l'intégrité des données échangées ; de manière optionnelle, l'authentification du client (mais dans la réalité celle-ci est souvent assurée par le serveur).
Largement utilisé car ainsi les protocoles de la couche applicative n’ont qu’a s’implanter au dessus de lui.
Dans la majorité des cas, l'utilisateur authentifie le serveur TLS sur lequel il se connecte. Cette authentification est réalisée par l'utilisation d'un certificat numérique X.509 délivré par une autorité de certification (AC). Des applications web peuvent utiliser l'authentification du poste client en exploitant TLS. Il est alors possible d'offrir une authentification mutuelle entre le client et le serveur. Le certificat client peut être stocké au format logiciel sur le poste client ou fourni par un dispositif matériel (carte à puce, token USB).

Principe de fonctionnement en http :

• -Le client envoie une demande de connexion TLS
• -Le serveur envoie son certif, qui contient la clef publique, les infos, et une signature numérique, un texte chiffré.
• -Le client essaye de déchiffrer la signature numérique avec les clefs publiques contenues dans les certificats des autorités de certification contenues dans les navigateurs. Si l’une d’entre elles fonctionnent, on connaît alors l’autorité et une demande OCSP permet de vérifier que le certificat est toujours valide. Sinon, le browser essaye de déchiffrer la signature avec la clef publique qui est dans le certificat. Si cela fonctionne, le browser sait que le certificat est auto-signé. Sinon, pas de connexion.
• -Le browser génère une clef symétrique (contrairement au clefs des certifs qui sont asymétriques (symétrique : la même clef chiffre et déchiffre)) appellée clef de session, la chiffre avec la clef publique du serv et lui envoie.
• -Le serv déchiffre la clef de session avec sa clef privée.
• -La connexion s’établit alors : client et serveur échangent des données en les chiffrant avec la clef de session.
• -Si le client doit s’authentifier aussi, le client envoie son propre certificat en même temps que la clef de session.

LDAP (Lightweight Directory Access Protocol)

Version actuelle : LDAP v3
Port : 389 (clair, TLS), 636 (LDAPS)

À la base un protocole d’accès et de modification d’annuaires, il est devenu une norme pour les systèmes d’annuaires avec un modèle de données, un modèle de nommage, un modèle fonctionnel basé sur le protocole LDAP, un modèle de sécurité et un modèle de réplication. Il a une structure arborescente dont chacun des nœuds est constitué d’attributs associés à des valeurs. Moins complexe que le modèle X.500 (LDAP est déjà pas mal compliqué… Alors X.500?).
Le nommage des éléments de l’arbre représente souvent la structure politique, hiérarchique de l’entité de l’entité représentée (ets…). La tendance actuelle est d'utiliser le nommage DNS pour les éléments de base de l'annuaire (racine et premières branches, domain components ou dc=…). Les branches plus profondes de l'annuaire peuvent représenter des unités d'organisation ou des groupes (organizational units ou ou=…), des personnes (common name ou cn=… voire user identifier uid=…). L'assemblage de tous les composants (du plus précis au plus général) d'un nom forme son distinguished name, l'exemple suivant en présente deux :

•  

cn=ordinateur,ou=machines,dc=EXEMPLE,dc=FR

•  

cn=Jean,ou=personnes,dc=EXEMPLE,dc=FR

            dc=FR
              |
          dc=EXEMPLE
         /          \
   ou=machines    ou=personnes
       /              \
cn=ordinateur       cn=Jean

Les annuaires LDAP, comme X500, sont structurés comme ça :
-Un annuaire est un arbre d’entrées ;
-Un entrée est constituée de plusieurs attributs ;
-Un attribut possède un nom, un type et plusieurs valeurs ;
-Les attributs sont définis dans des schémas.

Un attribut ne peut pas être NULL. Chaque entrée a un identifiant unique, le Distinguished Name, constitué de son Relative DN suivi du DN de son parent: c’est une définition récursive. En gros, ça marche comme un système de fichiers sous UNIX.
Le RDN de toto est rdn:uid=toto, son DN est dn:uid=toto,ou=people,dc=example,dc=org
LDAP utilise LDIF (LDAP Data Interchange Format), qui est un format standardisé pour échanger des données contenues dans les annuaires LDAP. Par exemple une entrée formatée en LDIF :

 

dn: cn=John Doe,dc=example,dc=org #Nom de l’entrée, pas un attr.
 cn: John Doe						#Attributs
 givenName: John
 sn: Doe
 telephoneNumber: +1 555 6789
 telephoneNumber: +1 555 1234
 mail: john@example.com
 manager: cn=Barbara Doe,dc=example,dc=com
 objectClass: inetOrgPerson
 objectClass: organizationalPerson
 objectClass: person
 objectClass: top

Un serveur contient un sous-arbre dont la racine est une entrée spécifique et tous ses enfants, par exemple : "dc=example,dc=org". Les serveurs peuvent également contenir des références vers d'autres serveurs, ainsi l'accès à une entrée ("ou=un service,dc=example,dc=org") peut retourner une référence (referral) à un autre serveur qui contient le sous-arbre voulu. Le client peut alors contacter (automatiquement ou pas) l'autre serveur. Certains serveurs prennent en charge le chaînage (chaining) qui permet au serveur d'interroger d'autres serveurs pour renvoyer l'information voulue au client. Les résultats renvoyés par le serveur ne sont pas triés, que ce soit pour les entrées, pour les attributs des entrées ou pour les valeurs des attributs.

Relation client/serveur:

Le client donne à sa requête un ID Message ID, qui est également utilisée par le serveur. La réponse contient un code numérique de résultat (même principe que http), les données, et un code ID.

Les opérations incluent :
-bind, qui sert à authentifier le client auprès du serveur ; bind peut être en clair, en TLS, en anonyme ce qui réduit les privilèges, en SASL avec Kerberos / certificat client etc. bind sert aussi à définir la version LDAP utilisée.
-StartTLS qui sert à entamer une liaison en TLS, dans un but de confidentialité mais aussi d’intégrité des données avec une signature. Les serveurs prennent généralement en charge le protocole non standard LDAPS, en SSL. La différence qu’en LDAPS, une connexion TLS est établie avant le moindre envoi de commande ; de plus la connexion doit être fermée lors de la cloture TLS, alors que normalement la connexion peut « sauter » d’une co sécurisée à non sécurisée.
-Search et Compare : L'opération Search est utilisée à la fois pour faire une recherche et rapatrier des entrées. Ses paramètres sont :

    • baseObject : le DN (Distinguished Name) de l'entrée à partir de laquelle effectuer la recherche ;
    • scope : base pour l'entrée baseObject elle-même, one pour effectuer une recherche au niveau des entrées immédiatement rattachées au baseObject, sub pour une recherche dans le sous-arbre de l'entrée ;
    • filter : les critères qui déterminent si une entrée fait partie des résultats ou non, par exemple (&(objectclass="person)(|(givenName=John)(mail=john*)))" - recherche les personnes qui ont pour prénom John ou dont le courriel commence par john ;
    • derefAliases : indique si la recherche doit suivre les alias dans les entrées (entrée qui font référence à d'autres entrées) ;
    • attributes : liste des attributs à ramener à l'issue de la recherche ;
    • sizeLimit : limitation du nombre d'entrées ramenées à l'issue de la recherche ;
    • timeLimit : limitation du délai de recherche, exprimé en secondes ;
    • typesOnly : ne renvoie que les types d'attribut et non les valeurs.

Le serveur renvoie les entrées qui correspondent, suivies par le code retour de la commande (code de retour). L'opération Compare prend en argument un DN, un nom d'attribut et une valeur d'attribut, puis vérifie si l'entrée correspondante contient bien un attribut ayant cette valeur.
-Add, delete, modify servent à mettre à jour des entrées.

URI

LDAP a un format d’URI qui lui est propre, pas toujours pris en charge par les clients ; les serveurs l’utilisent pour renvoyer les clients vers d’autres serveurs. Format :

<span style="font-style:normal"><font face="Liberation Serif, serif"><font size="4"><font style="font-size: 16pt">ldap://hôte:port/DN?attributs?profondeur?filtre?extension</font></font></font></span>

•  

DN : le DN à partir duquel effectuer la recherche ;

•  

attributs : liste contenant les attributs à renvoyer, séparés par des virgules ;

•  

profondeur : base (par défaut), one ou sub pour la profondeur de la recherche ;

•  

filtre : le filtre de recherche ;

•  

extension : extensions éventuelles du format d'URL LDAP.

ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com

retourne tous les attributs de l'entrée « John Doe »,

 ldap:///dc=example,dc=com??sub?(givenName=John)

recherche l'entrée ayant comme prénom « John » dans l'annuaire à partir de la racine.

[NB :%20 est un caractère d’échappement prévu dans la RFC 3986]

Schémas

Le contenu des entrées d'un annuaire LDAP est régi par des schémas.
Ils définissent les types d’attributs que peuvent avoir une entrée, avec la syntaxe (string UTF-8, comme une adresse mail ; un JPEG ; un DN ; etc). La définition d’un attribut dit aussi si il est mono ou multi valué.
Les schémas définissent des classes d'objets. Chaque entrée de l'annuaire doit avoir au moins une valeur pour l'attribut objectClass, qui soit une classe d'objets définie dans les schémas. Généralement, l'attribut objectClass est multi-valué et contient la classe top ainsi qu'un certain nombre d'autres classes.
Tout comme dans la programmation orientée objet, les classes permettent de décrire un objet en lui associant des attributs. Les classes LDAP représentent des personnes, des organisations... Le fait qu'une entrée appartienne à une classe (donc que l'attribut objectClass contienne le nom de la classe) lui permet d'utiliser les attributs de cette classe. Certains attributs sont obligatoires et d'autres facultatifs. Par exemple, si l'entrée utilise la classe person, elle doit avoir obligatoirement une valeur pour les attributs sn et cn, et peut avoir facultativement une valeur pour les attributs userPassword et telephoneNumber. Les entrées ayant généralement plusieurs classes, la différenciation entre attributs obligatoires et facultatifs peut être assez complexe.
Les éléments d'un schéma ont un nom et un identifiant unique nommé Object identifier (OID).

Beaucoup de serveurs exposent les schémas de l'annuaire comme des entrées LDAP accessibles à partir du DN cn=schema. Il est possible pour les administrateurs de définir leur propre schéma en plus des schémas standard.
Le principal intérêt de LDAP est l’authentification avec une API LDAP, qui remplace les fichiers à plat passwd et shadow.

Kerberos

Protocole d’authentification AAA (comme RADIUS) reposant sur un système de clefs symétriques et l’utilisation de tickets, et non pas de mdp en clair. D’abord créé pour Unix. Le système de tickets s’inspire de celui utilisé dans un cinéma. Ce système de tickets permet le SSO, ou Single Sign On : Un seul ticket (ou token) généré par Kerberos permet à l’utilisateur d’accéder à tous les services d’un réseau.
Fonctionnement :
Notation :
    • AS: service d’authentification.
    • TGS: Service délivrant des tickets d’accès aux services.
    • TGT: Ticket d’accès au TGS.
    • TS: Ticket d’accès au service demandé.
    • Kutilisateur: Clé secrète de l’utilisateur, connu de l’utilisateur et du TGS.
    • Kservice: Clé secrète du service demandé, connu du service et du TGS.
    • Ktgs : Clé secrète du TGS connu du TGS et de l’AS.
    • KsessionTGS : Clé de session entre l’utilisateur et le TGS.
    • Ksession: clé secrète de session entre l’utilisateur et le service demandé.
    • TicketService : Ticket d’accès au service demandé.
{a+b} signifie que le message contient a et b successivement

• -L’utilisateur s’authentifie avec son login/mdp. Son PC hashe le mdp en clé Kutilisateur. Puis le client Kerberos envoie à l’AS l’identité de la personne en clair ainsi que {msg auth + timestamp}, chiffré avec Kutilisateur. L’authentification a une durée modifiable (plusieurs heures par défaut). Le mdp n’est pas transmis, il génére que kUtilisateur ; de même Kutilisateur chiffre le msg authentifiant mais n’est pas transmise sur le réseau.
• -l’AS regarde l’identité de l’utilisateur ; il connaît aussi son mdp car c’est lui qui les gère. Il génère Kutilisateur et s’en sert pour déchiffrer le message d’authentification, si il est bien déchiffré c’est bon. Il regarde aussi le timestamp pour éviter les rejeux.
• -l’AS renvoie alors {TGT, KsessionTGS}chiffré avec Kutilisateur à l’utilisateur, c’est-à-dire un ticket TGS et une clef de session entre l’utilisateur et le TGS.
• -L’utilisateur déchiffre le tout, récupère le TGT et la clef de session TGS. Le TGT, chiffré avec kTgs, contient trois choses chiffrées avec Ktgs : La date d’expiration, le nom de l’utilisateur et kSessionTgs. L’utilisateur renvoie alors au TGS : le TGT, un timestamp chiffré KsessionTGS, le service demandé. C’est la demande d’accès.
• -Grâce au TGT, le TGS connait l’identité du sujet et la clé de session à utiliser pour chiffrer la communication avec l’utilisateur. Il vérifie grâce à KsessionTGS la valeur du timestamp (permet d’éviter le rejeu et de signer en quelque sorte la requête de l’utilisateur). En fonction des droits du sujet, il va accepter ou refuser la demande d’accès au service. Dans le cas où le sujet possède les droits d’accès au service, le TGS va lui envoyer KsessionTGS {timestamp, Ksession, service à joindre, TicketService}. Le TicketService est un ticket à transmettre au service pour assurer la connexion avec celui-ci. TicketService = Kservice {Ksession, identité sujet, date d’expiration}.
• -Le sujet déchiffre la réponse du TGS. Il transmet ensuite TicketService au service pour initialiser la connexion. TicketService = Kservice {Ksession, identité sujet, date d’expiration}.
• -Le service déchiffre TicketService et récupère Ksession. Il renvoie Ksession {timestamp}
• -Le sujet déchiffre le timestamp, vérifie que le temps écoulé entre l’envoi et la réception de la réponse n’est pas trop long. Ksession {timestamp}.

Remarque : L’utilisation de timestamp permet de s’assurer que les parties connaissent la clé et d’éviter qu’une personne mal intentionnée rejoue une séquence d’accès intercepté.
Remarque perso : Kerberos semble affreusement compliqué, et en réalité il est simplement plus « préconfiguré » qu’un RADIUS. Cependant RADIUS est bien plus configurable ; de plus le fait que le TGS puisse générer les clefs des utilisateurs semble compromettre (un peu) le tout. Un RADIUS doté d’un système de clefs privées/publiques semble plus efficace.
De plus Kerberos favorise le « tout Kerberos », et par là même le tout Windows.