Cours MIT "Sécurité des systèmes informatiques". Conférence 14: «SSL et HTTPS», partie 1

Institut de technologie du Massachusetts. Cours magistral # 6.858. "Sécurité des systèmes informatiques." Nikolai Zeldovich, James Mickens. 2014 année

Computer Systems Security est un cours sur le développement et la mise en œuvre de systèmes informatiques sécurisés. Les conférences couvrent les modèles de menace, les attaques qui compromettent la sécurité et les techniques de sécurité basées sur des travaux scientifiques récents. Les sujets incluent la sécurité du système d'exploitation (OS), les fonctionnalités, la gestion du flux d'informations, la sécurité des langues, les protocoles réseau, la sécurité matérielle et la sécurité des applications Web.

Cours 1: «Introduction: modèles de menace» Partie 1 / Partie 2 / Partie 3
Conférence 2: «Contrôle des attaques de pirates» Partie 1 / Partie 2 / Partie 3
Conférence 3: «Débordements de tampon: exploits et protection» Partie 1 / Partie 2 / Partie 3
Conférence 4: «Séparation des privilèges» Partie 1 / Partie 2 / Partie 3
Conférence 5: «D'où viennent les systèmes de sécurité?» Partie 1 / Partie 2
Conférence 6: «Opportunités» Partie 1 / Partie 2 / Partie 3
Conférence 7: «Native Client Sandbox» Partie 1 / Partie 2 / Partie 3
Conférence 8: «Modèle de sécurité réseau» Partie 1 / Partie 2 / Partie 3
Conférence 9: «Sécurité des applications Web», partie 1 / partie 2 / partie 3
Conférence 10: «Exécution symbolique» Partie 1 / Partie 2 / Partie 3
Conférence 11: «Ur / Web Programming Language» Partie 1 / Partie 2 / Partie 3
Conférence 12: Sécurité du réseau, partie 1 / partie 2 / partie 3
Conférence 13: «Protocoles réseau», partie 1 / partie 2 / partie 3
Conférence 14: «SSL et HTTPS» Partie 1 / Partie 2 / Partie 3

Nous allons maintenant voir comment les protocoles cryptographiques sont utilisés pour protéger les connexions réseau sur Internet et comment ils interagissent généralement avec les facteurs réseau. Avant d'entrer dans les détails, je tiens à vous rappeler qu'il y aura un test mercredi, mais pas dans ce public, mais à Walker, au 3ème étage, lors d'un cours régulier.



Donc, aujourd'hui, nous allons parler de la façon dont Internet utilise la cryptographie pour protéger une connexion réseau et examiner deux sujets étroitement liés.

La première est de savoir comment sécuriser cryptographiquement les connexions à une plus grande échelle que le système Kerberos, que nous avons couvert dans la dernière conférence, protège. La seconde est de savoir comment intégrer cette protection cryptographique, fournie au niveau du réseau, dans l'ensemble de l'application, et comment le navigateur Web garantit l'utilisation de la protection fournie par le protocole cryptographique. Ces sujets sont étroitement liés, il s'avère donc que la protection des communications réseau est assez facile à fournir, car la cryptographie fonctionne toujours. Mais l'intégrer dans le navigateur est une tâche beaucoup plus difficile que de construire un système autour de la cryptographie.

Avant de plonger dans cette discussion, je veux vous rappeler les éléments de base de la cryptographie que nous utiliserons.

Dans notre dernière conférence sur Kerberos, nous avons utilisé la cryptographie symétrique, ou
cryptage et décryptage. Cela signifie que vous avez une clé secrète K et deux fonctions. Ainsi, vous pouvez prendre des données, appelons-le P, c'est du texte brut auquel vous pouvez appliquer la fonction de chiffrement, et c'est la fonction d'une clé K. Et si vous chiffrez ce texte brut, vous obtiendrez le texte chiffré C.De même, nous avons il existe une fonction de déchiffrement D qui utilise la même clé K, à la suite de quoi le texte chiffré C se transformera en texte brut P. C'est la primitive autour de laquelle Kerberos a été construit.



Mais il s'avère qu'il existe d'autres primitives qui seront utiles pour la discussion d'aujourd'hui, et qui sont appelées chiffrement et déchiffrement asymétriques. L'idée ici est d'avoir différentes clés pour le chiffrement et le déchiffrement. Voyons pourquoi cela est si utile.

