Général

SSL (et son successeur, TLS ) est un protocole qui fonctionne directement sur TCP (bien quil existe également des implémentations pour les protocoles basés sur les datagrammes tels que UDP). De cette façon, les protocoles sur les couches supérieures (comme HTTP) peuvent rester inchangés pendant que s jusquà fournir une connexion sécurisée. Sous la couche SSL, HTTP est identique à HTTPS.

Lors de lutilisation correcte de SSL / TLS, tout ce quun attaquant peut voir sur le câble est ladresse IP et le port auxquels vous êtes connecté, approximativement la quantité de données que vous envoyez , et quel cryptage et quelle compression sont utilisés. Il peut également mettre fin à la connexion, mais les deux parties sauront que la connexion a été interrompue par un tiers.

Dans une utilisation typique, lattaquant sera également en mesure de déterminer à quel nom dhôte vous vous connectez. (mais pas le reste de lURL): bien que HTTPS lui-même nexpose pas le nom dhôte, votre navigateur devra généralement faire une requête DNS dabord pour savoir à quelle adresse IP envoyer la requête.

Élevé -niveau description du protocole

Après avoir établi une connexion TCP, la prise de contact SSL est lancée par le client. Le client (qui peut être un navigateur ainsi que tout autre programme tel que Windows Update ou PuTTY) envoie un certain nombre de spécifications:

• quelle version de SSL / TLS il exécute,
• ce que ciphersuites il souhaite utiliser et
• ce que méthodes de compression quil souhaite utiliser.

Le serveur identifie la version SSL / TLS la plus élevée prise en charge à la fois par lui et le client, choisit une suite de chiffrement parmi lune des options du client (si elle en prend en charge une), et choisit éventuellement une méthode de compression.

Une fois la configuration de base terminée, le serveur envoie son certificat. Ce certificat doit être approuvé par le client lui-même ou par une partie en qui le client fait confiance. Par exemple, si le client fait confiance à GeoTrust, il peut alors faire confiance au certificat de Google.com car GeoTrust certificat de Google « signé de manière cryptographique .

Après avoir vérifié le certificat et être certain que ce serveur est bien qui il prétend être (et non un homme du milieu), une clé est échangée. Cela peut être une clé publique, un  » PreMasterSecret  » ou simplement rien, selon la suite de chiffrement choisie. Le serveur et le client peuvent désormais calculer la clé pour chiffrement symétrique ^{pourquoi PKE?} . Le client indique au serveur quà partir de maintenant, toutes les communications seront chiffrées, et envoie un message chiffré et authentifié au serveur.

Le serveur vérifie que le MAC (utilisé pour lauthentification) est correct et que le message peut être correctement déchiffré. Il renvoie ensuite un message, que le client vérifie comme bien.

La poignée de main est maintenant terminée, et les deux hôtes peuvent communiquer en toute sécurité. Pour plus dinformations, consultez technet.microsoft.com/en-us/library/cc785811 et en.wikipedia .org / wiki / Secure_Sockets_Layer .

Pour fermer la connexion, une « alerte » close_notify est utilisée. Si un attaquant tente de mettre fin à la connexion en terminant la connexion TCP (en injectant un paquet FIN), les deux parties sauront que la connexion a été interrompue de manière incorrecte. Cependant, la connexion ne peut pas être compromise, simplement interrompue.

Quelques détails supplémentaires

Pourquoi pouvez-vous faire confiance à Google.com en faisant confiance à GeoTrust?

Un site Web souhaite communiquer avec vous en toute sécurité. Pour prouver son identité et vous assurer quil ne sagit pas dun attaquant, vous devez disposer de la clé publique du serveur . Cependant, vous pouvez difficilement stocker toutes les clés de tous les sites Web du monde, la base de données serait énorme et les mises à jour devraient être exécutées toutes les heures!

La solution à cela est les autorités de certification, ou CA en abrégé.Lorsque vous avez installé votre système dexploitation ou votre navigateur, une liste dautorités de certification de confiance laccompagnait probablement. Cette liste peut être modifiée à volonté; vous pouvez supprimer les personnes auxquelles vous navez pas confiance, en ajouter dautres ou même créer votre propre autorité de certification (bien que vous soyez le seul à faire confiance à cette autorité de certification, ce nest donc pas très utile pour les sites Web publics). Dans cette liste dautorité de certification, la clé publique de lautorité de certification est également stockée.

Lorsque le serveur de Google vous envoie son certificat, il mentionne également quil est signé par GeoTrust. Si vous faites confiance à GeoTrust, vous pouvez vérifier (en utilisant la clé publique de GeoTrust) que GeoTrust a vraiment signé le certificat du serveur. Pour signer vous-même un certificat, vous avez besoin de la clé privée, qui nest connue que de GeoTrust. De cette façon, un attaquant ne peut pas signer lui-même un certificat et prétend à tort être Google.com. Lorsque le certificat a été modifié ne serait-ce que dun bit, le signe sera incorrect et le client le rejettera.

Donc, si je connais la clé publique, le serveur peut prouver son identité?

Oui. En règle générale, la clé publique crypte et la clé privée décrypte. Cryptez un message avec la clé publique du serveur, envoyez-le, et si le serveur peut répéter le message dorigine, il a simplement prouvé quil a obtenu la clé privée sans révéler la clé.

Cest pourquoi il est si important pour pouvoir faire confiance à la clé publique: nimporte qui peut générer une paire de clés privée / publique, également un attaquant. Vous ne voulez pas finir par utiliser la clé publique dun attaquant!

Si lune des autorités de certification auxquelles vous faites confiance est compromise, un attaquant peut utiliser la clé privée volée pour signer un certificat pour tout site Web de son choix. Lorsque lattaquant peut envoyer un faux certificat à votre client, signé par lui-même avec la clé privée dune autorité de certification en qui vous avez confiance, votre client ne sait pas que la clé publique est une clé falsifiée, signée avec une clé privée volée.

Mais une autorité de certification peut me faire faire confiance à nimporte quel serveur de son choix!

Oui, et cest là que vient la confiance Vous devez faire confiance à lautorité de certification pour quelle ne crée pas de certificats comme elle lentend. Lorsque des organisations comme Microsoft, Apple et Mozilla font confiance à une autorité de certification, celle-ci doit effectuer des audits; une autre organisation les vérifie périodiquement pour sassurer que tout fonctionne toujours conformément aux règles.

Lémission dun certificat est effectuée si, et seulement si, le titulaire peut prouver quil possède le domaine pour lequel le certificat est émis.

Quel est ce MAC pour lauthentification des messages?

Chaque message est signé avec un soi-disant Code dauthentification de message , ou MAC pour faire court. Si nous sommes daccord sur une clé et un chiffrement de hachage, vous pouvez vérifier que mon message vient de moi, et je peux vérifier que votre message vient de vous.

