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

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

La première raison est que le protocole OCSP ajoute un délai à chaque demande que vous faites. Chaque fois que vous souhaitez vous connecter à un serveur, vous devez d'abord vous connecter à OCSP, attendre qu'il réponde, puis faire autre chose. Les retards de connexion ne contribuent donc pas à la popularité de ce protocole.

La deuxième raison est que vous ne voulez pas que l'OCSP affecte votre capacité à naviguer sur le Web. Supposons que le serveur OSCP soit en panne, puis vous pouvez complètement perdre Internet, car le protocole considère que puisqu'il ne peut pas vérifier le certificat de quelqu'un, il est possible que tous les sites sur Internet soient mauvais et vous ne devriez pas être autorisé à y aller. Mais personne n'en a besoin, donc la plupart des clients considèrent la non-interférence du serveur OCSP comme une évolution positive.



C'est vraiment mauvais du point de vue de la sécurité. Parce que si vous êtes un attaquant et que vous voulez convaincre quelqu'un que vous avez un certificat légal, mais qu'en réalité ce certificat a été révoqué, tout ce que vous devez faire est d'empêcher le client de communiquer avec le serveur OCSP.

Le client dira ceci: "J'essaie de demander une vérification de certificat du site dont j'ai besoin, mais cet OCSP, semble-t-il, n'est pas à proximité, donc je vais simplement sur ce site." Donc, utiliser OCSP n'est pas un bon plan.

En pratique, les gens essaient de créer cette alternative, car les clients ont simplement tendance à commettre de graves erreurs. Ainsi, par exemple, le navigateur Web Chrome est livré au client, ayant déjà en lui-même une liste de certificats que Google veut vraiment révoquer. Donc, si quelqu'un émet de manière incorrecte un certificat pour Gmail ou un autre site important, tel que Facebook ou Amazon, la prochaine version de Chrome contiendra déjà ces informations dans la liste de vérification intégrée. De cette façon, vous n'avez pas besoin d'accéder au serveur CRL et de communiquer avec OCSP. Si le navigateur a vérifié que le certificat n'est plus valide, le client le rejette.

Étudiant: disons que j'ai volé la clé secrète de l'autorité de certification, car toutes les clés publiques ne sont pas chiffrées?

Professeur: oui, cela aura de graves conséquences. Je ne pense pas qu'il existe de solution à ce problème. Bien sûr, il y a eu des situations où les centres de certification ont été compromis, par exemple, en 2011, deux autorités de certification compromises ont émis des certificats pour Gmail, Facebook, etc. On ne sait pas comment cela s'est produit, peut-être que quelqu'un a vraiment volé sa clé secrète. Mais quelles que soient les raisons du compromis, ces autorités de certification ont été supprimées de la liste des autorités de certification de confiance, qui est intégrée aux navigateurs, de sorte qu'elles ne figuraient plus dans la prochaine version de Chrome.

En fait, cela a causé des problèmes aux titulaires légitimes de certificats délivrés par ces centres, car leurs certificats antérieurs sont devenus invalides et ils ont dû obtenir de nouveaux certificats. Donc, dans la pratique, tout ce tapage avec les certificats est assez confus.

Nous avons donc examiné le principe général des certificats. Ils sont meilleurs que Kerberos dans le sens où vous n'avez plus besoin que ce gars soit en ligne tout le temps. De plus, ils sont plus évolutifs, car vous pouvez avoir plusieurs KDC et vous n'avez pas besoin de communiquer avec eux chaque fois que vous établissez une connexion.

Une autre caractéristique intéressante de ce protocole est que, contrairement à Kerberos, vous n'êtes pas obligé d'authentifier les deux côtés de la connexion. Vous pouvez vous connecter au serveur Web sans avoir de certificat pour vous, et cela se produit tout le temps. Si vous allez sur amazon.com, vous allez vérifier qu'Amazon est le bon site, mais Amazon n'a aucune idée de qui vous êtes et ne le saura pas jusqu'à ce que vous vous authentifiiez sur le site. Ainsi, au niveau du protocole de chiffrement, vous n'avez pas de certificat, mais Amazon en a un.