Ici, il y a une fonction E, qui peut chiffrer un certain ensemble de messages P avec une certaine clé publique pk, pour obtenir le texte chiffré C. Pour le déchiffrer avec la fonction D, il suffit de spécifier la clé secrète correspondante sk et d'obtenir le texte source P.



La commodité du chiffrement asymétrique est que vous pouvez publier une clé publique sur Internet et que les gens peuvent chiffrer les messages pour vous, mais vous avez besoin d'une clé secrète pour déchiffrer leurs messages. Aujourd'hui, nous verrons comment cela est utilisé dans le protocole. En pratique, vous utiliserez souvent la cryptographie à clé publique d'une manière légèrement différente. Par exemple, au lieu de chiffrer et de déchiffrer des messages, vous devrez peut-être signer ou vérifier des messages.

Il s'avère qu'au niveau de l'implémentation, ce sont des opérations connexes, mais au niveau de l'application API, elles peuvent sembler un peu différentes. Par exemple, vous pouvez signer le message M avec votre clé secrète sk et obtenir une signature S. Ensuite, vous pouvez vérifier ce message avec la clé publique correspondante pk et en conséquence obtenir un indicateur logique indiquant si la signature S est correcte pour le message M.



Voici quelques garanties relativement intuitives qui offrent ces fonctionnalités. Si, par exemple, vous avez reçu cette signature et qu'elle est vérifiée correctement, cela signifie qu'elle devait être générée par quelqu'un avec la bonne clé secrète. Est-ce clair?

Essayons ensuite de comprendre comment protéger les connexions réseau à une plus grande échelle que Kerberos. À Kerberos, nous avions un modèle assez simple, où tous les utilisateurs et serveurs utilisaient une sorte de connexion avec l'objet KDC, qui avait cette table géante d'utilisateurs, de services et leurs clés. Chaque fois qu'un utilisateur veut parler à un serveur, il doit demander à KDC de créer le ticket dont il a besoin en fonction de cette table géante.



Cela semble donc être un modèle assez simple. Alors pourquoi avons-nous besoin d'autre chose? Pourquoi Kerberos n'est-il pas assez bon pour travailler avec des sites? Pourquoi Internet n'utilise-t-il pas Kerberos exclusivement pour sécuriser toutes les connexions?

Vous avez répondu correctement - parce que le seul KDC devrait faire confiance à tout le monde, et c'est mauvais. Vous pouvez avoir des problèmes si vous considérez qu'une certaine machine est absolument sûre.

Peut-être que les gens du MIT sont prêts à faire confiance à quelqu'un sur le réseau local géré par KDC, mais pas à tout le monde sur Internet.

Et la réponse du deuxième étudiant est également correcte - il est très difficile de gérer un si grand nombre de clés. En fait, il peut être très difficile de construire un seul KDC capable de gérer un milliard de clés ou dix milliards de clés pour toutes les personnes dans le monde. Une autre complication de l'utilisation de Kerberos pour l'ensemble d'Internet est que tous les utilisateurs doivent avoir une clé ou doivent être connus par KDC. Vous ne pouvez même pas utiliser Kerberos dans notre institut pour vous connecter à certains serveurs si vous n'avez pas de compte dans la base de données Kerberos. Alors que pour tout Internet, il est tout à fait raisonnable de s'attendre à ce que lorsque vous allez à l'ordinateur, il ne sache pas du tout qui vous êtes, mais cela vous permettra d'aller sur le site Web d'Amazon, qui est protégé par la cryptographie.



Hein?

Il y a plusieurs autres choses que vous attendez d'un protocole cryptographique, et nous verrons comment elles apparaissent dans SSL. Mais l'idée clé est que cette solution est la même pour Kerberos et pour SSL ou TLS. Vous avez raison lorsque vous mentionnez que les protocoles Kerberos originaux que nous lisons dans les documents de cours ont été développés il y a longtemps. Et si nous voulons les utiliser pour l'Internet moderne, ils devront changer quelque chose. Quelles autres pensées avez-vous, pourquoi ne devrions-nous pas utiliser Kerberos?

C'est vrai, il y a un problème de mise à l'échelle lors de la restauration de l'accès, et éventuellement lors de l'enregistrement de nouveaux utilisateurs, car vous devrez vous rendre personnellement dans un bureau de compte et y ouvrir un compte. Quoi d'autre?

