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

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

Je pense que l'application de HTTPS est due à la préoccupation des utilisateurs qui ont trop de latitude pour décider d'utiliser des certificats.

Un autre problème qui se manifeste dans la pratique et qui force également l'utilisation de HTTPS est une pièce jointe non sécurisée ou un contenu mixte sur une page Web. Le point de ce problème est qu'un site sécurisé ou n'importe quel site Web, d'ailleurs, peut incorporer d'autres éléments de contenu dans une page Web.

Donc, si vous avez une sorte de site Web, par exemple foo.com/index.html, alors il peut être servi en utilisant le protocole HTTPS, mais à l'intérieur de la page HTML, vous pouvez avoir de nombreuses balises qui forcent le navigateur à aller quelque part et à en faire partie Cette page a une sorte de contenu étranger.



La balise de ce scénario ressemble à ceci:

<script scr = «http://jquery.com/…”> 

Et pointe vers la source de jquery.com. Ainsi, la bibliothèque JavaScript populaire facilite l'interaction de nombreuses choses dans votre navigateur. Mais de nombreux développeurs Web ont simplement un lien vers l'URL d'un autre site. Cela facilite les choses, mais quel pourrait être le problème? Supposons que vous ayez un site sécurisé et que vous téléchargiez simplement jQuery à partir de là.

Étudiant: il pourrait s'agir de faux jQuery.

Professeur: oui, ça l'est. Il y a en fait deux façons d'obtenir la mauvaise chose que vous ne vous attendez pas à recevoir. Une possibilité est que jQuery lui-même puisse être compromis. Vous avez obtenu quelque chose de similaire à ce que vous avez demandé. Si jQuery est compromis, c'est très mauvais. Une autre possibilité est que cette demande soit envoyée sur le réseau sans chiffrement ni authentification. Par conséquent, si l'adversaire contrôle votre connexion réseau, il peut intercepter cette demande et vous envoyer un autre code JavaScript en réponse, et maintenant ce code JavaScript fonctionnera dans le cadre de votre page. Et puisqu'il travaille dans ce domaine HTTPS foo.com, il a accès à vos cookies protégés foo.com et à toute autre chose sur cette page. Cela semble être une très mauvaise chose, alors soyez prudent. Et le développeur web doit également faire attention à ne pas faire ce genre d'erreur.

Ainsi, l'une des solutions est d'assurer la sécurité de tous les contenus intégrés dans une page sécurisée. C'est une bonne ligne directrice à suivre pour de nombreux développeurs Web. Alors peut-être que vous devriez simplement utiliser jquery.com dans cette ligne au lieu de jquery.com . Ou si les URL prennent en charge la stratégie d'origine, cela signifie que vous pouvez omettre une partie du HTTPS et simplement dire que l'origine de ce script est //jquery.com/, c'est-à-dire scr = "//jquery.com / ..."



Et cela signifie que cette balise vous enverra sur jquery.com si elle se trouve sur la page HTTPS et sur jquery.com si elle ne se trouve pas sur HTTPS, mais sur une URL HTTP régulière. C'est une façon d'éviter un tel problème.

Cependant, les gens essaient constamment d'améliorer tout, donc l'une des façons alternatives de résoudre ce problème est peut-être d'inclure un hachage ou quelque chose comme un indicateur ici dans la balise:

 <script scr = «http://jquery.com/…”> 

Parce que si vous savez quel type de contenu vous souhaitez télécharger, vous n'avez probablement pas besoin de le télécharger complètement à l'aide du protocole HTTPS. En fait, peu vous importe qui vous fournit ce contenu tant qu'il correspond à un hachage spécifique.

Ainsi, il existe une nouvelle spécification qui vous permet de configurer des hachages pour des balises de ce type. Ainsi, au lieu de créer un lien vers jquery.com avec une URL HTTPS, vous pouvez simplement dire que la source du script est jquery.com ou même HTTP, mais à la fin du script, vous ajoutez une sorte d'attribut de balise, par exemple le hachage est égal à ce que vous espérons obtenir du serveur.



Etudiant: quel est le nom de cette spécification?