C'est bien mieux que Kerberos, car là, vous devez avoir une entrée dans sa base de données pour vous connecter aux services Kerberos. Le seul inconvénient de l'utilisation de ce protocole est que le serveur doit avoir un certificat. Vous ne pouvez donc pas vous connecter au serveur et dire: «hé, chiffrons simplement nos affaires. Je n'ai aucune idée de qui tu es, mais tu n'as aucune idée de qui je suis, mais chiffrons-le quand même. » C'est ce qu'on appelle le chiffrement opportuniste, et bien sûr, il est vulnérable aux attaques de l'homme du milieu. Vous pouvez crypter des choses courantes avec quelqu'un, sans le connaître, puis un attaquant qui se prépare à vous attaquer peut également crypter plus tard ses paquets et se protéger de l'espionnage.

Il est donc un peu dommage que ces protocoles que nous considérons ici - SSL, TLS - n'offrent pas ce type de cryptage opportuniste. Mais telle est la vie.



Étudiant: Je suis juste curieux. Disons simplement qu'une fois par an, ils créent des paires de clés avec de nouveaux noms. Pourquoi ne pas essayer d'utiliser cette clé toute l'année?

Professeur: Je pense qu'ils le font. Mais quelque chose semble aller mal avec ce circuit. Ici, comme avec Kerberos, les gens commencent par utiliser un cryptage fort, mais au fil du temps, cela empire. Les ordinateurs sont de plus en plus rapides, de nouveaux algorithmes sont en cours de développement qui parviennent à casser ce cryptage. Et si les gens ne se soucient pas d'améliorer la fiabilité, les problèmes s'aggravent. Ainsi, par exemple, cela se produit lorsqu'un grand nombre de certificats sont signés.

Il y a deux nuances ici. Il existe un schéma de signature à clé publique. De plus, étant donné que la clé publique chiffrée présente certaines limites, lors de la signature d'un message, en réalité, seul le hachage de ce message est signé, car il est difficile de signer un gigantesque message, mais il est facile de signer un hachage compact.

Le problème est survenu parce que les gens utilisaient MD5 comme fonction de hachage, transformant la signature d'un énorme message en une chose de 128 bits qui était cryptée. Peut-être que MD5 était bon il y a 20 ans, mais au fil du temps, les gens y ont découvert des faiblesses qui pourraient être exploitées par un attaquant.

Supposons qu'à un moment donné, quelqu'un ait vraiment demandé un certificat avec un hachage MD5 spécifique, puis ait soigneusement analysé un autre message haché avec la même valeur MD5. En conséquence, il avait une signature CA hachée, puis un autre message est apparu, ou une clé différente, ou un nom différent, et maintenant il peut convaincre quelqu'un qu'il est signé avec le certificat correct. Et cela se produit vraiment. Par exemple, si vous passez beaucoup de temps à essayer de casser une clé, vous finirez par réussir. Si ce certificat utilise le chiffrement, il peut être craqué à l'aide de la méthode de force brute.

Un autre exemple d'utilisation infructueuse du chiffrement est l'algorithme RSA. Nous n'avons pas parlé de RSA, mais RSA est l'un de ces systèmes cryptographiques à clé publique qui vous permet de crypter et de signer des messages. De nos jours, vous pouvez dépenser beaucoup d'argent, mais à la fin, craquez les clés RSA 1000 bits. Vous devrez probablement faire un travail gigantesque, mais c'est facile à faire tout au long de l'année. Vous pouvez demander à l'autorité de certification de signer un message ou même de prendre la clé publique existante de quelqu'un, d'essayer de trouver la clé secrète appropriée ou de la pirater manuellement.
Ainsi, vous devez suivre l'attaquant, vous devez utiliser des clés RSA plus grandes ou utiliser un schéma de cryptage différent.

