Qu'est-ce qui a changé entre TLS et DTLS
Qu'est-ce que les auteurs DTLS (TLS sur UDP) ont dû changer pour qu'il puisse fonctionner sans TCP?
Points bonus: l'une des différences de protocole affecte-t-elle la façon dont il doit être utilisé, à la fois en termes d'interface mais aussi de meilleures pratiques?
DTLS est actuellement (version 1.2) défini dans RFC 6347 en expliquant les différences avec TLS 1.2 ( RFC 5246 ). La plupart des éléments TLS sont réutilisés avec seulement les plus petites différences.
Le contexte est que le client et le serveur veulent s’envoyer beaucoup de données sous forme de "datagrammes"; ils vraiment veulent tous les deux envoyer une longue séquence d'octets, avec un ordre défini, mais ne bénéficient pas du luxe de TCP . TCP fournit un tunnel bidirectionnel fiable pour les octets, où tous les octets finissent par atteindre le récepteur dans le même ordre que celui utilisé par l'expéditeur; TCP réalise cela à travers un complexe Assemblage de messages d'accusé de réception, de délais de transmission et de réémissions. Cela permet à TLS de simplement supposer que les données resteront indemnes dans des conditions normales; en d'autres termes, TLS les juge suffisantes pour détecte les altérations , car ces altérations ne se produisent que lorsqu'elles sont attaquées.
D'un autre côté, DTLS fonctionne sur des datagrammes qui peuvent être perdus, dupliqués ou reçus dans le mauvais ordre. Pour y faire face, DTLS utilise des mécanismes et une clémence supplémentaires.
Les principales différences sont les suivantes:
Enregistrements explicites . Avec TLS, vous avez un long flux d'octets, que l'implémentation TLS décide de diviser en enregistrements comme bon lui semble; cette répartition est transparente pour les applications. Ce n'est pas le cas avec DTLS: chaque enregistrement DTLS est mappé à un datagramme. Les données sont reçues et envoyées sur une base d'enregistrement, et un enregistrement est reçu complètement ou pas du tout. De plus, les applications doivent gérer elles-mêmes la découverte de MTU de chemin.
Numéros de séquence explicites . Les enregistrements TLS incluent un MAC qui garantit l'intégrité de l'enregistrement, et l'entrée MAC comprend un numéro de séquence d'enregistrement qui vérifie ainsi qu'aucun enregistrement n'a été perdu, dupliqué ou réorganisé . Dans TLS, ce numéro de séquence (un entier 64 bits) est implicite (c'est toujours un de plus que l'enregistrement précédent). Dans DTLS, le numéro de séquence est explicite dans chaque enregistrement (c'est donc une surcharge supplémentaire de 8 octets par enregistrement - ce n'est pas grave). Le numéro de séquence est en outre divisé en une "Epoch" de 16 bits et un numéro de sous-séquence de 48 bits, pour mieux gérer les renégociations de suites de chiffrement.
Les modifications sont tolérées . Les datagrammes peuvent être perdus, dupliqués, réorganisés ou même modifiés. C'est une "réalité" que TLS détesterait, mais DTLS accepte. Ainsi, le client et le serveur sont censés tolérer un peu d'abus; ils utilisent un mécanisme de "fenêtre" pour donner un sens aux enregistrements qui sont "un peu tôt" (s'ils reçoivent des enregistrements dans l'ordre 1 2 5 3 4 6, la fenêtre gardera l'enregistrement "5" dans un tampon jusqu'à ce que les enregistrements 3 et 4 sont reçus, ou le récepteur décide que les enregistrements 3 et 4 ont été perdus et doivent être ignorés). Les doublons PEUVENT être avertis, ainsi que les enregistrements pour lesquels le MAC ne correspond pas; mais, en général, les enregistrements anormaux (manquants, dupliqués, trop tôt au-delà de la portée de la fenêtre, trop anciens, modifiés ...) sont simplement supprimés.
Cela signifie que l'implémentation DTLS ne fait pas (et, vraiment, ne peut pas) faire la distinction entre le "bruit" normal (erreurs aléatoires qui peuvent se produire) et une attaque active. Ils peuvent utiliser un certain seuil (s'il y a trop d'erreurs, avertir l'utilisateur).
Cryptage sans état . Comme les enregistrements peuvent être perdus, le chiffrement ne doit pas utiliser un état qui est modifié avec chaque enregistrement. En pratique, cela signifie pas de RC4.
Aucune terminaison vérifiée . DTLS n'a aucune notion de fin de connexion vérifiée comme ce que fait TLS avec le
close_notifymessage d'alerte. Cela signifie que lorsqu'un récepteur cesse de recevoir des datagrammes de l'homologue, il ne peut pas savoir si l'expéditeur a volontairement cessé d'envoyer ou si le reste des données a été perdu. Notez qu'une telle chose était considérée comme l'un des péchés capitaux de SSL 2.0, mais pour DTLS, cela semble être OK. Il appartient au format de données transmis dans DTLS de prévoir une terminaison explicite, si une telle chose est nécessaire.Fragmentation et réémission . Les messages de prise de contact peuvent dépasser la longueur naturelle du datagramme et peuvent donc être répartis sur plusieurs enregistrements. La syntaxe des messages d'établissement de liaison est étendue pour gérer ces fragments. La gestion des fragments nécessite des tampons, donc les implémentations DTLS nécessiteront probablement un peu plus RAM que les implémentations TLS (c'est-à-dire des implémentations optimisées pour les systèmes embarqués où RAM est rare; les implémentations TLS pour le bureau et les serveurs allouent simplement des tampons assez grands et DTLS ne sera pas pire pour eux.) La réémission se fait via une machine d'état, qui est un peu plus complexe à implémenter que la simple prise de contact TLS (mais la RFC décrit bien).
Protection contre DoS/usurpation . Puisqu'un datagramme peut être envoyé "tel quel", il est sujet à l'usurpation d'adresse IP: un malfaiteur peut envoyer un datagramme avec une fausse adresse source. En particulier un message
ClientHello. Si le serveur DTLS alloue des ressources lorsqu'il reçoit unClientHello, alors il y a amplement de place pour DoS . Dans le cas de TLS, unClientHellone se produit qu'après la prise de contact à trois voies de TCP est terminée, ce qui implique que le client utilise une adresse IP source qu'il peut réellement recevoir Être capable de faire un serveur sans montrer votre véritable IP est une arme puissante, donc DTLS inclut une défense optionnelle.Le mécanisme défensif dans DTLS est un "cookie": le client envoie son
ClientHello, auquel le serveur répond avec un messageHelloVerifyRequestqui contient un cookie opaque, que le client doit renvoyer en tant que secondeClientHello. Le serveur doit organiser un type de cookie qui peut être vérifié sans enregistrer l'état; c'est-à-dire un cookie avec un horodatage et un MAC (curieusement, le RFC fait allusion à un tel mécanisme mais ne le spécifie pas complètement - il y a des chances que certaines implémentations se trompent ).Ce mécanisme de cookie est en fait une émulation de la négociation à trois voies TCP. Il implique un aller-retour supplémentaire, c'est-à-dire ramène DTLS aux performances TLS sur TCP pour la négociation initiale.
En dehors de cela, DTLS est similaire à TLS. Les suites de chiffrement non RC4 de TLS s'appliquent à DTLS. DTLS 1.2 est protégé contre les attaques de type BEAST car, comme TLS 1.2, il inclut une IV aléatoire par enregistrement lors de l'utilisation du cryptage CBC.
Pour résumer, les fonctionnalités supplémentaires de DTLS sont des importations conceptuelles de TCP (fenêtre de réception, réassemblage avec des numéros de séquence, réémissions, cookie de connexion ...) jeté sur un TLS normal (la seule omission importante est la manque de messages d'accusé de réception.) Le protocole est plus indulgent en ce qui concerne les modifications, et n'inclut pas une "fin de transmission" vérifiée (mais DTLS est censé être utilisé dans des contextes où cela n'aurait pas vraiment de sens de toute façon).
Le domaine d'application de DTLS est vraiment distinct de celui de TLS; il est destiné à être appliqué aux applications de streaming de données où les pertes sont moins importantes que la latence, par ex. VoIP ou flux vidéo en direct. Pour une application donnée, soit TLS est beaucoup plus logique que DTLS, ou l'inverse; la meilleure pratique consiste à choisir le protocole approprié .
Il existe des différences clés entre DTLS et le protocole TLS (Transport Layer Security) dont le programmeur d'application doit être conscient que l'autre réponse qui manque/implique n'existe pas!
Le protocole DTLS assure la confidentialité des communications pour les protocoles de datagramme. Contrairement à la réponse LONG et généralement informative très bien notée à ce jour (archive) , DTLS n'est pas utilisé lorsque TCP n'est pas disponible (par les applications qui ne bénéficient pas du luxe de TCP. La principale différence est que, bien qu'une implémentation DTLS gère les problèmes de réorganisation et de perte de paquets, elle le fait only pour les paquets utilisés pour la prise de contact DTLS (et la sélection de chiffrement). Cependant, les paquets DTLS contenant la charge utile (données d'application), fournissent leur charge utile pas plus de manière fiable que les paquets DTLS (généralement UDP) qui les encapsulent L'avantage est que DTLS fournit des données d'application plus rapidement et avec une latence plus faible. Pour les points bonus: c'est pourquoi DTLS est utilisé pour sécuriser les applications de streaming où les pertes sont moins importantes que la latence, par exemple VoIP, flux vidéo en direct et MMO jeu. TLS est destiné à fournir un flux de données fiable et avec un cryptage authentifié, de bout en bout. DTLS est destiné à la livraison d'applicat des données ioniques authentifiées et chiffrées de bout en bout, mais avec une latence inférieure à celle qui peut être obtenue lorsque toutes les données d'application sont garanties.
De plus, alors que le protocole DTLS (v1.2) est dérivé du protocole TLS (v1.2) et revendications pour "fournir des garanties de sécurité équivalentes", ce n'est pas le cas . 2 En 2013, les chercheurs ont identifié des lacunes de sécurité majeures dans les implémentations DTLS et dans le protocole DTLS lui-même, qui ont depuis été corrigées, au moins dans les implémentations GnuTLS et OpenSSL . 2
PS: DTLS 1.3 est en développement .