Professeur: il a un nom complexe, il se trouve dans les notes des notes de cours, quelque chose comme «l'intégrité des sous-ressources», l'intégrité des sous-ressources. Il est mis en œuvre assez lentement, mais j'espère que dans un proche avenir, il sera appliqué dans divers navigateurs. Ceci est similaire à une autre façon d'authentifier le contenu sans compter sur le chiffrement des données au niveau du réseau.

Ainsi, nous avons ce plan très général qui utilise SSL et TLS pour authentifier les connexions à un serveur spécifique. Il s'agit d'un autre moyen de protéger votre connexion réseau. Si vous vous souciez de l'intégrité, vous n'aurez peut-être pas besoin d'un canal réseau sécurisé et crypté. Tout ce que vous avez à faire est de spécifier exactement ce que vous voulez obtenir au final.

Étudiant: Ce code SRC ne vient-il pas du client?

Professeur: il travaille côté client, mais le client reçoit ce code d'un serveur.

Étudiant: quelqu'un ne peut-il pas simplement entrer son code JavaScript dans une page?

Professeur: Je pense que oui. Par conséquent, la signification du hachage est de protéger le contenu de la page contre les intrus qui tentent d'entrer un code JavaScript différent. Pour jQuery, cela est très important car jQuery est bien connu, car vous n'essayez pas de masquer le code source de jQuery. Par conséquent, vous voulez vous assurer qu'un attaquant du réseau ne peut pas intercepter votre connexion et insérer une version malveillante de jQuery, ce qui entraînera la fuite de cookies. Il est vrai que n'importe qui peut comprendre par lui-même le hachage de ces choses. Ainsi, c'est une solution aux problèmes d'intégrité, pas de confidentialité.

Je pense que les développeurs doivent garder un œil sur cela lorsqu'ils écrivent des pages ou incluent le contenu de leurs pages HTML dans les URL HTTPS. Une autre préoccupation que nous avons concerne les cookies. C'est là que la différence entre les cookies avec des indicateurs de sécurité et uniquement les cookies avec l'origine d'origine entre en jeu. La seule chose que le développeur peut gâcher ici est d'oublier simplement de mettre le drapeau sur les cookies en premier lieu, cela se produit. Peut-être ne pense-t-il qu'aux utilisateurs qui n'iront que sur l'URL HTTPS, et considère qu'il n'est pas nécessaire de définir des indicateurs. Est-ce un problème? Si vos utilisateurs sont très prudents et visitent toujours les URL HTTPS, il n'y a aucun problème. Pensez-vous qu'il est logique dans ce cas de laisser un indicateur de sécurité sur vos cookies?

Étudiant: est-il probable qu'un attaquant puisse se connecter à votre URL et vous rediriger vers un site malveillant?

Professeur: oui. Même si l'utilisateur n'accède pas explicitement manuellement à une URL en texte brut, l'attaquant peut toujours lui donner un lien vers un site non sécurisé ou lui demander de télécharger une image avec une URL autre que HTTPS. Ensuite, des cookies non sécurisés seront envoyés avec la demande de réseau. C'est donc un problème, et vous avez vraiment besoin d'un indicateur, même si vos utilisateurs et vos applications sont très prudents.

Étudiant: Je suppose qu'il existe des URL HTTP sécurisées.
Professeur: oui, c'est vrai. Supposons que j'ai un site Web qui n'écoute même pas sur le port 80 et qu'il n'y ait aucun moyen de me connecter via le port 80, alors pourquoi pourrait-il y avoir un problème si j'utilise des cookies non sécurisés?

Etudiant: car le navigateur ne pourra pas envoyer vos cookies vers un autre domaine.

Professeur: C'est vrai, le navigateur n'enverra pas de cookies vers un autre domaine, mais il y a toujours un risque qu'un attaquant puisse télécharger son URL. Supposons donc que amazon.com utilise uniquement SSL, il n'écoute même pas sur le port 80. Par conséquent, ils ne définissent pas leur indicateur de sécurité sur les cookies. Alors, comment un pirate peut-il voler ses cookies si Amazon n'écoute même pas sur le port 80?

Etudiant: le navigateur peut-il toujours penser qu'il s'agit d'une connexion HTTP?

Professeur: eh bien, si vous vous connectez au port 443 et utilisez SSL ou TLS, la connexion sera toujours cryptée, donc ce n'est pas un problème.

Étudiant: un attaquant pourrait intercepter la connexion.