Étudiant: Le serveur Kerberos doit toujours être en ligne.

Professeur: oui, c'est un autre problème. Nous avons répertorié certains types de problèmes de gestion, mais au niveau du protocole, KDC doit toujours être en ligne, car il sert en fait d'intermédiaire pour toutes vos interactions avec les services. Cela signifie que chaque fois que vous visitez un nouveau site Web, vous devez parler à KDC. Premièrement, ce sera un goulot d'étranglement en termes de performances. Comme d'autres types d'évolutivité, ce principe conduira à une évolutivité des performances, tandis que les principes énumérés ci-dessus ne conduisent qu'à une évolutivité de la gestion.



Alors, comment pouvons-nous résoudre ce problème en utilisant ces principes? L'idée est d'utiliser le chiffrement par clé pour arrêter d'utiliser KDC.

Voyons d'abord si vous pouvez établir une connexion sécurisée si vous ne connaissez que certaines des clés publiques de l'autre côté. Et puis nous verrons comment nous connectons la version de la clé publique KDC à l'authentification des parties dans ce protocole. Si vous ne souhaitez pas utiliser KDC, vous pouvez effectuer les opérations suivantes avec la cryptographie à clé publique: découvrez en quelque sorte la clé publique du partenaire de l'autre côté de la connexion. Donc, à Kerberos, si je veux me connecter à un serveur de fichiers, je connais la clé publique du serveur de fichiers quelque part. En tant que recrue, je reçois un imprimé disant que la clé publique du serveur de fichiers est telle ou telle, et je peux l'utiliser pour me connecter.

Vous pouvez simplement crypter le message pour la clé publique du serveur de fichiers auquel vous souhaitez vous connecter. Mais il s'avère qu'en pratique, ces opérations avec ces clés publiques sont assez lentes. Ils sont plusieurs ordres de grandeur plus lents que les clés de chiffrement symétriques. Donc, dans la pratique, vous souhaitez généralement toujours abandonner l'utilisation du chiffrement public.

Ainsi, un protocole typique pourrait ressembler à ceci. Vous avez A et B, ils veulent communiquer, et A connaît la clé publique B. En même temps, A génère une sorte de clé de session S, en choisissant simplement un nombre aléatoire pour cela. Ensuite, A est sur le point d'envoyer la clé de session S B, il ressemble donc à Kerberos. Nous allons chiffrer la clé de session S pour B.

Si vous vous souvenez, à Kerberos, pour ce faire, nous avions besoin d'un KDC parce que A ne connaissait pas la clé de B ou qu'il n'était pas autorisé à la connaître, car c'est un secret que seul B peut connaître. Mais avec une clé publique, vous pouvez le faire immédiatement, il suffit de crypter le secret avec cette clé publique Bspk et d'envoyer le message B. Maintenant, B peut décrypter ce message et dire: j'ai besoin d'utiliser cette clé secrète. Nous avons maintenant un canal de communication où tous les messages sont simplement cryptés avec cette clé secrète S.



Il y a donc quelques fonctionnalités utiles dans ce protocole. Premièrement, nous nous sommes débarrassés de la nécessité d'avoir KDC en ligne et de générer une clé de session pour nous. Nous pourrions simplement garantir la confidentialité des informations transmises si l'une des parties à la connexion les génère puis les chiffre pour l'autre sans utiliser KDC.

Une autre bonne chose est la certitude que seul B peut lire les messages envoyés de A à B, car seul B peut déchiffrer ce message. Par conséquent, B doit avoir la clé privée correspondante S.

Étudiant: importe qui donne cette clé - utilisateur ou serveur?

Professeur: peut - être. Je pense que cela dépend des propriétés que vous voulez de ce protocole. Par conséquent, que se passe-t-il si A fait une erreur ou utilise le mauvais caractère aléatoire, le serveur qui renvoie les données pense: "Oh, maintenant ce sont les seules données que A verra." Ce n'est peut-être pas tout à fait vrai, alors vous devriez y penser. Il existe plusieurs autres problèmes avec ce protocole.

Étudiant: Un attaquant peut-il utiliser une clé pour envoyer des messages répétés?

Professeur: oui, le problème peut être que je peux simplement envoyer à nouveau ces messages, et il semblera que c'est A qui envoie à nouveau le message B, et ainsi de suite.

