Sécurité réseau - Couche de transport

La sécurité du réseau implique la sécurisation des données contre les attaques lorsqu'elles sont en transit sur un réseau. Pour atteindre cet objectif, de nombreux protocoles de sécurité en temps réel ont été conçus. Il existe des normes courantes pour les protocoles de sécurité réseau en temps réel tels que S / MIME, SSL / TLS, SSH et IPsec. Comme mentionné précédemment, ces protocoles fonctionnent à différentes couches du modèle de réseau.

Dans le dernier chapitre, nous avons discuté de certains protocoles populaires conçus pour assurer la sécurité de la couche application. Dans ce chapitre, nous discuterons du processus de sécurisation du réseau au niveau de la couche de transport et des protocoles de sécurité associés.

Pour le réseau basé sur le protocole TCP / IP, les couches physiques et de liaison de données sont généralement implémentées dans le terminal utilisateur et le matériel de la carte réseau. Les couches TCP et IP sont implémentées dans le système d'exploitation. Tout ce qui est supérieur à TCP / IP est implémenté en tant que processus utilisateur.

Besoin de sécurité de la couche de transport

Parlons d'une transaction commerciale Internet typique.

Bob visite le site Web d'Alice pour vendre des produits. Dans un formulaire sur le site, Bob saisit le type de bien et la quantité souhaitée, son adresse et les coordonnées de sa carte de paiement. Bob clique sur Soumettre et attend la livraison des marchandises avec débit du montant du prix de son compte. Tout cela semble bien, mais en l'absence de sécurité du réseau, Bob pourrait avoir quelques surprises.

  • Si les transactions n'utilisaient pas la confidentialité (cryptage), un attaquant pourrait obtenir les informations de sa carte de paiement. L'attaquant peut alors faire des achats aux frais de Bob.

  • Si aucune mesure d'intégrité des données n'est utilisée, un attaquant pourrait modifier la commande de Bob en termes de type ou de quantité de marchandises.

  • Enfin, si aucune authentification de serveur n'est utilisée, un serveur pourrait afficher le célèbre logo d'Alice mais le site pourrait être un site malveillant maintenu par un attaquant, qui se fait passer pour Alice. Après avoir reçu la commande de Bob, il pourrait prendre l'argent de Bob et s'enfuir. Ou il pourrait commettre un vol d'identité en recueillant le nom de Bob et les détails de sa carte de crédit.

Les schémas de sécurité de la couche de transport peuvent résoudre ces problèmes en améliorant la communication réseau basée sur TCP / IP avec la confidentialité, l'intégrité des données, l'authentification du serveur et l'authentification du client.

La sécurité à cette couche est principalement utilisée pour sécuriser les transactions Web basées sur HTTP sur un réseau. Cependant, il peut être utilisé par n'importe quelle application fonctionnant sur TCP.

Philosophie de la conception TLS

Les protocoles TLS (Transport Layer Security) fonctionnent au-dessus de la couche TCP. La conception de ces protocoles utilise des interfaces de programme d'application (API) vers TCP, appelées «sockets» pour l'interfaçage avec la couche TCP.

Les applications sont désormais interfacées avec Transport Security Layer au lieu de TCP directement. Transport Security Layer fournit une API simple avec des sockets, qui est similaire et analogue à l'API de TCP.

Dans le diagramme ci-dessus, bien que TLS réside techniquement entre la couche application et la couche de transport, du point de vue commun, il s'agit d'un protocole de transport qui agit comme une couche TCP améliorée avec des services de sécurité.

TLS est conçu pour fonctionner sur TCP, le protocole fiable de couche 4 (et non sur le protocole UDP), pour simplifier la conception de TLS, car il n'a pas à se soucier du `` délai d'expiration '' et de la `` retransmission des données perdues ''. La couche TCP continue de faire cela comme d'habitude, ce qui répond aux besoins de TLS.

Pourquoi TLS est populaire?

La raison de la popularité de l'utilisation d'une sécurité chez Transport Layer est la simplicité. La conception et le déploiement de la sécurité à cette couche ne nécessitent aucune modification des protocoles TCP / IP implémentés dans un système d'exploitation. Seuls les processus utilisateur et les applications doivent être conçus / modifiés, ce qui est moins complexe.

Secure Socket Layer (SSL)