Professeur: oui, un attaquant peut intercepter vos paquets qui tentent de se connecter à Amazon via le port 80, et prétendre que vous vous êtes correctement connecté au site. Donc, si un attaquant a le contrôle sur votre réseau, il peut rediriger vos paquets dirigés vers Amazon vers le port 80 de sa propre machine, et le client ne pourra pas voir la différence. Il semblera qu'Amazon écoutait sur le port 80, mais en réalité, vos cookies seront envoyés au serveur Web de ce pirate.

Étudiant: parce que le client est inconnu.

Professeur: C'est vrai, car HTTP n'a aucun moyen de vérifier l'authenticité de l'hôte auquel vous êtes connecté. C'est exactement ce qui se passe. HTTP n'a pas d'authentification. Par conséquent, si vous supposez qu'il y a un adversaire du réseau, vous devez d'abord empêcher l'envoi de vos cookies via HTTP, car vous ne savez pas à qui cette connexion HTTP ira.

Étudiant: pour cela, vous devez contrôler le réseau.

Professeur: oui, bien sûr. Si vous avez un contrôle total sur votre réseau, vous savez que les adversaires ne pourront pas intercepter vos paquets. Cependant, même avec un contrôle total sur le réseau, vous pouvez avoir des problèmes, regardez le matériel pour la conférence sur TCP, divers types d'attaques sur le réseau y ont été envisagés.

Public: Mais n'est-il pas possible dans ce cas d'empêcher une attaque de redirection?

Professeur: Le pirate informatique est susceptible d'intercepter la demande http du client sur amazon.com , et cette demande inclura tous vos cookies pour amazon.com, ou les cookies pour tout autre domaine auquel vous envoyez la demande. Par conséquent, si vous ne marquez pas ces cookies comme sûrs, ils peuvent être envoyés à la fois via une connexion cryptée et non cryptée.

Etudiant: comment cette demande est-elle initiée?

Professeur: vous pouvez peut-être amener l'utilisateur à visiter newyorktimes.com, où vous avez payé pour une annonce téléchargeant une image d' Amazon.com . Et il n'y a rien qui empêcherait l'utilisateur de demander: "veuillez télécharger l'image à partir de cette URL." Mais lorsque le navigateur essaie de se connecter au site, il enverra des cookies si la connexion a réussi.

Il existe une extension HTTPS Everywhere, très similaire à Force HTTPS, ou HTTPS forcé, et qui tente d'empêcher ce type d'erreur. Lorsque vous sélectionnez un site en mode HTTPS forcé, le navigateur empêche principalement toute connexion HTTP à cet hôte.



Ainsi, il n'y a aucun moyen de ne pas marquer vos cookies comme sûrs ou de commettre une erreur similaire. Si le développeur a oublié de définir un indicateur de sécurité sur les cookies, dans ce cas, la solution est évidente - il suffit de corriger son erreur. Mais il y a un problème plus délicat: lorsqu'un serveur Web sécurisé reçoit le cookie du client, il n'a aucune idée si ce cookie a été envoyé via une connexion cryptée ou en texte brut. Parce qu'en fait, le serveur ne reçoit que quelques valeurs clés pour le cookie.

Du plan d'action ci-dessus, il s'ensuit que lors de l'envoi d'une demande à un serveur sécurisé, le navigateur inclura à la fois des cookies sécurisés et non sécurisés, car pour sa part, il se soucie de leur confidentialité. Mais côté serveur, il n'y a aucune garantie de confidentialité, et lorsque le serveur reçoit des cookies utilisateur, ils peuvent être envoyés à la fois via une connexion cryptée et textuelle. Cela conduit à la possibilité d'attaques telles que la fixation de session.

Cela signifie qu'un attaquant, par exemple, souhaite voir quels e-mails vous envoyez. Pour ce faire, il vous déposera ses propres cookies, qui sont une copie des cookies de son compte Gmail. Et lorsque vous envoyez votre lettre, elle apparaîtra dans son dossier Éléments envoyés, et non dans votre dossier. Ce sera comme si vous utilisiez un compte attaquant, afin qu'il puisse extraire votre correspondance de sa boîte aux lettres. Donc, si un pirate met de force des cookies de session dans votre navigateur, il vous forcera à utiliser son compte. C'est donc un autre problème qui survient en raison de malentendus avec une séparation incomplète des cookies HTTP et HTTPS.