Par exemple avec la clé  » agrafe de batterie de cheval correcte  » et le message  » exemple « , Je peux calculer le MAC  » 58393 « . Lorsque je vous envoie ce message avec le MAC (vous connaissez déjà la clé), vous pouvez effectuer le même calcul et faire correspondre le MAC calculé avec le MAC que jai envoyé.

Un attaquant peut modifier le message mais ne connaît pas la clé. Il ne peut pas calculer le MAC correct et vous saurez que le message n’est pas authentique.

En incluant un numéro de séquence lors du calcul du MAC, vous pouvez éliminer la rediffusion de attaques . SSL fait cela.

Vous avez dit que le client envoie une clé, qui est ensuite utilisée pour la configuration cryptage symétrique. Quest-ce qui empêche un attaquant de lutiliser?

La clé publique du serveur le fait. Puisque nous avons vérifié que la clé publique appartient vraiment au serveur et à personne dautre, nous peut chiffrer la clé à laide de la clé publique. Lorsque le serveur la reçoit, il peut la déchiffrer avec la clé privée. Lorsque quelquun dautre la reçoit, elle ne peut pas la déchiffrer.

Cest aussi pourquoi la taille de la clé est importante: Plus la clé publique et la clé privée sont volumineuses, plus il est difficile de casser la clé que le client envoie au serveur.

Comment pirater SSL

En résumé :

• Essayez si lutilisateur ignore les avertissements de certificat;
• Lapplication peut charger des données depuis un canal non chiffré (par exemple HTTP), qui peut être falsifié;
• Une page de connexion non protégée qui se soumet à HTTPS peut être modifiée afin quelle se soumette à HTTP;
• Les applications non corrigées peuvent être vulnérable aux exploits comme BEAST et CRIME;
• Recourir à dautres méthodes suc h comme une attaque physique;
• Exploitez canaux secondaires comme la longueur du message et lheure de utilisé pour former le message;
• Attendez les attaques quantiques .

Voir aussi: Un schéma avec de nombreux vecteurs dattaque contre SSL par Ivan Ristic ^(png)

En détail:

Il ny a pas de simple et direct chemin; SSL est sécurisé lorsquil est fait correctement. Un attaquant peut cependant essayer si lutilisateur ignore les avertissements de certificat , ce qui briserait la sécurité instantanément. Lorsquun utilisateur fait cela, lattaquant na pas besoin dune clé privée dune autorité de certification pour forger un certificat, il doit simplement envoyer son propre certificat.

Une autre façon serait de faire une faille dans le (côté serveur ou côté client). Un exemple simple est dans les sites Web: si lune des ressources utilisées par le site Web (comme une image ou un script) est chargée via HTTP, la confidentialité ne peut plus être garantie. Même si les navigateurs nenvoyez pas len-tête HTTP Referer lors de la demande de ressources non sécurisées à partir dune page sécurisée ( source ), il est toujours possible pour quelquun qui écoute le trafic de deviner où vous « visite de; par exemple, sils savent que les images X, Y et Z sont utilisées sur une page, ils peuvent deviner que vous visitez cette page quand ils voient que votre navigateur demande ces trois images à la fois. De plus, lors du chargement de Javascript, la page entière peut être compromise. Un attaquant peut exécuter nimporte quel script sur la page, en modifiant par exemple à qui va la transaction bancaire.

Lorsque cela se produit (une ressource étant chargée via HTTP), le navigateur donne un avertissement de contenu mixte: Chrome , Firefox , Internet Explorer 9

Une autre astuce pour HTTP est lorsque la page de connexion nest pas sécurisée et quelle se soumet à une page https.  » Génial,  » le développeur a probablement pensé,  » maintenant jenregistre la charge du serveur et le le mot de passe est toujours envoyé chiffré!  » Le problème est sslstrip , un outil qui modifie la page de connexion non sécurisée afin quelle soumet quelque part afin que lattaquant puisse le lire.

Il y a également eu diverses attaques ces dernières années, comme la vulnérabilité de renégociation TLS , sslsniff , BEAST et très récemment, CRIME . Cependant, tous les navigateurs courants sont protégés contre toutes ces attaques, donc ces vulnérabilités ne présentent aucun risque si vous utilisez un navigateur à jour.

Dernier point mais non le moindre, vous pouvez recourir à dautres méthodes pour obtenir les informations que SSL vous refuse dobtenir. Si vous pouvez déjà voir et altérer la connexion de lutilisateur, il nest peut-être pas si difficile de remplacer lun de ses téléchargements .exe par un enregistreur de frappe, ou simplement dattaquer physiquement cette personne. La cryptographie peut être plutôt sécurisée, mais les humains et lerreur humaine reste un facteur faible. Selon cet article de Verizon , 10% des violations de données impliquaient des attaques physiques (voir page 3), donc  » Cest certainement quelque chose à garder à lesprit.

Commentaires

• Je serais intéressé par un peu plus dexplications pour  » une clé est échangée  » contre la clé symétrique. Comment se fait-il quune personne avec un renifleur de paquets ne puisse pas accéder.
• @Yehosef Bonne question! Jai oublié de lexpliquer dans ma réponse. En regardant autour de vous, il savère quil y a en fait une question dédiée à ceci: security.stackexchange.com/q/6290/10863
• @ Iwazaru Tous les CA font cela depuis le premier jour. Le but dun certificat est de fournir la clé publique pour un domaine donné, et le point de le signer pour prouver quil sagit vraiment de la bonne clé pour le domaine. Laissez ‘ s Encrypt fait exactement ce quil devrait faire: vérifier que vous êtes propriétaire du domaine, et signer votre certificat (avec votre clé) si vous pouvez le prouver. Désormais, tous ceux qui font confiance à Let ‘ s Encrypt, qui est pratiquement tous les navigateurs, feront confiance à ce certificat.
• Euh, non. TLS est en effet juste implémenté sur TCP.
• Nous avons trouvé ce processus graphique de prise de contact SSL , très clair.

Étant donné que le concept général de SSL a déjà été traité dans dautres questions (par exemple, celui-ci et celui-là ), cette fois jirai pour plus de détails. Les détails sont importants. Cette réponse sera quelque peu verbeuse.

Historique

SSL est un protocole avec une longue histoire et plusieurs versions.Les premiers prototypes sont venus de Netscape lorsquils développaient les premières versions de leur navigateur phare, Netscape Navigator (ce navigateur a tué Mosaic dans les premiers temps de la guerre des navigateurs, qui fait toujours rage, bien quavec de nouveaux concurrents). La version 1 na jamais été rendue publique, nous ne savons donc pas à quoi elle ressemblait. La version 2 de SSL est décrite dans un brouillon qui peut être lu ici ; il présente un certain nombre de faiblesses, dont certaines sont plutôt graves, il est donc obsolète et les nouvelles implémentations SSL / TLS ne le prennent pas en charge (alors que les anciennes sont désactivées par défaut). Je ne parlerai plus de SSL version 2, sauf à titre de référence occasionnelle.