Par exemple, les utilisateurs n'utilisent plus de hachage et de certificats MD5. Ils utilisent l'algorithme de hachage cryptographique SHA-1. Pendant un certain temps, il a fourni la sécurité nécessaire, mais aujourd'hui c'est une défense faible. Maintenant, Google essaie activement de forcer les développeurs de sites Web et de navigateurs à abandonner l'utilisation de SHA-1 et à utiliser une fonction de hachage différente, car il est tout à fait clair qu'après 5 ou 10 ans, il ne sera pas difficile d'attaquer avec succès SHA-1. Sa faiblesse a déjà été prouvée.

Donc, je suppose que la balle magique en tant que telle n'existe pas. Il vous suffit de vous assurer de continuer à vous développer en parallèle avec les hackers. Bien sûr, le problème existe. Par conséquent, toutes les choses dont nous avons parlé devraient être basées sur un cryptage approprié, ou sur le fait qu'il est très difficile à déchiffrer. Par conséquent, vous devez choisir les options appropriées. Au moins, il y a une date d'expiration, il est donc préférable de choisir une date d'expiration de 1 an, plutôt que de 10 ans.



Cette clé d'autorité de certification crée un problème plus grave, car elle n'a pas de date d'expiration. Par conséquent, vous devez choisir des paramètres de sécurité plus agressifs, par exemple, des clés RSA 4000 ou 6000 bits, ou autre chose. Ou un schéma de cryptage différent, ou tous ensemble, mais n'utilisez pas SHA-1 ici.

Voyons maintenant comment nous intégrons ce protocole dans une application spécifique, à savoir un navigateur Web. Si vous souhaitez fournir une communication réseau ou une communication avec des sites utilisant la cryptographie, il y a trois choses dans le navigateur que nous devons protéger.

La première chose, A est la protection des données sur le réseau. C'est relativement facile car nous allons simplement exécuter un protocole très similaire à celui que j'ai décrit jusqu'à présent. Nous allons crypter tous les messages, les signer, nous assurer qu'ils n'ont pas été falsifiés, en général, nous ferons toutes ces choses merveilleuses. C'est ainsi que nous protégerons les données.

Mais il y a deux autres choses dans le navigateur Web dont nous devons vraiment nous inquiéter. Ainsi, le premier, B, est le code utilisé dans le navigateur, par exemple, JavaScript ou des données importantes stockées dans le navigateur, vos cookies ou le stockage local, tout cela doit être en quelque sorte protégé contre les pirates. Dans une seconde, je vous dirai comment les protéger.

Le dernier, C, auquel vous ne pensez souvent pas, mais ce qui peut s'avérer être un vrai problème dans la pratique, c'est la protection de l'interface utilisateur. Et la raison en est que, en fin de compte, la plupart des données confidentielles dont nous nous soucions de la protection proviennent de l'utilisateur. Ainsi, l'utilisateur imprime des données sur un site, et il a probablement plusieurs onglets de sites différents ouverts simultanément, il doit donc être capable de distinguer avec quel site il interagit réellement, à tout moment.



S'il saisit accidentellement le mot de passe Amazon sur un forum Web, cela n'entraînera pas de conséquences désastreuses, selon l'importance qu'il accorde à son mot de passe Amazon, mais ce sera toujours désagréable. Par conséquent, vous voulez vraiment avoir une bonne interface utilisateur qui aide l'utilisateur à comprendre ce qu'il fait, s'il imprime des données sensibles sur le bon site et si quelque chose arrive à ces données après leur envoi. Cela s'avère donc être un problème assez important pour la protection des applications Web.

Parlons donc de ce que les navigateurs modernes font avec ces choses A, B et C. Comme je l'ai mentionné, pour protéger les données sur le réseau, nous utiliserons simplement ce protocole, appelé SSL ou TLS, si le cryptage et l'authentification des données sont utilisés.