Par conséquent, généralement la solution à ce problème est que les deux côtés de la connexion sont impliqués dans la génération de S et cela garantit que la clé que nous utilisons est «fraîche». Parce qu'ici, sur la figure, en réalité, B ne génère rien, de sorte que ces messages de protocole se ressemblent à chaque fois.

Il arrive généralement qu'un côté choisisse un nombre aléatoire comme S, puis l'autre côté, B, choisit également un nombre aléatoire, généralement appelé nonce. Il y a deux chiffres et une clé qui n'est pas vraiment sélectionnée uniquement par un côté, c'est un hachage que les deux côtés ont choisi pour l'interaction conjointe. En plus du hachage, vous pouvez utiliser le protocole Diffie-Hellman, que nous avons examiné dans la dernière conférence, grâce auquel vous obtenez d'abord la confidentialité. Il s'agit de mathématiques plus compliquées que de simplement hacher deux nombres aléatoires qui ont choisi ces deux côtés. Mais vous obtiendrez alors une propriété aussi bonne que la clé secrète partagée d'origine, éliminant ainsi la nécessité de transférer la clé de déchiffrement lors de la transmission de données chiffrées.

Ainsi, des attaques répétées peuvent être évitées comme suit. B génère un nonce et définit ensuite la vraie clé secrète S ', qui est utilisée pour hacher la clé secrète S avec ce nonce. Et, bien sûr, B devrait renvoyer le nonce à A pour savoir ce qui se passe lorsqu'ils s'accordent tous les deux sur la clé.



Un autre problème est qu'il n'y a pas de véritable authentification A. A sait qui est B, ou du moins sait qui peut décrypter les données. Mais B n'a aucune idée de qui est de l'autre côté, que ce soit une sorte d'adversaire se faisant passer pour un autre ou quelqu'un d'autre. Comment résoudre ce problème dans le monde des clés publiques?

Il existe plusieurs façons de procéder. Une possibilité est de signer ce message initialement, car nous avons ce bon principe de signe. Nous pourrions donc peut-être signer cela avec une clé secrète. Ce signe fournit simplement une signature, mais vous l'assignez probablement, et vous fournissez également ce message.

Ensuite, B doit savoir que A est une clé publique afin de vérifier la signature. Mais si B sait que A est une clé publique, alors B sera à peu près sûr que A est celui qui a envoyé ce message.



Vous pouvez également faire confiance au chiffrement. Donc peut-être que B peut renvoyer nonce à A, en le chiffrant avec la clé publique fournie par A. Et alors seulement A peut déchiffrer nonce et générer la clé de session finale S '. Il y a donc quelques astuces que vous pourriez faire. C'est ainsi que les certificats clients fonctionnent aujourd'hui dans les navigateurs Internet.

Ainsi, A possède une clé secrète et, par conséquent, lorsque vous recevez un certificat MIT personnel, votre navigateur crée une clé secrète de longue durée et reçoit un certificat pour celle-ci. Et chaque fois que vous envoyez une demande au serveur Web, vous prouvez que vous connaissez la clé secrète de votre certificat utilisateur, puis définissez la clé secrète S pour le reste de la connexion.

Ce sont des problèmes qui sont assez facilement résolus au niveau du protocole. Cependant, la base de tout ce qui précède est que toutes les parties connaissent les clés publiques de l'autre. Comment savoir la clé publique de quelqu'un? Supposons que je veuille me connecter à un site Web, que j'ai une URL à laquelle je veux me connecter, ou un nom d'hôte, comment puis-je savoir quelle clé publique correspond?

De même, si je me connecte au serveur MIT pour voir mes notes, comment le serveur sait-il quelle devrait être ma clé publique pour la distinguer de la clé publique d'un autre étudiant du MIT?

C'est le principal problème que le KDC a abordé. En fait, KDC a résolu deux problèmes pour nous. Tout d'abord, il a généré un message (Ebspk (S)), créé une clé de session et l'a chiffrée pour le serveur. Nous avons maintenant corrigé cela en créant une cryptographie à clé publique. Mais nous devions également faire correspondre les noms de chaîne principaux aux clés cryptographiques Kerberos qui nous avaient été fournies plus tôt.