SSL version 3 (que jappellerai « SSLv3 ») était un protocole amélioré qui fonctionne encore aujourdhui et qui est largement supporté. Bien que toujours une propriété de Netscape Communications (ou de celui qui en possède de nos jours), le protocole a été publié en tant que « RFC historique » ( RFC 6101 ). Pendant ce temps, le protocole a été normalisé, avec un nouveau nom afin déviter les problèmes juridiques; le nouveau nom est TLS .

Trois versions de TLS ont été produites jusquà présent, chacune avec son RFC dédié: TLS 1.0 , TLS 1.1 et TLS 1.2 . Ils sont en interne très similaires les uns avec les autres, et avec SSLv3, au point quune implémentation peut facilement prendre en charge SSLv3 et les trois versions TLS avec au moins 95% du code commun. Pourtant, en interne, toutes les versions sont désignées par un numéro de version au format major.minor ; SSLv3 est alors 3.0, tandis que les versions TLS sont respectivement 3.1, 3.2 et 3.3. Ainsi, il nest pas étonnant que TLS 1.0 soit parfois appelé SSL 3.1 (et ce nest pas incorrect non plus). SSL 3.0 et TLS 1.0 ne diffèrent que par quelques détails infimes. TLS 1.1 et 1.2 ne sont pas encore largement supportés, bien quil y ait une impulsion pour cela, en raison de possibles faiblesses (voir ci-dessous, pour « lattaque BEAST »). SSLv3 et TLS 1.0 sont pris en charge « partout » (même IE 6.0 les connaît).

Contexte

SSL vise à fournir un tunnel bidirectionnel sécurisé pour les données arbitraires. Considérez TCP , le protocole bien connu pour lenvoi de données sur Internet. TCP fonctionne sur les « paquets » IP et fournit un tunnel bidirectionnel pour les octets; il fonctionne pour chaque valeur doctet et les envoie dans deux flux qui peuvent fonctionner simultanément. TCP gère le travail acharné de fractionner les données en paquets, de les reconnaître, de les réassembler dans leur bon ordre, tout en supprimant les doublons et en réémettant les paquets perdus. Du point de vue de lapplication qui utilise TCP, il ny a que deux flux, et les paquets sont invisibles; en particulier, les flux ne sont pas découpés en « messages » (il appartient à lapplication de prendre ses propres règles dencodage si elle souhaite avoir des messages, et cest précisément ce que HTTP ).

TCP est fiable en présence d « accidents », cest-à-dire derreurs de transmission dues à un matériel défectueux, à une congestion du réseau, à des personnes avec des smartphones qui sortent de la portée dune station de base donnée , et dautres événements non malveillants. Cependant, un individu mal intentionné (l «attaquant») ayant un certain accès au support de transport pourrait lire toutes les données transmises et / ou les modifier intentionnellement, et TCP ne protège pas contre cela. Par conséquent SSL.

SSL suppose quil fonctionne sur un protocole de type TCP, qui fournit un flux fiable; SSL nimplémente pas la réémission des paquets perdus et des choses comme ça. Lattaquant est censé être en mesure de perturber complètement la communication de manière inévitable (par exemple, il peut couper les câbles) donc le travail de SSL est de:

• détecter les altérations (lattaquant ne doit pas pouvoir modifier les données silencieusement );
• assurer la confidentialité des données (le lattaquant ne doit pas prendre connaissance des données échangées).

SSL remplit ces objectifs dans une large mesure (mais pas absolue).

Records

SSL est en couches et la couche inférieure est le protocole denregistrement . Toutes les données envoyées dans un tunnel SSL sont divisées en enregistrements . Sur le fil (le socket TCP sous-jacent ou le support de type TCP), un enregistrement ressemble à ceci:

HH V1:V2 L1:L2 data

où:

• HH est un octet unique qui indique le type de données dans lenregistrement.Quatre types sont définis: change_cipher_spec (20), alert (21), handshake (22) et application_data ( 23).
• V1: V2 est la version du protocole, sur deux octets. Pour toutes les versions actuellement définies, V1 a la valeur 0x03, tandis que V2 a la valeur 0x00 pour SSLv3, 0x01 pour TLS 1.0, 0x02 pour TLS 1.1 et 0x03 pour TLS 1.2.
• L1: L2 est la longueur de data, en octets (la convention big-endian est utilisé: la longueur est de 256 * L1 + L2). La longueur totale de data ne peut pas dépasser 18432 octets, mais en pratique, elle ne peut même pas atteindre cette valeur.

Un enregistrement a donc cinq- en-tête doctet, suivi dau plus 18 ko de données. Le data est lendroit où le chiffrement symétrique et les contrôles dintégrité sont appliqués. Lorsquun enregistrement est émis, lexpéditeur et le destinataire sont censés se mettre daccord sur les algorithmes cryptographiques actuellement appliqués et avec quelles clés; cet accord est obtenu via le protocole de prise de contact, décrit dans la section suivante. La compression, le cas échéant, est également appliquée à ce stade.

Dans tous les détails, la construction dun enregistrement fonctionne comme ceci:

• Au départ, il y a quelques octets à transférer ; ce sont des données dapplication ou un autre type doctets. Cette charge utile comprend au plus 16 384 octets, mais peut-être moins (une charge utile de longueur 0 est légale, mais il savère quInternet Explorer 6.0 naime pas cela du tout ) .
• La charge utile est ensuite compressée avec nimporte quel algorithme de compression actuellement convenu. La compression est avec état et peut donc dépendre du contenu des enregistrements précédents. En pratique, la compression est soit « nulle » (pas de compression du tout), soit « Deflate » ( RFC 3749 ), cette dernière étant actuellement courtoisement mais fermement montrée la sortie porte dans le contexte Web, en raison de la récente attaque CRIME . La compression vise à raccourcir les données, mais elle doit nécessairement les élargir légèrement dans certaines situations défavorables (en raison du principe du casier ). SSL permet une expansion dau plus 1024 octets. Bien sûr, la compression nulle ne se développe jamais (mais ne raccourcit jamais non plus); Deflate augmentera dau plus 10 octets si limplémentation est bonne.
• La charge utile compressée est alors protégée contre les altérations et chiffrée. Si les algorithmes de chiffrement et dintégrité actuels sont « nuls », alors cette étape est une non-opération. Sinon, un MAC est ajouté, puis un peu de remplissage (en fonction de lalgorithme de chiffrement) et le résultat est chiffré. Ces étapes induisent à nouveau une certaine expansion, que la norme SSL limite à 1024 octets supplémentaires (combinée à lexpansion maximale de létape de compression, cela nous amène aux 18432 octets, auxquels nous devons ajouter len-tête de 5 octets).