Dans cette section, nous abordons la famille de protocoles conçus pour TLS. La famille comprend les versions SSL 2 et 3 et le protocole TLS. SSLv2 a été remplacé par SSLv3, nous allons donc nous concentrer sur SSL v3 et TLS.

Bref historique de SSL

En 1995, Netscape a développé SSLv2 et utilisé dans Netscape Navigator 1.1. La version SSL1 n'a jamais été publiée et utilisée. Plus tard, Microsoft a amélioré SSLv2 et a introduit un autre protocole similaire appelé Private Communications Technology (PCT).

Netscape a considérablement amélioré SSLv2 sur divers problèmes de sécurité et a déployé SSLv3 en 1999. L'Internet Engineering Task Force (IETF) a ensuite introduit un protocole TLS (Transport Layer Security) similaire en tant que norme ouverte. Le protocole TLS n'est pas interopérable avec SSLv3.

TLS a modifié les algorithmes cryptographiques pour l'expansion et l'authentification des clés. En outre, TLS a suggéré l'utilisation du crypto ouvert Diffie-Hellman (DH) et de la norme de signature numérique (DSS) à la place du crypto RSA breveté utilisé dans SSL. Mais en raison de l'expiration du brevet RSA en 2000, il n'existait aucune raison forte pour que les utilisateurs abandonnent le SSLv3 largement déployé vers TLS.

Principales caractéristiques de SSL

Les principales caractéristiques du protocole SSL sont les suivantes -

  • SSL assure la sécurité de la connexion réseau via -

    • Confidentiality - Les informations sont échangées sous une forme cryptée.

    • Authentication- Les entités de communication s'identifient mutuellement grâce à l'utilisation de certificats numériques. L'authentification du serveur Web est obligatoire alors que l'authentification du client reste facultative.

    • Reliability - Maintient les contrôles d'intégrité des messages.

  • SSL est disponible pour toutes les applications TCP.

  • Pris en charge par presque tous les navigateurs Web.

  • Facilite les affaires avec de nouvelles entités en ligne.

  • Développé principalement pour le e-commerce Web.

Architecture de SSL

SSL est spécifique à TCP et ne fonctionne pas avec UDP. SSL fournit une interface de programmation d'application (API) aux applications. Les bibliothèques / classes SSL C et Java sont facilement disponibles.

Le protocole SSL est conçu pour interfonctionner entre l'application et la couche de transport, comme illustré dans l'image suivante -

SSL lui-même n'est pas un protocole à une seule couche comme le montre l'image; en fait, il est composé de deux sous-couches.

  • La sous-couche inférieure comprend l'un des composants du protocole SSL appelé protocole d'enregistrement SSL. Ce composant fournit des services d'intégrité et de confidentialité.

  • La sous-couche supérieure comprend trois composants de protocole liés à SSL et un protocole d'application. Le composant d'application fournit le service de transfert d'informations entre les interactions client / serveur. Techniquement, il peut également fonctionner au-dessus de la couche SSL. Trois composants de protocole liés à SSL sont -

    • Protocole de prise de contact SSL
    • Modifier le protocole de spécification de chiffrement
    • Protocole d'alerte.

  • Ces trois protocoles gèrent tous les échanges de messages SSL et sont abordés plus loin dans cette section.

Fonctions des composants du protocole SSL