Il existe un protocole TLC pour de telles choses dans le monde HTTPS. Cela signifie que nous continuerons à nous appuyer sur certains aspects du processus qui prennent en charge ces gigantesques tables qui mappent les noms des participants au processus aux clés cryptographiques. Le plan est que nous aurons quelque chose appelé une autorité de certification, qui est indiquée par les lettres CA dans toutes sortes de littérature sur la sécurité du réseau. Cette autorité de certification prend également en charge logiquement le tableau, dans une partie dont les noms de tous les participants sont affichés, et dans l'autre - les clés publiques correspondantes. La principale différence entre ce centre et Kerberos est que cette autorité de certification n'a pas à être en ligne pour toutes les transactions.
À Kerberos, pour vous connecter avec quelqu'un ou trouver la clé de quelqu'un d'autre, vous devez parler à KDC. Au lieu de cela, dans le monde de CA, ils le font.



Si vous avez ici une sorte de nom et la clé correspondante dans une autre partie du tableau, l'autorité de certification va simplement signer des messages indiquant que certaines lignes existent dans ce tableau. Ainsi, l'autorité de certification devra avoir ses propres clés privées et publiques ici. Il utilisera une clé secrète pour trouver des messages pour d'autres utilisateurs sur le système sur lesquels vous pouvez compter.

Donc, si vous avez un enregistrement «nom + clé» dans la base de données de l'autorité de certification, l'autorité de certification créera un message indiquant que ce nom correspond à cette clé publique et signera ce message avec sa clé privée de l'autorité de certification.



Cela vous permet de faire des choses très similaires à ce que fait Kerberos, mais en même temps, nous nous débarrassons de la nécessité de trouver une CA en ligne pour toutes les transactions. Et, il sera en fait beaucoup plus évolutif. C'est exactement ce qu'on appelle communément un certificat. L'évolutivité est assurée par le fait que pour un client ou toute autre personne utilisant ce système, un certificat fourni par une source n'est pas inférieur à un certificat provenant d'une autre source. Il est signé par la clé secrète de l'autorité de certification. Vous pouvez donc vérifier son authenticité sans avoir à contacter une autorité de certification ou toute autre partie répertoriée ici.

Ça fonctionne comme ça. Le serveur avec lequel vous souhaitez parler stocke le certificat qu'il a initialement reçu de l'autorité de certification. Et chaque fois que vous vous y connectez, le serveur vous dit: «OK, voici mon certificat. Il a été signé par ce CA. Vous pouvez vérifier la signature et vous assurer qu'il s'agit bien de ma clé publique et de mon nom. »

En revanche, la même chose se produit avec les certificats clients. Lorsqu'un utilisateur se connecte au serveur Web, son certificat client indique que votre clé publique correspond à la clé secrète générée à l'origine dans le navigateur. Ainsi, lors de la connexion au serveur, vous allez présenter un certificat signé par l'autorité de certification MIT, qui indique que votre nom d'utilisateur correspond à cette clé publique. , , , , Athena.

: , ?

: , , – , ? - , , , , . - , . . , VeriSign. US Postal Service CA, , . , CA , KDC.

, , Kerberos. , , KDC. , KDC, , . , , . CA , KDS.

: ?

: , . , , KDC, . , . , , . , , , . Kerberos, . Kerberos , . , , . , , . , .

, . , , CA - , . , amazon.com, amazon.com. CA, . , , , .



. , CA , , , , - , . , , . - , amazon.com, , - .

, -, , , , . , . «» , , .

, . -, CRL, ertificate Revocation List. . , - , . , , , : «, , , - . , ».

, , , CRL, , web-, CRL. , - , , . , , , , , .

, . , . , . , . , CRL, - .

, ? , . , CRL .

, , , Kerberos, KDC. CA , . , « SSL », OCSP. CA KDC. , , , , , , - . , OCSP, : «, . , »? , CRL . , , . , , .

26:30

MIT « ». 14: «SSL HTTPS», 2


.

Merci de rester avec nous. ? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en le recommandant à vos amis, une réduction de 30% pour les utilisateurs Habr sur un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbps à partir de 20 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbit / s jusqu'en décembre gratuitement en payant pour une période de six mois, vous pouvez commander ici .

Dell R730xd 2 ? Nous avons seulement 2 x Intel Dodeca-Core Xeon E5-2650v4 128 Go DDR4 6x480 Go SSD 1 Gbps 100 TV à partir de 249 $ aux Pays-Bas et aux États-Unis! Pour en savoir plus sur la création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?