Le MAC est, généralement, HMAC avec lune des fonctions de hachage habituelles (principalement MD5, SHA-1 ou SHA-256) (avec SSLv3, ce nest pas le « vrai » HMAC mais quelque chose de très similaire et, à notre connaissance, aussi sûr que HMAC). Le chiffrement utilisera soit un chiffrement par bloc en mode CBC , soit le chiffrement de flux RC4 . Notez quen théorie, dautres types de modes ou dalgorithmes pourraient être employés, par exemple lun de ces modes astucieux qui combinent le chiffrement et les contrôles dintégrité; il existe même des RFC pour cela . Dans la pratique, cependant, les implémentations déployées ne sont pas encore au courant de celles-ci, cest pourquoi elles font HMAC et CBC. Fondamentalement, le MAC est dabord calculé et ajouté aux données, et le résultat est chiffré. Cest MAC-then-encrypt et ce nest en fait pas une très bonne idée . Le MAC est calculé sur la concaténation de la charge utile (compressée) et dun numéro de séquence, de sorte quun attaquant industrieux ne peut pas échanger des enregistrements.

Handshake

La handshake est un protocole qui est joué dans le protocole denregistrement. Son objectif est détablir les algorithmes et les clés à utiliser pour les enregistrements. Il se compose de messages . Chaque message de prise de contact commence par un en-tête de quatre octets, un octet qui décrit le type de message, puis trois octets pour la longueur du message (convention big-endian). Les messages de prise de contact successifs sont ensuite envoyés avec des enregistrements marqués du type « handshake » (le premier octet de len-tête de chaque enregistrement a la valeur 22).

Notez les couches: les messages de prise de contact, complétés par quatre- en-tête doctets, sont ensuite envoyés sous forme denregistrements, et chaque enregistrement également a son propre en-tête. En outre, plusieurs messages de prise de contact peuvent être envoyés dans le même enregistrement, et un message de prise de contact donné peut être divisé en plusieurs enregistrements.Du point de vue du module qui construit les messages de prise de contact, les « enregistrements » ne sont quun flux sur lequel des octets peuvent être envoyés; il est inconscient de la division réelle de ce flux en enregistrements.

Prise de contact complète

Au départ, le client et le serveur « sentendent sur » un cryptage nul sans MAC et aucune compression. Cela signifie que lenregistrement quils enverront en premier sera envoyé en texte clair et non protégé.

Le premier message dune poignée de main est un ClientHello. Cest le message par lequel le client déclare son intention de faire du SSL. Notez que «client» est un rôle symbolique; cela signifie « le parti qui parle en premier ». Il se trouve que dans le contexte HTTPS, qui est HTTP-within-SSL-within-TCP, les trois couches ont une notion de «client» et de «serveur», et elles sont toutes daccord (le client TCP est aussi le client SSL et le client HTTP), mais cest une sorte de coïncidence.

Le message ClientHello contient:

• le protocole maximum version que le client souhaite prendre en charge;
• le « client aléatoire » (32 octets, dont 28 sont censés être générés avec un générateur de nombres cryptographiquement fort);
• le  » ID de session « (dans le cas où le client souhaite reprendre une session dans une poignée de main abrégée, voir ci-dessous);
• la liste des » suites de chiffrement « que le client connaît, classées par préférence client;
• la liste des algorithmes de compression connus du client, classés par préférence client;
• quelques extensions facultatives.

A suite de chiffrement est un identifiant symbolique de 16 bits pour un ensemble de cryptographes c algorithmes. Par exemple, la suite de chiffrement TLS_RSA_WITH_AES_128_CBC_SHA a la valeur 0x002F et signifie que « les enregistrements utilisent le chiffrement HMAC / SHA-1 et AES avec une clé de 128 bits, et léchange de clé se fait par chiffrement une clé aléatoire avec la « clé publique RSA du serveur ».

Le serveur répond à ClientHello avec un ServerHello qui contient:

• la version du protocole que le client et le serveur utiliseront ;
• le « serveur aléatoire » (32 octets, avec 28 random bytes);
• lID de session pour cette connexion;
• la suite de chiffrement qui sera utilisée;
• lalgorithme de compression qui sera utilisé;
• éventuellement, certaines extensions.

La prise de contact complète ressemble à ceci:

 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data 

(Ce schéma a été copié sans vergogne depuis la RFC.)

Nous voyons les ClientHello et ServerHello. Ensuite, le serveur envoie quelques autres messages, qui dépendent de la suite de chiffrement et dun autre paramètre rs:

• Certificat: le certificat du serveur, qui contient sa clé publique. Plus dinformations ci-dessous. Ce message est presque toujours envoyé, sauf si la suite de chiffrement impose une prise de contact sans certificat.
• ServerKeyExchange: quelques valeurs supplémentaires pour léchange de clés, si le contenu du certificat nest pas suffisant. En particulier, les suites de chiffrement « DHE » utilisent un échange de clés éphémère Diffie-Hellman , qui nécessite ce message.
• CertificateRequest: un message demandant que le client également sidentifie avec un certificat qui lui est propre. Ce message contient la liste des noms dancres de confiance (également appelés « certificats racine ») que le serveur utilisera pour valider le certificat client.
• ServerHelloDone: un message marqueur (de longueur zéro) qui indique que le serveur est terminé et que le client doit maintenant parler.

Le client doit alors répondre avec:

• Certificat: le certificat client, si le serveur en a demandé un. Il existe des variations subtiles entre les versions (avec SSLv3, le client doit omettre ce message sil na pas de certificat; avec TLS 1.0+, dans la même situation, il doit envoyer un Certificate message avec une liste vide de certificats).
• ClientKeyExchange: la partie client de léchange de clés réel (par exemple, une valeur aléatoire chiffrée avec la clé RSA du serveur).
• CertificateVerify: a signature numérique calculée par le client sur tous les messages de prise de contact précédents. Ce message est envoyé lorsque le serveur a demandé un certificat client et que le client sest conformé. Cest ainsi que le client prouve au serveur quil « possède » réellement la clé publique qui est encodée dans le certificat quil a envoyé.

Ensuite, le client envoie un ChangeCipherSpec , qui nest pas un message de prise de contact: il a son propre type denregistrement, il sera donc envoyé dans un enregistrement qui lui est propre.Son contenu est purement symbolique (un seul octet de valeur 1). Ce message marque le moment où le client passe à la suite de chiffrement et aux clés nouvellement négociées. Les enregistrements suivants du client seront ensuite cryptés.

Le message Terminé est une somme de contrôle cryptographique calculée sur tous les messages de prise de contact précédents (du client et du serveur). Puisquil est émis après le ChangeCipherSpec, il est également couvert par le contrôle dintégrité et le chiffrement. Lorsque le serveur reçoit ce message et vérifie son contenu, il obtient une preuve quil a bien parlé au même client depuis le début. Ce message protège la poignée de main des altérations (lattaquant ne peut pas modifier les messages de la poignée de main et toujours obtenir le message Finished).

Le serveur répond finalement avec son propre ChangeCipherSpec puis Finished. À ce stade, létablissement de liaison est terminé et le client et le serveur peuvent échanger des données dapplication (dans des enregistrements chiffrés marqués comme tels).