Étudiant: mais pour insérer vos cookies dans le navigateur de quelqu'un d'autre, vous devez y avoir une vulnérabilité.

Professeur: non, pour paramétrer votre cookie, la vulnérabilité n'est pas nécessaire. Vous incitez simplement le navigateur à se connecter à l'URL de l'hôte HTTP normal. Et si le navigateur n'a pas d'extension, comme Force HTTPS ou HTTPS Everywhere, vous, en tant qu'attaquant, pouvez définir la clé dans le navigateur de l'utilisateur. Il s'agit d'un cookie non sécurisé, mais il sera renvoyé, même pour des demandes sécurisées.

Etudiant: comment faire croire au navigateur que ce domaine est le même domaine?
Professeur: pour cela, vous devez intercepter la connexion réseau et effectuer l'un des types d'attaques dont nous avons parlé il y a quelques minutes.

Que fait réellement le HTTPS forcé? Il essaie de prévenir certains des nombreux problèmes. Des études sur le protocole Force HTTPS ont été publiées il y a 5 ou 6 ans. Depuis lors, il a été normalisé et effectivement adopté. Il ressemble à un plugin sommaire qui stocke certaines choses et certains cookies. Aujourd'hui, la plupart des développeurs de navigateurs pensent que sa création était une bonne idée. Il est préférable de l'intégrer directement dans le navigateur. Il existe quelque chose appelé HTTP Strict Transport Security, ou HSTS, un mécanisme pour forcer une connexion sécurisée via le protocole HTTPS. C'est un bon exemple de la façon dont la recherche scientifique affecte la sécurité des applications Web et des navigateurs.

Voyons ce que Force HTTPS fait pour un site Web. Le protocole HTTPS forcé permet à un site Web de définir ce bit pour un nom d'hôte spécifique, et trois éléments obligent le protocole HTTPS à affecter le comportement du navigateur.

La première est que toute erreur de certificat est toujours fatale. Ainsi, l'utilisateur n'a aucune chance d'accepter le mauvais certificat avec le mauvais nom d'hôte ou expiré, etc. C'est une chose qui change le navigateur.

La deuxième chose est que Force HTTPS redirige toutes les requêtes HTTP vers HTTPS. C'est une assez bonne idée. Si vous savez que le site utilise toujours légitimement HTTPS, vous devez probablement interdire toute demande HTTP régulière, car cela peut être le signe d'une sorte d'erreur ou la preuve qu'un attaquant tente de vous inciter à vous proposer de vous connecter au site sans chiffrement. . Vous voulez vous assurer que cela se produit réellement avant l'exécution de la demande HTTP, sinon toute demande HTTP irait déjà au réseau.

Et la dernière chose que Force HTTPS oblige le navigateur à faire est d'interdire le plan d'intégration non sécurisé que nous avons examiné précédemment - lorsque vous incorporez une URL HTTP dans un site HTTPS.



C'est donc ce que fait l'extension Force HTTPS. Sur la base de la terminologie utilisée aujourd'hui, le protocole HSTS fait de même. Désormais, la plupart des navigateurs par défaut interdisent l'incorporation non sécurisée. Cela a été controversé, car de nombreux développeurs ont eu des problèmes en raison de Force HTTPS, mais je pense que Firefox, Chrome et IE refuseront par défaut de charger des composants non sécurisés, ou du moins JavaScript et CSS non sécurisés dans votre page si vous faites-le mal.

Étudiant: ne demande-t-il pas à l'utilisateur la performance d'une action?

Professeur: ils sont habitués au fait que généralement l'utilisateur est d'accord. Par exemple, IE utilise une boîte de dialogue contextuelle qui vous demande si vous souhaitez télécharger du contenu supplémentaire, ou quelque chose comme ça. Je pense que si vous essayez, vous pouvez contourner toutes ces mesures de sécurité, mais je ne vous conseille pas de le faire. Ainsi, les navigateurs modernes essaient de résoudre certains des problèmes en utilisant Force HTTPS et HSTS.

Étudiant: que se passe-t-il lorsqu'un site ne prend pas en charge HTTPS?

Professeur: que voulez-vous dire?