Les quatre sous-composants du protocole SSL gèrent diverses tâches pour une communication sécurisée entre la machine cliente et le serveur.

  • Protocole d'enregistrement

    • La couche d'enregistrement formate les messages de protocole de couche supérieure.

    • Il fragmente les données en blocs gérables (longueur maximale 16 Ko). Il compresse éventuellement les données.

    • Crypte les données.

    • Fournit un en-tête pour chaque message et un hachage (Message Authentication Code (MAC)) à la fin.

    • Remet les blocs formatés à la couche TCP pour transmission.

  • Protocole de prise de contact SSL

    • C'est la partie la plus complexe de SSL. Il est appelé avant la transmission de toute donnée d'application. Il crée des sessions SSL entre le client et le serveur.

    • L'établissement de session implique l'authentification du serveur, la négociation des clés et des algorithmes, l'établissement des clés et l'authentification du client (facultatif).

    • Une session est identifiée par un ensemble unique de paramètres de sécurité cryptographiques.

    • Plusieurs connexions TCP sécurisées entre un client et un serveur peuvent partager la même session.

    • Actions de protocole de prise de contact en quatre phases. Ceux-ci sont discutés dans la section suivante.

  • Protocole ChangeCipherSpec

    • Partie la plus simple du protocole SSL. Il se compose d'un seul message échangé entre deux entités communicantes, le client et le serveur.

    • Lorsque chaque entité envoie le message ChangeCipherSpec, elle change son côté de la connexion en état sécurisé comme convenu.

    • L'état en attente des paramètres de chiffrement est copié dans l'état actuel.

    • L'échange de ce message indique que tous les futurs échanges de données sont cryptés et que l'intégrité est protégée.

  • Protocole d'alerte SSL

    • Ce protocole est utilisé pour signaler des erreurs - telles qu'un message inattendu, un mauvais enregistrement MAC, la négociation des paramètres de sécurité a échoué, etc.

    • Il est également utilisé à d'autres fins - comme notifier la fermeture de la connexion TCP, notifier la réception d'un certificat incorrect ou inconnu, etc.

Mise en place d'une session SSL

Comme indiqué ci-dessus, il existe quatre phases d'établissement de session SSL. Ceux-ci sont principalement gérés par le protocole SSL Handshake.

Phase 1 - Établir des capacités de sécurité.

  • Cette phase comprend l'échange de deux messages - Client_hello et Server_hello .

  • Client_hello contient la liste des algorithmes cryptographiques pris en charge par le client, par ordre décroissant de préférence.

  • Server_hello contient la spécification de chiffrement sélectionnée (CipherSpec) et un nouveau session_id .

  • Le CipherSpec contient des champs comme -

    • Algorithme de chiffrement (DES, 3DES, RC2 et RC4)

    • Algorithme MAC (basé sur MD5, SHA-1)

    • Algorithme à clé publique (RSA)

    • Les deux messages ont «nonce» pour empêcher les attaques de relecture.

Phase 2 - Authentification du serveur et échange de clés.

  • Le serveur envoie un certificat. Le logiciel client est configuré avec les clés publiques de diverses organisations «de confiance» (CA) pour vérifier le certificat.

  • Le serveur envoie la suite de chiffrement choisie.

  • Le serveur peut demander un certificat client. Habituellement, ce n'est pas fait.

  • Le serveur indique la fin de Server_hello .

Phase 3 - Authentification du client et échange de clés.

  • Le client envoie un certificat, uniquement sur demande du serveur.

  • Il envoie également le secret pré-maître (PMS) chiffré avec la clé publique du serveur.

  • Le client envoie également un message Certificate_verify si le certificat est envoyé par lui pour prouver qu'il a la clé privée associée à ce certificat. Fondamentalement, le client signe un hachage des messages précédents.

Phase 4 - Terminez.

  • Le client et le serveur s'envoient des messages Change_cipher_spec pour que l'état de chiffrement en attente soit copié dans l'état actuel.

  • Désormais, toutes les données sont cryptées et leur intégrité est protégée.

  • Le message «Terminé» de chaque extrémité vérifie que les processus d'échange de clés et d'authentification ont réussi.

Les quatre phases, décrites ci-dessus, se produisent lors de l'établissement de la session TCP. L'établissement de session SSL commence après TCP SYN / SYNACK et se termine avant TCP Fin.

