Pourquoi est-il possible de renifler une requête HTTPS / SSL?
Je suis nouveau dans le domaine des demandes et de la sécurité HTTP et de toutes ces bonnes choses, mais d'après ce que j'ai lu, si vous voulez que vos demandes et réponses soient chiffrées, utilisez HTTPS et SSL, et vous serez bon. Quelqu'un dans une question précédente a posté un lien vers cette application http://www.charlesproxy.com/ qui montre qu'il est effectivement possible de renifler les requêtes HTTPS, et de voir le demande et réponse en texte PLAIN.
J'ai essayé cela avec la connexion facebook.com, et j'ai en effet pu voir mon nom d'utilisateur ET mon mot de passe en texte clair. C'était aussi facile. Que se passe-t-il? Je pensais que c'était tout l'intérêt de HTTPS - pour crypter les demandes et les réponses?
Ceci est expliqué dans leur page sur proxy SSL , peut-être pas avec suffisamment d'explications.
Un proxy est, par définition, un man-in-the-middle : le client se connecte au proxy et le proxy se connecte au serveur.
SSL fait deux choses:
- Il garantit la confidentialité et l'intégrité de la connexion établie.
- Il vérifie à qui vous vous connectez.
C'est la deuxième partie qui est importante et apparemment cassée ici: vous êtes assis devant votre navigateur et surpris que votre navigateur se connecte au proxy alors que vous vous attendiez à ce qu'il se connecte à Facebook. Techniquement, le proxy ne renifle pas le trafic HTTPS, il le relaie.
Votre navigateur sait qu'il est connecté à Facebook car le site a un certificat qui dit "Je suis vraiment www.facebook.com ”. Cryptographie à clé publique , ce qui signifie que je n'entrerai pas ici, garantit que seul le détenteur de la clé privée peut établir une connexion valide avec ce certificat. Ce n'est que la moitié de la bataille: vous avez seulement la prétention du serveur que c'est vraiment www.facebook.com et pas randomhijacker.com. Votre navigateur vérifie en outre que le certificat a été validé par autorité de certification . Votre navigateur ou système d'exploitation est accompagné d'une liste d'autorités de certification auxquelles il fait confiance. Encore une fois, la cryptographie à clé publique garantit que seule l'autorité de certification peut émettre des certificats que votre navigateur acceptera.
Lorsque vous vous connectez au proxy, votre navigateur reçoit un certificat indiquant "Je suis vraiment www.facebook.com ”. Mais ce certificat n'est pas signé par une autorité de certification à laquelle votre navigateur fait confiance par défaut. Donc:
- soit vous avez reçu un avertissement concernant une connexion HTTPS non sécurisée, sur laquelle vous avez cliqué pour voir le contenu à
https://www.facebook.com/; - ou vous a ajouté l'autorité de certification qui a signé le certificat du proxy ("le certificat de l'autorité de certification de Charles") à votre liste des autorités de certification approuvées par votre navigateur.
Dans tous les cas, vous avez demandé à votre navigateur de faire confiance au proxy. Il en est ainsi. Une connexion SSL n'est pas sécurisée si vous commencez à faire confiance à des étrangers aléatoires.
Lecture recommandée pour plus d'informations:
- quand est-il sûr de cliquer sur un message d'avertissement SSL?
- Est-ce qu'une connexion SSL établie signifie qu'une ligne est vraiment sécurisée
- SSL avec GET et POST
- Comment puis-je vérifier que j'ai une connexion SSL directe à un site Web?
- https empêche-t-il l'homme au milieu des attaques par serveur proxy?
- Comment est-il possible que des personnes observant une connexion HTTPS en cours d'établissement ne sachent pas comment la décrypter?
- Comment les utilisateurs finaux peuvent-ils détecter les tentatives malveillantes d'usurpation SSL lorsque le réseau dispose déjà d'un proxy SSL autorisé?
Vous ne pouvez pas casser https à moins d'avoir accès à la clé symétrique de la session . En bref, les sessions https fonctionnent de cette façon:
- Le client et le serveur échangent des informations initiales
- En utilisant ces informations, le client est en mesure d'authentifier le serveur , en s'assurant qu'il vaut la confiance
- Le client utilise la clé publique du serveur pour lui envoyer un secret crypté
- Le serveur déchiffre ce secret à l'aide de sa clé privée (seul le serveur authentifié peut le faire!)
- Le client et le serveur utilisent le secret pour générer localement la clé symétrique de session
- Maintenant, ils peuvent se parler en toute sécurité car personne d'autre ne connaît leur clé symétrique de session
Si certains avancent en cours de route, un tiers peut accéder au secret partagé, il sera également en mesure de générer la clé symétrique de session et de décrypter la communication.