À retenir: le client suggère mais le serveur choisit . La suite de chiffrement est entre les mains du serveur. Les serveurs courtois sont censés suivre les préférences du client (si possible), mais ils peuvent faire autrement et certains le font réellement (par exemple dans le cadre de la protection contre BEAST).

Prise de contact abrégée

Lors de la prise de contact complète, le serveur envoie un « ID de session » (cest-à-dire un ensemble de 32 octets maximum) au client. Plus tard, le client peut revenir et envoyer le même identifiant de session dans le cadre de son ClientHello. Cela signifie que le client se souvient toujours de la suite de chiffrement et des clés de la négociation précédente et souhaite réutiliser ces paramètres. Si le serveur se souvient également de la suite de chiffrement et des clés, il copie cet ID de session spécifique dans son ServerHello, puis suit le poignée de main abrégée :

 Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data 

La poignée de main abrégée est plus courte: moins de messages, non activité de cryptographie asymétrique et, surtout, latence réduite . Les navigateurs Web et les serveurs le font souvent. Un navigateur Web typique ouvrira une connexion SSL avec une prise de contact complète, puis effectuera des prises de contact abrégées pour toutes les autres connexions au même serveur: les autres connexions quil ouvre en parallèle, ainsi que les connexions suivantes au même serveur. En effet, les serveurs Web typiques fermeront les connexions après 15 secondes dinactivité, mais ils se souviendront des sessions (la suite de chiffrement et les clés) pendant beaucoup plus longtemps (éventuellement pendant des heures voire des jours).

Échange de clés

Il existe plusieurs algorithmes déchange de clés que SSL peut utiliser. Ceci est spécifié par la suite de chiffrement; chaque algorithme déchange de clé fonctionne avec certains types de clé publique de serveur. Les algorithmes déchange de clés les plus courants sont:

• RSA: la clé du serveur est de type RSA. Le client génère une valeur aléatoire (le  » secret pré-maître « de 48 octets, dont 46 sont aléatoires) et le crypte avec la clé publique du serveur. Il ny a pas de ServerKeyExchange.
• DHE_RSA: la clé du serveur est de type RSA, mais utilisée uniquement pour signature. Léchange de clé proprement dit utilise Diffie-Hellman. Le serveur envoie un message ServerKeyExchange contenant les paramètres DH (module, générateur) et une clé publique DH nouvellement générée; de plus, le serveur signe ce message. Le client répondra par un message ClientKeyExchange qui contient également une clé publique DH nouvellement générée. Le DH renvoie le « secret pré-maître « .
• DHE_DSS: comme DHE_RSA, mais le serveur a une clé DSS ( » DSS « est également connu comme « DSA » ). DSS est un algorithme de signature uniquement.

Les algorithmes déchange de clés moins couramment utilisés incluent:

• DH: la clé du serveur est de type Diffie-Hellman (on parle dun certificat qui contient un Touche DH). Ceci était autrefois « populaire » sur le plan administratif (le gouvernement fédéral américain en a mandaté lutilisation) lorsque le brevet RSA était encore actif (cétait au cours du siècle précédent). Malgré la pression bureaucratique, il na jamais été aussi largement déployé que RSA.
• DH_anon: comme les suites DHE, mais sans la signature du serveur. Il sagit dune suite de chiffrement sans certificat. Par construction, il est vulnérable aux attaques Man-in-the-Middle , donc très rarement activé du tout.
• PSK: suites de chiffrement à clé pré-partagée . Léchange de clé symétrique uniquement, basé sur un secret partagé préétabli.
• SRP: lapplication du protocole SRP qui est un Protocole déchange de clés authentifié par mot de passe . Le client et le serveur sauthentifient mutuellement en ce qui concerne un secret partagé, qui peut être un mot de passe à faible entropie (alors que PSK nécessite un secret partagé à haute entropie). Très chouette. Pas encore largement pris en charge.
• Une clé RSA éphémère: comme DHE mais avec une paire de clés RSA nouvellement générée. La génération de clés RSA étant coûteuse, ce nest pas une option populaire et na été spécifiée que dans le cadre des suites de chiffrement «dexportation» qui respectaient les réglementations dexportation américaines antérieures à 2000 sur la cryptographie (cest-à-dire les clés RSA dau plus 512 bits). Personne ne le fait de nos jours.
• Variantes des algorithmes DH* avec courbes elliptiques . Très à la mode. Devrait devenir courant à lavenir.

Certificats et authentification

Les certificats numériques sont des récipients pour les clés asymétriques. Ils sont destinés à résoudre la distribution des clés. A savoir, le client souhaite utiliser la clé publique du serveur. Lattaquant tentera de faire en sorte que le client utilise la clé publique de l attaquant . Le client doit donc avoir un moyen de sassurer quil utilise la bonne clé.

SSL est censé utiliser X.509 . Cest une norme pour les certificats. Chaque certificat est signé par une autorité de certification . Lidée est que le client connaît intrinsèquement les clés publiques dune poignée de CA (ce sont les «ancres de confiance» ou «certificats racine»). Avec ces clés, le client peut vérifier la signature calculée par une CA sur un certificat qui a été délivré au serveur. Ce processus peut être étendu de manière récursive: une CA peut émettre un certificat pour une autre CA (cest-à-dire signer la structure de certificat qui contient le nom et la clé de lautre CA). Une chaîne de certificats commençant par une autorité de certification racine et se terminant par le certificat du serveur, avec des certificats de lautorité de certification intermédiaires entre les deux, chaque certificat étant signé par rapport à la clé publique encodée dans le certificat précédent, est appelée, sans imagination, un chaîne de certificats .

Le client est donc censé faire ce qui suit:

• Obtenir une chaîne de certificats se terminant par le certificat du serveur. Le message Certificate du serveur est censé contenir, précisément, une telle chaîne.
• Valider la chaîne, cest-à-dire vérifier tous les signatures et noms et les différents bits X.509. De plus, le client doit vérifier le statut de révocation de tous les certificats de la chaîne, ce qui est complexe et lourd (les navigateurs Web le font maintenant, plus ou moins, mais est un développement récent).
• Vérifiez que le nom du serveur prévu est bien écrit dans le certificat du serveur. Le client ne souhaitant pas seulement utiliser une clé publique validée, il souhaite également utiliser la clé publique dun serveur spécifique . Voir RFC 2818 pour plus de détails sur la manière de procéder dans un contexte HTTPS .