Reprise d'une session déconnectée

  • Il est possible de reprendre une session déconnectée (via un message d' alerte ), si le client envoie un hello_request au serveur avec les informations cryptées session_id .

  • Le serveur détermine ensuite si session_id est valide. S'il est validé, il échange ChangeCipherSpec et les messages terminés avec le client et les communications sécurisées reprennent.

  • Cela évite de recalculer les paramètres de chiffrement de session et économise le calcul au niveau du serveur et du client.

Clés de session SSL

Nous avons vu que lors de la phase 3 de l'établissement de la session SSL, un secret pré-maître est envoyé par le client au serveur chiffré à l'aide de la clé publique du serveur. Le secret principal et diverses clés de session sont générés comme suit -

  • Le secret principal est généré (via un générateur de nombres pseudo aléatoires) en utilisant -

    • Le secret pré-maître.

    • Deux nonces (RA et RB) échangés dans les messages client_hello et server_hello.

  • Six valeurs secrètes sont ensuite dérivées de ce secret principal comme -

    • Clé secrète utilisée avec MAC (pour les données envoyées par le serveur)

    • Clé secrète utilisée avec MAC (pour les données envoyées par le client)

    • Clé secrète et IV utilisées pour le cryptage (par serveur)

    • Clé secrète et IV utilisées pour le chiffrement (par le client)

Protocole TLS

Afin de fournir une norme Internet ouverte de SSL, l'IETF a publié le protocole TLS (Transport Layer Security) en janvier 1999. TLS est défini comme une norme Internet proposée dans la RFC 5246.

Principales caractéristiques

  • Le protocole TLS a les mêmes objectifs que SSL.

  • Il permet aux applications client / serveur de communiquer de manière sécurisée en s'authentifiant, en empêchant les écoutes clandestines et en résistant à la modification des messages.

  • Le protocole TLS se trouve au-dessus de la couche TCP de transport orientée connexion fiable dans la pile de couches réseau.

  • L'architecture du protocole TLS est similaire au protocole SSLv3. Il a deux sous-protocoles: le protocole TLS Record et le protocole TLS Handshake.

  • Bien que les protocoles SSLv3 et TLS aient une architecture similaire, plusieurs modifications ont été apportées à l'architecture et au fonctionnement, en particulier pour le protocole de prise de contact.

Comparaison des protocoles TLS et SSL

Il existe huit principales différences entre les protocoles TLS et SSLv3. Ce sont les suivants -

  • Protocol Version - L'en-tête du segment de protocole TLS porte le numéro de version 3.1 pour différencier le numéro 3 porté par l'en-tête de segment de protocole SSL.

  • Message Authentication- TLS utilise un code d'authentification de message à hachage par clé (H-MAC). L'avantage est que H-MAC fonctionne avec n'importe quelle fonction de hachage, pas seulement MD5 ou SHA, comme indiqué explicitement par le protocole SSL.

  • Session Key Generation - Il existe deux différences entre les protocoles TLS et SSL pour la génération du matériel clé.

    • La méthode de calcul des secrets pré-maître et maître est similaire. Mais dans le protocole TLS, le calcul du secret principal utilise la norme HMAC et la sortie de la fonction pseudo-aléatoire (PRF) au lieu du MAC ad hoc.

    • L'algorithme de calcul des clés de session et des valeurs d'initiation (IV) est différent dans TLS du protocole SSL.

  • Message de protocole d'alerte -

    • Le protocole TLS prend en charge tous les messages utilisés par le protocole d'alerte de SSL, sauf Aucun message d'alerte de certificat n'est rendu redondant. Le client envoie un certificat vide au cas où l'authentification du client n'est pas requise.

    • De nombreux messages d'alerte supplémentaires sont inclus dans le protocole TLS pour d'autres conditions d'erreur telles que record_overflow, decode_error, etc.

  • Supported Cipher Suites- SSL prend en charge les suites de chiffrement RSA, Diffie-Hellman et Fortezza. Le protocole TLS prend en charge toutes les combinaisons sauf Fortezza.

  • Client Certificate Types- TLS définit les types de certificats à demander dans un message certificate_request . SSLv3 prend en charge tous ces éléments. De plus, SSL prend en charge certains autres types de certificats tels que Fortezza.

  • CertificatVérification et messages terminés -

    • Dans SSL, une procédure de message complexe est utilisée pour le message certificate_verify . Avec TLS, les informations vérifiées sont contenues dans les messages de prise de contact eux-mêmes, évitant ainsi cette procédure complexe.

    • Le message terminé est calculé de différentes manières en TLS et SSLv3.

  • Padding of Data- Dans le protocole SSL, le remplissage ajouté aux données utilisateur avant le chiffrement est la quantité minimale requise pour rendre la taille totale des données égale à un multiple de la longueur de bloc du chiffrement. Dans TLS, le remplissage peut être n'importe quelle quantité qui se traduit par une taille de données qui est un multiple de la longueur de bloc du chiffrement, jusqu'à un maximum de 255 octets.

Les différences ci-dessus entre les protocoles TLS et SSLv3 sont résumées dans le tableau suivant.

Navigation sécurisée - HTTPS

Dans cette section, nous discuterons de l'utilisation du protocole SSL / TLS pour effectuer une navigation Web sécurisée.

HTTPS défini

Le protocole HTTP (Hyper Text Transfer Protocol) est utilisé pour la navigation Web. La fonction de HTTPS est similaire à HTTP. La seule différence est que HTTPS offre une navigation Web «sécurisée». HTTPS signifie HTTP sur SSL. Ce protocole est utilisé pour fournir la connexion cryptée et authentifiée entre le navigateur Web client et le serveur du site Web.

La navigation sécurisée via HTTPS garantit que le contenu suivant est crypté -

  • URL de la page Web demandée.
  • Contenu de la page Web fourni par le serveur au client utilisateur.
  • Contenu des formulaires remplis par l'utilisateur.
  • Cookies établis dans les deux sens.

Fonctionnement de HTTPS

Le protocole d'application HTTPS utilise généralement l'un des deux protocoles de sécurité de couche de transport les plus courants: SSL ou TLS. Le processus de navigation sécurisée est décrit dans les points suivants.

  • Vous demandez une connexion HTTPS à une page Web en saisissant https: // suivi de l'URL dans la barre d'adresse du navigateur.

  • Le navigateur Web établit une connexion au serveur Web. L'utilisation de https appelle l'utilisation du protocole SSL.

  • Une application, navigateur dans ce cas, utilise le port système 443 au lieu du port 80 (utilisé dans le cas de http).

  • Le protocole SSL passe par un protocole d'établissement de liaison pour établir une session sécurisée, comme indiqué dans les sections précédentes.

  • Le site Web envoie initialement son certificat numérique SSL à votre navigateur. Lors de la vérification du certificat, la négociation SSL progresse pour échanger les secrets partagés pour la session.

  • Lorsqu'un certificat numérique SSL de confiance est utilisé par le serveur, les utilisateurs voient une icône de cadenas dans la barre d'adresse du navigateur. Lorsqu'un certificat de validation étendue est installé sur un site Web, la barre d'adresse devient verte.

  • Une fois établie, cette session consiste en de nombreuses connexions sécurisées entre le serveur Web et le navigateur.

Utilisation de HTTPS

  • L'utilisation de HTTPS assure la confidentialité, l'authentification du serveur et l'intégrité des messages à l'utilisateur. Il permet une conduite sûre du commerce électronique sur Internet.

  • Empêche les données d'être écoutées et refuse le vol d'identité qui sont des attaques courantes sur HTTP.

Les navigateurs Web et les serveurs Web actuels sont équipés du support HTTPS. Cependant, l'utilisation de HTTPS sur HTTP nécessite plus de puissance de calcul au niveau du client et du serveur pour effectuer le cryptage et la négociation SSL.

Protocole Secure Shell (SSH)

Les principales caractéristiques de SSH sont les suivantes:

  • SSH est un protocole réseau qui s'exécute au-dessus de la couche TCP / IP. Il est conçu pour remplacer le TELNET qui fournissait des moyens non sécurisés de connexion à distance.

  • SSH fournit une communication client / serveur sécurisée et peut être utilisé pour des tâches telles que le transfert de fichiers et le courrier électronique.

  • SSH2 est un protocole répandu qui offre une sécurité de communication réseau améliorée par rapport à la version antérieure SSH1.

Défini par SSH

SSH est organisé en trois sous-protocoles.

  • Transport Layer Protocol- Cette partie du protocole SSH assure la confidentialité des données, l'authentification du serveur (hôte) et l'intégrité des données. Il peut également fournir une compression de données.

    • Server Authentication- Les clés d'hôte sont asymétriques comme les clés publiques / privées. Un serveur utilise une clé publique pour prouver son identité à un client. Le client vérifie que le serveur contacté est un hôte «connu» de la base de données qu'il gère. Une fois le serveur authentifié, les clés de session sont générées.

    • Session Key Establishment- Après authentification, le serveur et le client conviennent du chiffrement à utiliser. Les clés de session sont générées à la fois par le client et le serveur. Les clés de session sont générées avant l'authentification de l'utilisateur afin que les noms d'utilisateur et les mots de passe puissent être envoyés cryptés. Ces clés sont généralement remplacées à intervalles réguliers (par exemple, toutes les heures) pendant la session et sont détruites immédiatement après utilisation.

    • Data Integrity- SSH utilise des algorithmes MAC (Message Authentication Code) pour vérifier l'intégrité des données. C'est une amélioration par rapport au CRC 32 bits utilisé par SSH1.

  • User Authentication Protocol- Cette partie de SSH authentifie l'utilisateur auprès du serveur. Le serveur vérifie que l'accès est accordé uniquement aux utilisateurs prévus. De nombreuses méthodes d'authentification sont actuellement utilisées telles que les mots de passe saisis, Kerberos, l'authentification par clé publique, etc.

  • Connection Protocol - Cela fournit plusieurs canaux logiques sur une seule connexion SSH sous-jacente.

Services SSH

SSH fournit trois services principaux qui permettent de fournir de nombreuses solutions sécurisées. Ces services sont brièvement décrits comme suit -

  • Secure Command-Shell (Remote Logon)- Il permet à l'utilisateur de modifier des fichiers, d'afficher le contenu des répertoires et d'accéder aux applications sur le périphérique connecté. Les administrateurs système peuvent démarrer / afficher / arrêter à distance des services et des processus, créer des comptes d'utilisateurs et modifier les autorisations de fichiers / répertoires, etc. Toutes les tâches réalisables à l'invite de commande d'une machine peuvent désormais être effectuées en toute sécurité à partir de la machine distante à l'aide d'une connexion à distance sécurisée.

  • Secure File Transfer- Le protocole de transfert de fichiers SSH (SFTP) est conçu comme une extension de SSH-2 pour un transfert de fichiers sécurisé. En substance, il s'agit d'un protocole distinct superposé au protocole Secure Shell pour gérer les transferts de fichiers. SFTP crypte à la fois le nom d'utilisateur / mot de passe et les données du fichier en cours de transfert. Il utilise le même port que le serveur Secure Shell, c'est-à-dire le port système n ° 22.

  • Port Forwarding (Tunneling)- Il permet de sécuriser les données des applications basées sur TCP / IP non sécurisées. Une fois la redirection de port configurée, Secure Shell redirige le trafic d'un programme (généralement un client) et l'envoie à travers le tunnel crypté vers le programme de l'autre côté (généralement un serveur). Plusieurs applications peuvent transmettre des données sur un seul canal sécurisé multiplexé, éliminant ainsi le besoin d'ouvrir de nombreux ports sur un pare-feu ou un routeur.

Avantages et limitations

Les avantages et les limites de l'utilisation de la sécurité des communications au niveau de la couche transport sont les suivants:

  • Avantages

    • Transport Layer Security est transparent pour les applications.

    • Le serveur est authentifié.

    • Les en-têtes de couche d'application sont masqués.

    • Il est plus fin que les mécanismes de sécurité de la couche 3 (IPsec) car il fonctionne au niveau de la connexion de transport.

  • Limites

    • Applicable uniquement aux applications basées sur TCP (pas UDP).

    • Les en-têtes TCP / IP sont en clair.

    • Convient pour une communication directe entre le client et le serveur. Ne prend pas en charge les applications sécurisées utilisant une chaîne de serveurs (par exemple, e-mail)

    • SSL ne fournit pas de non-répudiation car l'authentification client est facultative.

    • Si nécessaire, l'authentification client doit être implémentée au-dessus de SSL.

Sommaire

Un grand nombre d'applications Web ont vu le jour sur Internet au cours de la dernière décennie. De nombreux portails de gouvernance électronique et de commerce électronique ont été mis en ligne. Ces applications exigent que la session entre le serveur et le client soit sécurisée, garantissant la confidentialité, l'authentification et l'intégrité des sessions.

Une façon d'atténuer une attaque potentielle pendant la session d'un utilisateur consiste à utiliser un protocole de communication sécurisé. Deux de ces protocoles de communication, Secure Sockets Layer (SSL) et Transport Layer Security (TLS), sont traités dans ce chapitre. Ces deux protocoles fonctionnent au niveau de la couche Transport.

Un autre protocole de couche de transport, Secure Shell (SSH), conçu pour remplacer TELNET, fournit des moyens sécurisés de connexion à distance. Il est capable de fournir divers services tels que Secure Command Shell et SFTP.

L'emploi de la sécurité de la couche de transport présente de nombreux avantages. Cependant, le protocole de sécurité conçu à ces niveaux ne peut être utilisé qu'avec TCP. Ils n'assurent pas la sécurité des communications implémentées à l'aide d'UDP.