Berkeley sockets

Berkeley Sockets Interface ou simplement sockets, est un ensemble normalisé de fonctions de communication lancé par l'université de Berkeley au début des années 1980 pour leur Berkeley Software Distribution (abr. BSD). 30 ans après son lancement, cette interface de programmation est proposée dans quasiment tous les langages de programmation populaires (Java, C#, C++, …).

La notion sur laquelle est construite cette interface sont les sockets (en français « interfaces de connexion » mais aussi « ports, points de connexion, connecteurs logiciels ») par lesquelles une application peut se brancher à un réseau et communiquer ainsi avec une autre application branchée depuis un autre ordinateur.

Avant leur introduction, le seul mécanisme standard qui permettait à deux processus de communiquer se faisait par l'intermédiaire des pipes.^{[réf. nécessaire]}

Fonctionnalités

Un socket représente une prise par laquelle une application peut envoyer et recevoir des données. Cette prise permet à l'application de se brancher sur un réseau et communiquer avec d'autres applications qui y sont branchées. Les informations écrites sur une prise depuis une machine sont lues sur la prise d'une autre machine, et inversement. Il existe différents modèles de prises, en fonction des protocoles réseau; le plus fréquent sont les socket TCP/IP. La première interface de programmation (anglais API pour application programming interface) mettant en œuvre les socket a été développée par l'université de Berkeley pour leur Unix, dans les années 1980. C'est un des premiers produits open source de l'histoire.

La fonction socket de cette API sert à créer un certain type de prise. Le type de prise sera choisi en fonction de la technologie de communication à utiliser (par exemple TCP/IP). L'API permet à un logiciel serveur de servir plusieurs clients simultanément. Sur les systèmes d'exploitation Unix le programme serveur utilisera la fonction fork pour chaque demande d'un client.

Une connexion est établie entre le client et le serveur en vue de permettre la communication. La fonction connect permet à un client de demander la connexion à un serveur, et la fonction accept permet à un serveur d'accepter cette connexion. Le programme serveur utilisera préalablement la fonction listen pour informer le logiciel sous-jacent qu'il est prêt à recevoir des connexions. Une fonction close permet de terminer la connexion. Lorsqu'un des deux interlocuteurs termine la connexion, l'autre est immédiatement avisé.

Une fois la connexion établie, les fonctions send et recv servent respectivement à envoyer et à recevoir des informations. Une fonction auxiliaire gethostbyname permet d'obtenir l'adresse IP d'une machine en interrogeant le DNS, adresse qui sera utilisée par d'autres fonctions de l'API.

Chaque socket possède un type et un ou plusieurs processus qui lui sont associés. Il est également caractérisé par le domaine de communication dans lequel il se trouve. Ce dernier est une abstraction qui permet de regrouper les processus ayant des propriétés communes et communiquant par l'intermédiaire de sockets. Normalement, un socket ne peut échanger des données qu'avec un socket se trouvant dans le même domaine de communication.

La communication inter-processus de 4.3BSD supportait trois domaines de communication :

• le domaine Unix dans lequel deux processus se trouvant sur la même station Unix uniquement peuvent communiquer ;
• le domaine Internet pour les processus utilisant le protocole TCP/IP pour communiquer entre eux ;
• le domaine NS pour les processus échangeant des données en utilisant le protocole standard de Xerox.

Types de sockets

Les différents types de sockets dépendent de quelques propriétés visibles par le programmeur. Rien n'empêche deux sockets de types différents de communiquer entre eux si le protocole utilisé le supporte — même si les processus sont supposés communiquer uniquement par des sockets de même type.

Il existe généralement quatre types de sockets :

• Un socket stream permet une communication bidirectionnelle, sûre, séquencée et un flux de données sans duplication pouvant entraîner une fragmentation des paquets transmis. Dans le domaine Internet, il s'agit du protocole TCP.
• Un socket datagram permet une communication bidirectionnelle qui n'est pas séquencée, pas sûre, et peut éventuellement entraîner une duplication des données. Un processus utilisant ce type de socket peut donc recevoir les données dans un ordre différent de l'ordre de départ. Dans le domaine Internet, il s'agit du protocole UDP.
• Un socket raw permet d'accéder au contenu brut des paquets de données. Les sockets raw ne sont pas destinés aux utilisateurs courants — seul l'utilisateur root peut y avoir accès sur la plupart des systèmes UNIX® — et sont utilisés par exemple pour analyser le trafic d'un réseau.
• Un socket sequenced packet, qui ressemble à un socket stream sauf qu'il n'utilise pas de fragmentations de paquets.

