Pourquoi TCP plus sûr qu'UDP?
Lors de la lecture des présentations MS SDL, j'ai trouvé une recommandation pour remplacer UDP par TCP dans les applications car TCP est plus sécurisé que UDP. Mais les deux ne sont que des couches de transport) , rien de plus.
Alors pourquoi TCP plus sûr qu'UDP?
Pour envoyer des données à une application via TCP, vous devez d'abord établir une connexion. Jusqu'à ce que la connexion soit établie, les paquets n'atteignent que la couche OS, pas l'application. L'établissement d'une connexion nécessite que vous receviez les paquets à la fin de l'initiation. Si vous vouliez forger une adresse IP qui ne se trouve pas sur votre propre réseau et établir une connexion TCP, vous devez pouvoir intercepter les paquets envoyés par l'autre côté (vous devez être "entre" le point de terminaison, et où les paquets vers l'adresse IP falsifiée iraient normalement, ou faire d'autres astuces de routage intelligentes.)
UDP n'a pas de connexion, vous pouvez donc forger un paquet avec une adresse IP arbitraire et il devrait arriver à l'application. Vous ne recevrez toujours pas de paquets à moins que vous ne soyez bien au bon endroit. Que cela compte ou non dépend de la sécurité que vous mettez dans l'application. Si vous deviez faire confiance à certaines adresses IP plus qu'à d'autres dans l'application, cela peut être un problème.
Donc, dans ce sens, TCP est plus "sécurisé" que UDP. Selon l'application, cela peut ou non être pertinent pour la sécurité. En soi, ce n'est pas une bonne raison de remplacer UDP avec TCP car il y a d'autres compromis impliqués entre les deux protocoles.
L'UDP ordinaire ne garde pas l'état, n'a pas de poignée de main, etc. Cela signifie qu'un attaquant pourrait facilement envoyer un paquet usurpé à moins qu'il n'y ait des protections sur d'autres couches.
D'un autre côté, l'envoi d'un paquet usurpé TCP nécessite que l'attaquant devine le numéro de séquence et le port client d'une connexion établie.
TCP n'est pas plus sécurisé que UDP, il est plus "fiable" car il est dynamique et nécessite la reconnaissance de chaque segment. UDP est sans état et envoie simplement des segments sans savoir que le client les obtient ou non.
Les fonctionnalités de sécurité sur mesure ne sont pas non plus disponibles pour les autres, les différences sont essentiellement dues aux différentes exigences de chaque protocole, les avantages de sécurité perçus sont des sous-produits des protocoles fonctionnellement plutôt qu'une fonctionnalité de sécurité délibérée.
EDIT: UDP et TCP ont des utilisations spécifiques, aucune de ces utilisations ne concerne la sécurité.
Les deux protocoles s'appuient sur d'autres protocoles pour assurer la sécurité. Donc, bien que TCP puisse avoir une surface d'attaque légèrement plus petite, cela n'a vraiment aucune conséquence pour sécuriser soit vous avez besoin d'un protocole orienté sécurité. Protocole tel que DTLS ou googles QUIC.
Choisir d'implémenter TCP pour un cas d'utilisation qui convient mieux à UDP, plutôt que de sécuriser UDP correctement (TCP nécessiterait également la sécurisation dans la plupart des cas d'utilisation), serait comme utiliser un fer 9 pour mettre parce que vous pensez qu'un fer 9 serait une meilleure arme pour vous défendre dans un combat ... quand vous avez un pistolet dans votre poche.
TCP plus sûr qu'UDP?
Oui, mais nous devons être très clairs sur ce dont nous parlons lorsque nous parlons de "sécurité" et ne pas généraliser cette déclaration aux protocoles de couche supérieure.
Actuellement, security est souvent associé à la triade [~ # ~] cia [~ # ~]:
- C onfidentialité.
- I intégrité.
- A disponibilité.
La version 4 du protocole IP, qui est toujours la plus utilisée actuellement, est une très vieille bête qui a été développée au cours des années 70 et 80.
A cette époque, la confidentialité n'était pas vraiment un sujet et ce qui était vraiment visé était d'atteindre l'intégrité et la disponibilité (le réseau Arpanet, l'ancêtre d'Internet qui a donné naissance au protocole IP, a été conçu pour assurer une continuité de service même dans les en cas de guerre nucléaire, pas pour protéger les données en transit).
Dans cette optique, deux protocoles de transport ont été développés sur la couche IP: TCP et UDP.
TCP a été conçu pour garantir à la fois les propriétés intégrité et disponibilité. Il comprend ce qui était à l'époque des techniques avancées telles qu'une prise de contact à trois voies, la négociation des paramètres, la gestion de divers états de connexion, la réorganisation transparente des paquets, les fenêtres d'accusé de réception et les mécanismes de nouvelle tentative. Cela apporte de bonnes garanties à l'expéditeur que les données qu'il a envoyées ont été reçues sous une forme complète et non corrompue (c'est-à-dire aucune partie manquante, modifiée ou non ordonnée).
Rappelez cependant que ce que ce protocole visait était une catastrophe technique, pas une falsification malveillante des données en transit. Cette question était complètement hors de portée à l'époque.
UDP au contraire a été conçu pour être un protocole rapide. Il n'a aucune des fonctionnalités mentionnées ci-dessus, et donc aucun de leurs frais généraux. En particulier, lorsque l'expéditeur envoie des données en utilisant UDP, les données reçues peuvent être incomplètes, non ordonnées ou pas reçues du tout: le protocole UDP en lui-même ne fournit aucun mécanisme pour empêcher ou détecter cela ni du côté de l'expéditeur ni du côté du récepteur.
De cette façon, en se concentrant sur les propriétés d'intégrité et de disponibilité des données de sécurité, TCP est en effet plus sécurisé que UDP.
Un protocole d'application reposant sur TCP est-il plus sécurisé qu'un protocole reposant sur UDP?
Certainement pas.
Cela signifie seulement que les personnes développant un protocole d'application reposant sur UDP auront plus de travail car elles devront peut-être implémenter dans leur protocole d'application des solutions de contournement pour les fonctionnalités manquantes dans le protocole UDP. Ils devront tenir compte du fait que les données envoyées peuvent ne pas être nécessairement reçues, que les données reçues peuvent ne pas être dans le bon ordre, etc. Ce sont tous des problèmes bien connus.
OpenVPN par exemple, alors qu'il prend en charge TCP principalement pour la compatibilité avec les pare-feu restrictifs, fonctionne par défaut et fonctionne mieux sur UDP. Le basculer sur TCP est possible mais n'augmente en rien sa sécurité car la différence entre le protocole UDP à deux couches de transport et TCP est entièrement gérée par OpenVPN lui-même. Le basculer sur TCP ne fera que ajoutez le TCP surcharge au protocole OpenVPN, réduisant ainsi ses performances.
TCP meilleur que UDP?
Non, il s'agit entièrement d'un choix de conception de protocole d'application.
UDP est un protocole plus brut. Lorsqu'il est utilisé correctement et avec précaution, il peut-être atteint de meilleures performances que TCP au prix d'un développement et d'une maintenance plus difficiles du protocole d'application.
- Lorsque l'application n'est pas sensible au temps, TCP s'impose comme le choix naturel car il n'est pas nécessaire de réinventer la roue.
- Lorsque l'application est sensible au temps, une discussion doit avoir lieu sur laquelle choisir sachant que chacun aura ses inconvénients: a potentiel pénalité de performance avec TCP contre un certainement application plus complexe avec UDP.
La plupart des protocoles ne sont pas sensibles au temps et donc TCP est le protocole le plus utilisé. En effet, lorsque vous chargez une page Web ou recevez un e-mail, il n'y a aucune différence si vous le recevez 10 millisecondes tôt ou tard. .
Le streaming multimédia et DNS sont deux exemples classiques de protocoles utilisant UDP, en plus de l'OpenVPN cité précédemment.
Avec le streaming multimédia, vous ne vous souciez pas vraiment si une image vidéo ou quelques millisecondes de vidéo ou audio sont manquantes, tant que la vidéo ou l'audio est lue de manière fluide et synchrone. Dans ce cas, vous ne voulez pas induire de pauses répétitives car TCP a détecté un paquet manquant et a demandé à l'expéditeur de renvoyer le contenu de la dernière fenêtre d'accusé de réception.
Avec DNS, les demandes et les réponses sont généralement très courtes et vous souhaitez que le processus de résolution de nom soit aussi rapide que possible (notez que les réponses plus longues et moins sensibles au temps telles que les transferts de zone DNS se produisent toujours sur TCP). Il est plus rapide de renvoyer la demande de résolution de nom au serveur DNS sur les très rares fois où la demande ou sa réponse est perdue que de traiter une négociation à trois voies à part entière pour chaque demande.
Qu'en est-il de la confidentialité et des reniflements/falsifications malveillants (et IPv6)?
Tout ce qui nous importait jusqu'à présent était, dans l'esprit de cet ancien IPv4, l'équilibre entre la vitesse de transmission et l'intégrité des données + la disponibilité. Maintenant, si nous voulons ajouter la confidentialité en plus de cela, nous pouvons le faire mais cela devra être fait au niveau de la couche application car, comme indiqué précédemment, IPv4 n'est pas concerné par les problèmes de confidentialité.
Une implémentation moderne et complète de la sécurité peut être implémentée au niveau de la couche application et s'appuyer sur les protocoles TCP ou UDP (ou les deux) sans aucun impact sur la sécurité du protocole d'application lui-même (voir l'exemple d'OpenVPN ci-dessus).
Cependant, comme indiqué au début, IPv4 vient vraiment d'un autre âge informatique. Il a obtenu un successeur du nom de IPv6, qui prend en charge nativement IPSec au niveau de la couche IP, fournissant ainsi des services de sécurité plus modernes ci-dessous des protocoles de transport tels que UDP et TCP.
Cela permet de déléguer le chiffrement des données en transit de l'application à la couche réseau, et permet à UDP et à TCP de fournir exactement les mêmes garanties de sécurité. Cependant, dans la plupart des scénarios, le gain de performances UDP sera contrebalancé par la surcharge IPSec, donc je ne suis pas sûr qu'il y aurait un avantage à utiliser UDP à la place TCP tant que IPv6 IPSec est utilisé.
Pas vraiment.
Aucun de ces protocoles n'a de fonctionnalités intégrées destinées à assurer la confidentialité. Toute sécurité est censée être fournie par les couches de protocole ci-dessus (ou ci-dessous ).
TCP est un protocole plus complexe que UDP, ce qui le rend un peu plus difficile à usurper, mais ces complications sont rarement un obstacle sérieux.
Lorsque les gens disent que TCP est "plus fiable" que UDP, ils ne font pas référence à la sécurité. TCP est plus fiable car il garantit que tous les segments sont reçus dans l'ordre et tous les segments perdus sont retransmis. UDP ne le garantit pas. Lorsque la connexion est mauvaise, les segments UDP peuvent se perdre sans laisser de trace ou arriver dans le mauvais ordre. La façon de traiter ce problème dépend de l'application.
TCP est "basé sur la connexion", ce qui signifie qu'il a une fiabilité intégrée, sous la forme de numéros de séquence. Ainsi, par exemple, je vous envoie une image sur TCP mais, 1/4 des paquets sont perdus. Comme nous avons un protocole basé sur la connexion avec des numéros de séquence, votre ordinateur saura que vous êtes manquer ces données et donc me demander ces données afin d'avoir l'intégrité des données. C'est plus lent mais beaucoup plus sûr. De plus, pour usurper des paquets TCP/IP, vous devez attraper ce numéro de séquence et envoyer un paquet malveillant. Sans homme au milieu, c'est presque impossible!
UDP est un protocole "sans connexion", ce qui signifie qu'il envoie simplement les données et oublie. Il n'y a pas de fiabilité ou d'intégrité des données, mais c'est plus rapide et plus efficace pour certaines applications.
En pratique, TCP est plus facile à contrôler dans un réseau pare-feu: le trafic se rapportant aux connexions établies en externe et en interne, et donc les rôles client vs serveur, peut être clairement distingué et gérées par une stratégie distincte. Par exemple, vous pouvez garantir de manière triviale que les hôtes d'un réseau protégé peuvent accéder à un serveur Web externe mais ne pourront pas agir en tant que serveur Web pour des clients externes. Pour les services UDP (par exemple DNS), appliquer ces stratégies nécessite beaucoup plus d'intelligence et de conjectures, car vous devez prendre en compte les informations au-dessus et en dessous de la couche de transport.
TCP n'est pas "plus sécurisé" que UDP:
- TCP n'a pas de fonction de cryptage en soi ;
- La transmission de paquets TCP est fiable, mais vous pouvez l'émuler sur UDP.
UDP n'est qu'une couche mince au-dessus des paquets IP, tandis que TCP possède des mécanismes supplémentaires complexes - et standard -, qui font partie des systèmes d'exploitation.
Il vaut la peine de jeter un coup d'œil au projet QUIC, pour en savoir plus sur les différences TCP/UDP, et pourquoi Google a créé sa propre couche de transport HTTP/2 sécurisée sur UDP au lieu de TCP.
Citons https://www.chromium.org/quic :
Les principaux avantages de QUIC par rapport à TCP + TLS + HTTP2 incluent:
- Latence d'établissement de connexion
- Contrôle amélioré de la congestion
- Multiplexage sans blocage en tête de ligne
- Correction d'erreur directe
- Migration de connexion
Définissons quelques avantages/inconvénients de la sécurité prospective pour chacun et voyons:
UDP
- (+) Relativement difficile à analyser les ports ouverts UDP, et aucune analyse furtive n'existe (demi-connexion dans TCP en envoyant SYN).
- (-) Les périphériques réseau (par exemple les pare-feu avec état, NAT) ont du mal à contrôler les connexions UDP, car il n'y a pas de FLAGS sur lesquels s'appuyer.
- (-) Les attaques réfléchies sont plus courantes en raison de l'absence de connexion.
- (-) L'usurpation d'adresse IP est facile et utilisée dans les attaques DoS.
TCP
- (-) Le scan furtif peut détecter les ports ouverts TCP (envoyer SYN uniquement pour détecter les ports ouverts))
- (+) Les périphériques réseau (par exemple les pare-feu avec état) peuvent facilement suivre et contrôler les connexions TCP.
- (+) La falsification de paquets n'est pas facile, car elle nécessite de fournir le `numéro de séquence et le numéro d'accusé de réception corrects.
- (+) Pas aussi facile que UDP pour usurper l'IP à cause de la prise de contact initiale.
Actuellement, TCP n'est pas plus sécurisé que UDP. TCP est plus fiable que UDP car TCP peut détecter et retransmettre une erreur) paquets.
Si l'on souhaite avoir une transmission de données sécurisée, alors vous envisagez d'utiliser un cryptage de format tel que TLS ou IPSec.
TCP a un concept de connexion, pas UDP. Cependant, le concept de connexion est à la fois une force et une faiblesse du point de vue de la sécurité. La principale force de sécurité de la connexion est qu'elle est normalisée, le développeur d'applications, l'équipement réseau et les pare-feu peuvent tous s'appuyer sur une méthode fixe pour établir la connexion, gérer la fragmentation des paquets, la retransmission, etc. De plus, le concept de connexion facilite la création de couches de sécurité supplémentaires, par exemple SSL.
Cependant, une connexion TCP ne fournit pas beaucoup de protection contre une attaque qui cible directement la couche de transport, par exemple une attaque SYN flood. Avec UDP, vous pouvez théoriquement authentifier chaque paquet pour atténuer certains d'entre eux des risques.
Par conséquent, je dirais que UDP est "théoriquement" plus sûr que TCP, mais nous vivons dans un monde où la sécurité n'est pas parfaite, donc la force théorique est quelque peu dénuée de sens. Dans le monde réel, il est possible de trouver des exemples dans les deux sens - où un protocole a échoué d'une manière à laquelle l'autre n'aurait pas été vulnérable.
En résumé, je ne pense pas qu'il y ait de réponse à quel protocole est plus "sécurisé" dont vous avez besoin pour qualifier votre question avec les menaces qui vous préoccupent et combien et combien de temps vous êtes prêt à passer pour les atténuer. Si ce sont toutes des menaces et que vous avez une infinité de temps et d'argent, ma réponse théorique tient.