Ceci est très similaire à ce dont nous avons discuté, et inclut les autorités de certification, etc. Et puis, bien sûr, il y a beaucoup plus de détails. Par exemple, TLS est extrêmement complexe, mais nous ne le considérerons pas de ce point de vue. Nous nous concentrerons sur la protection du navigateur, ce qui est beaucoup plus intéressant. Nous devons nous assurer que tout code ou données fournis via des connexions non cryptées ne sont pas capables de modifier le code et les données reçus d'une connexion cryptée, car notre modèle de menace est tel que toutes les données non cryptées peuvent être falsifiées par un attaquant sur le réseau.

Donc, si nous avons une sorte de code JavaScript non crypté qui s'exécute dans notre navigateur, nous devons supposer qu'il aurait pu être falsifié par un attaquant car il n'était pas crypté. Il ne s'est pas authentifié sur le réseau. Et, par conséquent, nous devons empêcher son interférence de toute page qui a été livrée via une connexion non cryptée.

Ainsi, le plan général est que pour cela, nous allons introduire un nouveau schéma d'URL, que nous appellerons HTTPS. Vous voyez souvent cela dans les URL. Le nouveau schéma d'URL est que maintenant ces URL sont simplement différentes des adresses HTTP. Donc, si vous avez une URL avec ce HTTPS: //, alors il a une source d'origine différente de celle des URL HTTP normales, car ces dernières passent par des correctifs non chiffrés, elles passent par SSL / TLS. De cette façon, vous ne confondrez jamais ces types d'adresses si la même stratégie d'origine fonctionne correctement.

C'est donc une pièce du puzzle. Mais vous devez également vous assurer de bien distinguer les sites cryptés les uns des autres, car pour des raisons historiques, ils utilisent des politiques de cookies différentes. Parlons donc d'abord de la façon dont nous distinguerons les différents sites chiffrés les uns des autres.

Le plan est que le nom d'hôte via l'URL soit le nom du certificat. En fait, il s'avère que les autorités de certification vont signer le nom d'hôte, qui apparaît dans l'URL comme nom de la clé publique du serveur Web. À ce titre, Amazon détiendrait un certificat pour www.amazon.com . Il s'agit du nom de notre table dont la clé publique correspond à leur clé privée.



C'est ce que le navigateur recherchera. Donc, s'il reçoit un certificat, s'il essaie de se connecter ou d'obtenir l' URL foo.com , cela signifie que le serveur représente avec précision le certificat foo.com authentique. Sinon, disons, nous avons essayé de contacter un gars et en avons contacté un autre, car il a un nom complètement différent dans le certificat auquel nous nous sommes connectés. Ce sera une incompatibilité de certificat.

Voici comment nous distinguerons différents sites les uns des autres: nous y apporterons l'autorité de certification pour nous aider à distinguer ces sites les uns des autres, car les autorités de certification promettent de n'émettre des certificats qu'aux bons membres du réseau. Cela fait donc partie de la même politique d'origine, selon laquelle nous divisons le code en parties. Comme vous vous en souvenez, les cookies ont une politique légèrement différente. Ils sont presque de la même origine, mais pas tout à fait, les cookies ont un plan légèrement différent. Les cookies ont un soi-disant indicateur de sécurité, Secure Flag. La règle est que si les cookies ont cet indicateur, ils ne sont envoyés qu'en réponse aux demandes HTTPS ou avec les demandes HTTPS. Les cookies avec et sans indicateur de sécurité sont liés les uns aux autres en tant que requêtes https et http.



C'est un peu compliqué. Ce serait plus facile si un cookie indiquait simplement qu'il s'agissait d'un cookie pour l'hôte HTTPS, et c'était un cookie pour l'hôte HTTP, et ils étaient complètement différents. Cela serait très clair pour isoler les sites sécurisés des sites non sécurisés. Malheureusement, pour des raisons historiques, les cookies utilisent ce type d'interaction étrange.

Par conséquent, si un cookie est marqué comme sûr, il ne s'applique qu'aux sites HTTPS, c'est-à-dire qu'il a l'hôte correct. Les cookies sécurisés s'appliquent uniquement aux URL d'hôte HTTPS, tandis que les cookies non sécurisés s'appliquent aux deux types d'URL, à la fois pour https et http, donc en une seconde, cela deviendra une source de problèmes pour nous.