Etudiant: que le navigateur ne se connectera pas au site via HTTPS.

Professeur: que se passe-t-il si vous avez un site Web qui ne prend pas en charge HTTPS mais définit ces cookies? Le fait est que si vous utilisez cette option dans votre navigateur, vous ne pourrez pas parler à la plupart des internautes, car ils n'utilisent pas HTTPS. Par conséquent, le navigateur devrait pouvoir communiquer via HTTPS avec les sites qui souhaitent vraiment une telle protection.

Etudiant: si je me souviens bien, vous ne pouvez pas paramétrer un cookie tant que le site ne le permet pas.

Professeur: oui, c'est vrai. Ces gars sont inquiets des attaques DoS, dans lesquelles ce plugin peut être utilisé pour causer des problèmes à d'autres sites. Par exemple, si vous définissez le bit Force HTTPS pour certains sites Web sans méfiance, ils cesseraient soudainement de fonctionner, car maintenant tout le monde essaierait de s'y connecter via HTTPS, qu'ils ne prennent pas en charge. C'est donc un exemple qui s'inquiète de la possibilité d'utiliser une attaque DoS en utilisant HTTPS forcé pour les sites qui ne comptent pas sur cela.

Une autre chose est que ce protocole ne prend pas en charge l'utilisation de Force HTTPS pour l'ensemble du domaine. Par exemple, je suis un utilisateur mit.edu qui a défini des cookies Force HTTPS dans tous les navigateurs, et maintenant seules les connexions HTTPS fonctionnent dans le MIT. Cela semble un peu catastrophique, vous devez donc probablement éviter une situation similaire.

D'un autre côté, le protocole HSTS y est revenu en disant que vous pouvez définir Force HTTPS pour l'ensemble du sous-domaine, car il s'avère utile pour les cookies non sécurisés envoyés avec la demande si vous ne savez pas d'où ils ont été envoyés. Il y a tout un tas de paramètres pour ces choses au niveau le plus bas, mais on ne sait toujours pas ce que signifie le bon choix dans ce cas.

Vous pourriez vous poser une question intéressante: ces améliorations sont-elles fondamentales ou visent-elles uniquement à aider les développeurs à éviter les erreurs? Supposons que vous ayez un développeur très responsable qui ne prenne pas de mesures dangereuses, mette à jour les certificats à temps, en rédige de nouveaux - doit-il utiliser Force HTTPS?

Etudiant: bien sûr, car rien n'arrêtera le pirate qui forcera l'utilisateur à télécharger quelque chose via HTTP, puis à intercepter la connexion.

Professeur: c'est vrai. Mais si vous pensez qu'il est très diligent et que tous ses cookies sont marqués comme sûrs, alors si quelqu'un visite la version HTTP de votre site, cela ne devrait pas poser de problème.



Cependant, vous devez probablement encore vous défendre contre l'écrasement des cookies ou les attaques par injection. C'est fatiguant, mais vous pouvez probablement y faire quelque chose.

Étudiant: Je pense que le développeur ne pourra en aucun cas vérifier l'authenticité du certificat, non?

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

: , , HTTP HTTPS, , , .

: , UI, - , . URL-. amazon.com, , , . HTTPS amazon.com, HTTP URL . , URL-, , amazonn.com amazon.com. . , Force HTTPS.



– Force HTTPS ? ?

: , .

: . , , Force HTTPS HTTPS . , . , Force HTTPS, , , HTTP, HTTPS. , HTTPS. , , HTTPS.

: Force HTTPS?

: , , , . , , , , , , , Force HTTPS .

, amazon.com Force HTTPS, , , , amazon.com, .



. DNSSEC. DNSSEC, , , , HTTPS Force HTTPS, DNS-. , DNSSEC, , , .

Google , . , Chrome , Force HTTPS. Chrome, , CRL Force HTTPS, . , , , . , Google, , , .

Bien sûr, actuellement, Google dit que tout site peut être inclus dans le navigateur, car la liste existante est très petite, mais si elle atteint des millions d'entrées, je suis sûr que Google cessera d'inclure tous les sites dans la liste des navigateurs. Mais maintenant, vous pouvez vraiment y ajouter votre domaine en envoyant simplement un e-mail aux développeurs Chrome et votre site sera répertorié dans Forcer les URL HTTPS.


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?