Le modèle de certification avec des certificats X.509 a souvent été critiqué, pas vraiment pour des raisons techniques, mais plutôt pour des raisons politico-économiques. Il concentre le pouvoir de validation entre les mains de quelques acteurs , qui ne sont pas nécessairement bien intentionnés, ou du moins pas toujours compétents . De temps en temps, des propositions pour d’autres systèmes sont publiées (par exemple, Convergence ou

Après la longue présentation de SSL dans la réponse précédente , allons-y avec les choses amusantes, à savoir:

Attaques contre SSL

Il y a eu de nombreuses attaques contre SSL, certaines reposant sur des erreurs de mise en œuvre, dautres sur de véritables faiblesses de protocole.

Il faut se rappeler que si SSL est lun des protocoles les plus attaqués (puisquil est de très haut niveau: une application réussie vers SSL semble très agréable dans le résumé dun article de recherche), SSL est également l’un des protocoles les plus réparés .Il doit être considéré comme robuste précisément parce que tous les moyens connus dattaquer les protocoles de transport ont été essayés sur SSL, et SSL a été corrigé le cas échéant.

Restauration de version

Au début de SSLv3, SSLv2 était encore largement utilisé, et par conséquent, les clients envoyaient couramment des messages, qui indiquaient simplement que SSLv3 était également pris en charge; le serveur prendrait alors lindication et répondrait en dialecte SSLv3 + (voir lannexe E de la RFC 2246 pour plus de détails). Étant donné que SSLv2 présentait des faiblesses, il était dans le meilleur intérêt de lattaquant de faire en sorte quun client et un serveur, tous deux connaissant SSLv3, se parlent néanmoins en utilisant SSLv2. Cest ce quon appelle une attaque de restauration de version . Le concept sétend également aux versions ultérieures.

Des avertissements ont été ajoutés pour détecter les tentatives de restauration. Pour les restaurations de retour à SSLv2, un client qui connaît SSLv3 + doit utiliser un remplissage spécial pour létape de chiffrement RSA (SSLv2 pris en charge uniquement léchange de clés RSA): dans PKCS # 1 , les données à chiffrer sont censées être remplies dun certain nombre doctets aléatoires; un client compatible SSLv3 est alors supposé définir chacun des huit derniers octets de remplissage à la valeur fixe 0x03. Le serveur vérifie ensuite ces octets; si les huit 0x03 sont trouvés, alors une restauration est très probablement tentée, et le serveur rejette la tentative (un client SSLv2 uniquement a une probabilité seulement 255 ^-8 dutiliser ces octets de remplissage par simple manque de chance, donc les faux positifs se produisent à un taux négligeable).

Pour les restaurations vers une ancienne version de SSL / TLS, mais pas plus ancienne que SSLv3, un autre kludge a été ajouté: dans le secret pré-maître sur 48 octets que le client crypte avec la clé RSA du serveur, les deux premiers octets ne sont pas aléatoires, mais doivent être égaux à la « version de protocole maximale prise en charge » que le client a écrite en premier dans son ClientHello. Malheureusement, certains clients se sont trompés, et ce kludge ne fonctionne quavec un échange de clés basé sur RSA, donc la protection contre la restauration y est très limitée. Heureusement, SSLv3 + dispose dune autre protection beaucoup plus puissante contre rollbacks, cest-à-dire que les messages de prise de contact sont hachés ensemble lorsque les messages Finished sont générés. Ce pro tecte contre les annulations à moins que l «ancienne version» ne soit si complètement faible que lattaquant pourrait totalement briser tout le chiffrement avant la fin de la poignée de main elle-même. Cela ne sest pas encore produit (SSLv3 est encore raisonnablement robuste).

Weak Cipher Suites

Certaines des suites de chiffrement standard sont intentionnellement faibles dune certaine manière. Il existe:

• des suites de chiffrement sans aucun chiffrement, uniquement un contrôle dintégrité, par exemple TLS_RSA_WITH_NULL_SHA;
• certaines suites de chiffrement avec chiffrement à 40 bits, telles que TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (suites de chiffrement destinées à les règles dexportation américaines strictes du siècle dernier – ces réglementations ont été pour la plupart levées à la fin de lère Bill Clinton);
• certaines suites de chiffrement avec un chiffrement à 56 bits, comme TLS_RSA_WITH_DES_CBC_SHA. Le DES 56 bits est cassable avec la technologie existante , mais cest encore un peu difficile pour un amateur (même un étudiant ennuyé ayant accès à quelques centaines de machines universitaires ), jai donc tendance à qualifier le DES 56 bits de « force moyenne ».

Cela ouvre la voie à une variante dattaques de restauration de version, dans laquelle lattaquant force le client et le serveur à se mettre daccord sur une suite de chiffrement faible, lidée étant que lattaquant modifie la liste des suites de chiffrement annoncées par le client. Ceci est réalisable pour lattaquant si la suite de chiffrement sélectionnée est si faible quil peut la casser afin de recalculer un Finished message. En fait, le MAC utilisé dans SSLv3 + (même lorsquil est basé sur MD5) est suffisamment robuste pour éviter cela. Donc, pas de souci réel ici. De plus, mon avis est que toute vraie faiblesse ici cest quand un client ou un serveur accepte dutiliser une suite de chiffrement faible.

Par défaut, les navigateurs Web modernes ne permettent pas lutilisation de telles suites de chiffrement faibles.

Vol de clé privée

Si une connexion SSL utilise léchange de clé RSA, et un attaquant conserve une copie des enregistrements, puis plus tard (éventuellement des mois après, éventuellement en inspectant toutes les sauvegardes sur des disques durs ou bandes jetés) obtient une copie de la clé privée, puis il peut démêler la poignée de main et décrypter les données.

Perfect Forward Secrecy consiste à contrer ce « plus tard ». Vous lobtenez en utilisant les suites de chiffrement DHE. Avec une suite de chiffrement DHE, la clé privée réelle qui pourrait être utilisée pour démêler la poignée de main est la clé éphémère Diffie-Hellman, et non la clé privée RSA (ou DSS) du serveur.Étant éphémère, il nexistait quen RAM, et na jamais été écrit sur le disque dur; en tant que tel, il devrait être beaucoup plus résistant aux vols ultérieurs.

La leçon est donc la suivante: en règle générale, essayez dutiliser une suite de chiffrement DHE si possible. Vous devriez toujours faire attention à vos sauvegardes et ne pas laisser votre clé privée fuir, mais, au moins, les suites DHE rendent une telle fuite un peu moins problématique, surtout si cela se produit après la fin de la durée de vie de la clé (cest-à-dire que le certificat correspondant nest pas plus valide).

Problèmes de certificat

Toute lactivité de certificat est une point sensible dans SSL.

Techniquement, SSL est assez indépendant de X.509. Les chaînes de certificats sont échangées sous forme de blobs opaques. À un moment donné, le client doit utiliser la clé publique du serveur, mais le client est libre de «connaître» cette clé comme bon lui semble. Dans certains scénarios spécifiques où SSL peut être utilisé, le client connaît déjà le serveur « s publique clé (codée en dur dans le code) et ignore simplement le certificat envoyé par le serveur. Néanmoins, dans le cas courant du HTTPS, le client effectue la validation de la chaîne de certificats du serveur comme décrit dans X.509 ( lisez-le au détriment de votre santé mentale; vous avez été averti).

Cela donne un certain nombre de vecteurs dattaque, par exemple:

• La validation implique de vérifier que les certificats sont toujours valides à la date actuelle. Comment la machine cliente connaît-elle la date actuelle? Avec son horloge interne, et éventuellement en parlant avec des serveurs NTP (en un moyen assez non protégé!). Le client pourrait être éteint de plusieurs minutes, heures, jours, voire années (je lai vu), et, dans une certaine mesure, un attaquant puissant pourrait le forcer en jouant avec les messages NTP. Cela permettrait lattaquant dutiliser des certificats obsolètes qui ont été révoqués il y a des années. Remarquez un fait amusant: les SSL «client random» et «server random» doivent contenir 28 octets aléatoires et la date et lheure locales (sur 4 octets). Cette inclusion du temps était censé faire partie dune solution de contournement contre les attaques basées sur le temps. Je nai connaissance daucune implémentation qui le vérifie vraiment.

• Jusquen 2003 environ, limplémentation de la validation de certificat dans Internet Explorer / Windows ne traitait pas lextension « Basic Constraints » correctement. Leffet net était que nimporte qui avec un certificat de 100 € pouvait agir en tant quautorité de certification et émettre des « certificats » avec un nom et des clés choisis arbitrairement.

• X .509 inclut une fonction de confinement des dommages appelée révocation : il sagit de publier une liste de certificats bannis, qui ont lair bien, cryptographiquement parlant, mais ne doivent pas faire confiance (par exemple, leur clé privée a été volée, ou ils contiennent un nom erroné). La révocation ne fonctionne que dans la mesure où les parties impliquées (cest-à-dire les navigateurs) acceptent de télécharger des listes de révocation gigantesques (qui peuvent durer plusieurs mégaoctets!) Ou de contacter les serveurs OCSP . Les navigateurs modernes le font maintenant, mais avec un peu de réticence, et beaucoup accepteront quand même de se connecter sils ne pouvaient pas obtenir les informations sur létat de la révocation en temps opportun (car lutilisateur humain nest pas patient). La situation générale saméliore au fil des ans, mais assez lentement.

• Certaines autorités de certification racine ont commis des erreurs dans le passé (par exemple, Comodo et DigiNotar). Cela a abouti à lémission de faux certificats (le nom est www.microsoft.com mais la clé privée nest pas du tout entre les mains de Microsoft …). Ces erreurs ont été découvertes et les certificats révoqués, mais cela soulève encore des questions inconfortables (par exemple, y a-t-il dautres autorités de certification qui ont eu de tels problèmes mais ne les ont pas révélées ou, pire encore, ne les ont jamais remarquées?).

X.509 est un assemblage très complexe dalgorithmes, de technologies, de spécifications et de comités, et il est très difficile de faire les choses correctement. Essayer de décoder des certificats X.509 « à la main » dans un langage de programmation non protégé comme C est un moyen facile dobtenir des débordements de tampon.

Attaques de Bleichenbacher

Daniel Bleichenbacher a trouvé en 1998 une belle attaque contre RSA. Lorsque vous cryptez une donnée avec RSA (comme cela se produit pour le message ClientKeyExchange en SSL), les données à chiffrer doivent être complétées dans lordre pour créer une séquence doctets de la même longueur que le module RSA. Le remplissage se compose principalement doctets aléatoires, mais il y a un peu de structure (notamment, les deux premiers octets après le remplissage doivent être 0x00 0x02).

Lors du décryptage (sur le serveur, alors), le remplissage doit être trouvé et supprimé. Il se trouve quà ce moment-là, lorsque le serveur a déchiffré mais obtenu un remplissage non valide (les octets 0x00 0x02 nétaient pas là), il la signalé avec un message dalerte (selon la spécification SSL), alors quun remplissage valide a entraîné le serveur utilisant la valeur apparemment déchiffrée et poursuivant la poignée de main.

Ce genre de chose est connu sous le nom d oracle de remplissage . Il permet à un attaquant denvoyer une séquence arbitraire doctets comme sil sagissait dun secret pré-maître chiffré, et de savoir si le déchiffrement de cette séquence donnerait un remplissage valide ou non. Cest « une simple information de 1 bit, mais il suffit de récupérer la clé privée avec quelques millions de requêtes (avec des chaînes » cryptées « astucieusement conçues).

Solution de contournement: lorsque le décryptage aboutit à une invalidité padding, le serveur continue dutiliser un secret pré-maître aléatoire. La prise de contact échouera ensuite, avec les messages Finished. Toutes les implémentations actuelles de SSL le font.

LOracle de remplissage contre-attaque

Un autre domaine où un oracle de remplissage a été trouvé se trouve dans le Considérez le chiffrement CBC et HMAC. Les données à chiffrer sont dabord MAC, puis le résultat est chiffré. Avec le chiffrement CBC, les données à chiffrer doivent avoir une longueur qui est un multiple de la taille du bloc (8 octets pour 3DES, 16 octets pour AES). Donc, un certain remplissage est appliqué, avec une certaine structure.

À ce moment-là (lattaque a été découverte par Vaudenay en 2002), quand une implémentation SSL traitait une réception d, il a renvoyé des messages dalerte distincts pour ces deux conditions:

• Lors du décryptage, aucune structure de remplissage valide na été trouvée.
• Lors du décryptage, un remplissage valide a été trouvé, mais le MAC a été vérifié et il ne correspondait pas.

Ceci est un oracle de remplissage, et qui peut être utilisé pour récupérer des données chiffrées. Cela nécessite un attaquant actif, mais ce nest pas si difficile. Vaudenay la implémenté, et il a été étendu au cas où une implémentation SSL modifiée a renvoyé le même message dalerte dans les deux cas, mais a mis plus de temps à revenir dans le second cas, en raison du temps nécessaire pour recalculer le MAC (une belle démonstration de une attaque de synchronisation ).

Comme les gens napprennent jamais, limplémentation Microsoft de SSL utilisée dans ASP.NET était toujours non corrigé en 2010 (huit ans plus tard!) lorsque Rizzo et Duong ont réimplémenté lattaque Vaudenay et construit une démonstration qui a récupéré les cookies HTTP.

Voir cette page pour quelques pointeurs. Il faut noter que si SSL avait utilisé encrypt-then-MAC , de tels problèmes auraient été évités (les enregistrements défectueux auraient été rejetés au niveau MAC, avant même en considérant le déchiffrement).

BEAST

Lattaque BEAST est à nouveau de Duong et Rizzo, et, encore une fois, cest un remake dune attaque plus ancienne (de Philip Rogaway en 2002). Pour vous faire une idée, pensez à CBC . Dans ce mode de fonctionnement, chaque bloc de données est dabord XORé avec le résultat du cryptage du bloc précédent; et cest le résultat du XOR qui est chiffré. Ceci est fait pour « randomiser » les blocs et pour éviter les fuites qui se trouvent en mode ECB. Puisque le premier bloc na pas un bloc « précédent », il doit y avoir un vecteur dinitialisation (IV), qui joue le rôle du bloc précédent pour le premier bloc.

Il savère que si un attaquant peut contrôler une partie des données à chiffrer, et peut également prédire lIV qui sera utilisé, alors il peut transformer la machine de chiffrement en un autre déchiffrement oracle et lutiliser pour récupérer dautres données chiffrées (que lattaquant ne choisit pas). Cependant, dans SSLv3 et TLS 1.0, lattaquant peut prédire lIV dun enregistrement: cest le dernier bloc de lenregistrement précédent! Donc, lattaquant doit être capable denvoyer des données dans le flux, afin de « pousser » les données cibles, à un point où limplémentation a construit et envoyé lenregistrement précédent (généralement lorsque 16 ko valent des données ont été accumulées), mais na pas commencé à construire le suivant.

TLS 1.1+ est protégé contre cela car dans TLS 1.1 (et les versions ultérieures), un IV aléatoire par enregistrement est utilisé. Pour SSLv3 et TLS 1.0, une solution de contournement consiste à envoyer des enregistrements de longueur nulle: cest-à-dire des enregistrements avec une charge utile de longueur zéro – mais avec un MAC et un remplissage et un cryptage, et le MAC est calculé à partir dune clé secrète et sur la séquence nombre, donc cela joue le rôle dun générateur de nombres aléatoires. Malheureusement, IE 6.0 sétouffe sur les enregistrements de longueur nulle. Dautres stratégies impliquent une division 1 / n-1 (un enregistrement n octets est envoyé sous forme de deux enregistrements, lun avec un seul octet de charge utile, lautre avec les n-1 ).

Une autre solution de contournement consiste à forcer lutilisation dune suite de chiffrement non CBC lorsque cela est possible – le serveur sélectionne une suite de chiffrement basée sur RC4 sil y en a une dans la liste des suites de chiffrement envoyées par le client, même si le client aurait préféré une suite de chiffrement basée sur CBC. Cet outil peut vous dire si un serveur donné agit apparemment comme ça.(Remarque: BEAST est une attaque contre le client , mais, en sélectionnant une suite de chiffrement RC4, le serveur peut protéger un client imprudent.)

Voir cette page pour quelques pointeurs. Alors que TLS 1.1 date de 2006, lattaque BEAST peut forcer les fournisseurs de navigateurs à se mettre enfin à niveau.

CRIME

Comme pour toute franchise hollywoodienne, Duong et Rizzo ont publié en 2012 la suite de la suite. CRIME exploite une fuite qui a été théorisée il y a des années mais qui na été clairement démontrée que dans la démonstration quils ont récemment publiée. CRIME exploite la compression, dans la même configuration que lattaque BEAST (lattaquant peut envoyer ses propres données dans une connexion SSL, où des données cibles intéressantes telles quun cookie sont également envoyées). En gros, lattaquant met dans ses données une valeur potentielle pour la chaîne cible et, si elle correspond, la compression raccourcit les enregistrements résultants. Voir cette question pour une analyse (pré-cognitive).

Le CRIME est évité en nutilisant pas du tout la compression au niveau TLS, ce qui est ce que font maintenant les navigateurs. Internet Explorer et IIS nont jamais implémenté la compression au niveau TLS en premier lieu (pour une fois, la négligence a sauvé la journée); Firefox et Chrome lont implémenté et désactivé cet été (ils ont été prévenus par Duong et Rizzo, qui sont assez responsables dans leur activité).

CRIME montre pourquoi jai écrit, vers le début de mon Explications SSL :

SSL remplit ces objectifs dans une large mesure (mais pas absolue).

En effet, le chiffrement perd la longueur des données chiffrées. Il ny a pas de bonne solution connue contre cela. Et la longueur seule peut révéler beaucoup de choses. Par exemple, lorsque nous observons avec un moniteur réseau une connexion SSL, nous pouvons repérer les «poignées de main supplémentaires» dans le flux (car le premier octet de chaque enregistrement identifie le type de données dans lenregistrement, et il nest pas crypté); avec les longueurs des enregistrements, il est assez facile de voir si le client a fourni un certificat ou non.

Poodle

( edit: cette section a été ajoutée le 15/10/2014)

Lattaque « Poodle » exploite une faille spécifique à SSL 3.0 avec des suites de chiffrement basées sur CBC. Il repose sur une fonctionnalité souvent négligée de SSL 3.0: la plupart des octets de remplissage sont ignorés. Dans TLS 1.0, le remplissage (octets ajoutés dans un enregistrement pour rendre la longueur compatible avec le cryptage CBC, qui ne traite que les blocs complets) est entièrement spécifié; tous les octets doivent avoir une valeur spécifique et le destinataire le vérifie. Dans SSL 3.0, le contenu des octets de remplissage est ignoré, ce qui permet à un attaquant deffectuer des modifications qui passent généralement inaperçues. La modification na dincidence que sur les données non applicatives mais peut être utilisée comme oracle de décryptage dune manière vaguement similaire à BEAST.

Plus de détails peuvent être lus dans this réponse .

Lavenir

Les humains napprennent jamais. Il y a beaucoup de pression pour ajouter des extensions astucieuses à SSL pour de nombreuses raisons qui semblent toujours bonnes au début, mais peuvent induire des problèmes supplémentaires.

Considérez, par exemple, SSL FalseStart . Il sagit principalement du client qui envoie ses données dapplication juste après avoir envoyé son message Finished (dans une prise de contact complète), sans attendre le Finished message du serveur. Cela réduit la latence, ce qui est bon et bien intentionné. Cependant, cela change la situation de sécurité: avant davoir reçu le message Finished du serveur, celui-ci nest authentifié quimplicitement (le client na pas encore la preuve que le serveur visé était réellement impliqué à tout; il sait juste que tout ce quil envoie ne sera lisible que par le serveur prévu). Cela peut avoir des impacts; par exemple, un attaquant pourrait émuler le serveur jusquà ce point et forcer, par exemple, le client à utiliser une suite de chiffrement basée sur CBC ou une compression TLS. Par conséquent, si un client implémente FalseStart, cela diminue lefficacité des mesures de protection contre BEAST et CRIME, comme cela pourrait autrement être appliqué par le serveur.

(Google désactivé FalseStart ce printemps, apparemment à cause de problèmes de compatibilité avec certains serveurs. Quoi quil en soit, la « réduction de la latence de 30% » semblait bizarre, car FalseStart naurait une certaine influence que sur les poignées de main complètes, et non sur les poignées de main abrégées, donc je ne le fais pas.  » Je ne crois pas à ces prétendus avantages; pas à cette ampleur, du moins.)

Commentaires

• Les efforts que vous déployez pour fournir de bonnes informations ce site est vraiment fou et extrêmement admirable. Très apprécié.
• Voir aussi tools.ietf.org / html / rfc7457