Et la dernière touche que les navigateurs Web ont mise en place pour essayer de nous aider à cet égard est l'aspect de l'interface utilisateur dans lequel ils vont entrer une sorte d'icône de verrouillage pour que les utilisateurs puissent la voir. Ainsi, vous devez faire attention à l'icône de verrouillage dans la barre d'adresse du navigateur et à l'URL pour savoir sur quel site vous vous trouvez réellement.

Les développeurs de navigateurs Web s'attendent à ce que vous vous comportiez de cette façon: une fois que vous accédez à un site Web, vous regardez d'abord l'URL et assurez-vous qu'il s'agit du nom de l'hôte auquel vous souhaitez parler, puis vous trouverez l'icône de verrouillage et comprendre que tout va bien. Il s'agit d'un aspect de l'interface utilisateur du navigateur.

Mais cela ne suffit pas. Il s'avère que de nombreux sites de phishing incluent simplement l'image de l'icône de verrouillage dans le site lui-même, mais utilisent une URL différente. Et si vous ne savez pas quelle doit être l'adresse de ce site, vous risquez d'être trompé. En ce sens, ce côté de l'interface utilisateur est un peu déroutant, en partie parce que les utilisateurs eux-mêmes sont souvent confus. Il est donc difficile de dire ce qui se trouve ici. Par conséquent, nous nous concentrerons principalement sur le deuxième aspect, B, qui est certainement beaucoup plus facile à discuter. Vous avez des questions à ce sujet?



Étudiant: J'ai remarqué que certains sites passent au fil du temps de HTTP à HTTPS.

Professeur: oui, les navigateurs évoluent avec le temps, et cela est confirmé par le fait qu'ils obtiennent une icône de verrouillage. Certains navigateurs ne définissent une icône de verrouillage que si tout le contenu ou toutes les ressources de votre page sont également transmis via https. Ainsi, l'un des problèmes que HTTPS essaie de résoudre par la force est le contenu mixte ou les problèmes de types de contenu non sécurisés intégrés dans la page. Par conséquent, parfois, vous ne pourrez pas obtenir d'icône de verrouillage à cause de cette vérification. Si le navigateur Chrome considère que le certificat de site n'est pas assez bon et utilise une cryptographie faible, il ne vous donnera pas d'icône de verrouillage. Cependant, différents navigateurs agissent différemment, et si Chrome ne vous donne pas d'icône de verrouillage, Firefox le peut. Ainsi, encore une fois, il n'y a pas de définition claire de ce que signifie cette icône de verrou.

Voyons quels problèmes peuvent survenir lors de la mise en œuvre de ce plan. En HTTP standard, nous sommes habitués à compter sur DNS, qui devrait nous donner l'adresse IP correcte sur le serveur. DNS HTTPS URL-? DNS DNS?

: , , , IP-.

: , , , amazon.com.

: , - amazon.com, IP-.

: , , – - DNS . , DNS , . , DNS , IP-, . , - DNS- IP-? ?

: , HTTPS?

: , , .

: , HTTP URL.

: , HTTPS, .

: .

: , . . , CA, , , , - , .

, - https , - , , , , , , .

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

, , , . , amazon.com www.amazon.com , , , .

-, , , . , : „ , , , , ». , - , . .

, DNS, , , .

, , DNS, . , DNS-, SSL / TLS HTTPS, DNS . , DNS . DoS , , .

, — , ? , , ? , ?



: , - , . , .

: , , , , , , : « »! , , - , , , , . , .

: , .

: , . . , , , , , cookies, , URL-, , origin. , - amazon.com , , , , amazon.com. , amazon.com, , , , , , JavaScript .

, , -. , . - amazon.com «» . , amazon.com, , , , . . , , .

52:10

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


La version complète du cours est disponible ici .

Merci de rester avec nous. Aimez-vous nos articles? 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 fois moins cher? 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?