Socket Internet

Les sockets du domaine Internet sont utilisés pour la communication bidirectionnelle entre des processus qui sont sur des machines différentes d'un réseau IP. Ainsi, un socket du domaine Internet désigne un des nœuds d'un flux de données à travers un réseau IP tel qu'Internet.

Dans ce type de socket, une adresse socket est la combinaison d'une adresse IP et d'un port (lequel est associé à un processus) formant une seule et unique entité.

Un socket Internet se caractérise par la combinaison des éléments suivants :

• Adresse du socket local : adresse IP locale et numéro de port.
• Adresse du socket distant : uniquement pour les sockets TCP déjà établis.
• Protocole : un protocole de la couche transport (TCP, UDP).

Socket unix

Les sockets du domaine UNIX utilisent le système de fichiers comme espace de noms. Ils sont référencés dans le système de fichier par les processus en tant qu'inodes. Cela permet à deux processus d'ouvrir le même socket pour communiquer. Toutefois, la communication se produit entièrement dans le noyau du système d'exploitation.

Il est possible d'utiliser les permissions du système de fichiers (en) pour contrôler l'accès aux sockets IPC. On peut définir quel processus peut se connecter à tel autre de cette manière.

En plus d'envoyer des données, ces processus peuvent envoyer des descripteurs de fichiers sur un socket du domaine Unix, en utilisant les fonctions d'appel système « sendmsg » et « recvmsg ».

Socket raw

Les sockets raw reçoivent les paquets bruts avec leur en-tête, et elles n'ajoutent automatiquement un en-tête lorsque l'on envoie les paquets que si on le demande dans une option de la socket. Une utilisation possible des sockets raw est de développer de nouveaux protocoles de couche transport en espace utilisateur.

Les sockets raw sont nécessaires aux protocoles qui sont directement encapsulés dans IP, sans passer par TCP ni UDP. On peut par exemple citer le protocole de gestion de groupes de multidiffusion IGMP, le protocole de routage dynamique OSPF, ainsi que le protocole ICMP utilisé par la commande ping.

Enfin, on peut s'en servir pour créer des paquets TCP ou UDP inhabituels. En particulier, un pirate informatique pourra contrefaire des paquets dans l'intention de nuire ou de s'introduire dans un système (voir plus bas).

Les sockets raw, un outil de piratage ?

Quand Microsoft a publié Windows XP en 2001, l'interface Winsock prenait en charge les sockets raw. La presse a alors critiqué Microsoft, en affirmant que les sockets raw n'étaient utilisées que par des pirates pour fabriquer de toutes pièces des paquets trafiqués. Ceux-ci peuvent ainsi par exemple lancer des attaques de réinitialisation des connexions TCP en cours, en créant des segments TCP contenant le bit RST (reset). Trois ans plus tard, Microsoft a, sans l'annoncer, limité la prise en charge des sockets raw par Winsock dans un patch qui ne pouvait pas être retiré et n'a pas offert d'assistance ou proposé de contournements aux applications qui les utilisaient.

On peut s'interroger sur l'opportunité de mettre ainsi des bâtons dans les roues des pirates, sachant qu'un informaticien déterminé trouvera toujours le moyen de « forger » (contrefaire) des paquets. De fait, il n'a fallu que quelques jours pour qu'un « correctif » au hotfix de Microsoft apparaisse. Les paquets réseau ne sont en effet jamais que des suites arbitraires d'octets, le vrai problème des attaques de type RST se niche dans le protocole TCP lui-même et pas dans le moyen pratique de contrefaire les paquets, socket raw ou autre.

Par ailleurs, il existe des utilisations légitimes de certains paquets « forgés », même dans le cas d'un paquet TCP ayant le bit RST. Le mécanisme d'équilibrage de charge des serveurs de Yahoo! et de Google s'en sert, par exemple.

Annexes

Articles connexes

• XML socket
• Winsock
• Secure socket layer

Liens externes

• Les sockets en Langage C
• Guide pour la programmation réseaux, Unix (utilisation des sockets Internet)