Une connexion HTTPS peut-elle être compromise en raison d'un serveur DNS voyou
Si je visitant (juste un ordinateur de bureau, un côté client), un site qui possède une connexion HTTPS/connexion valide, qui peut être compromis si j'utilise un serveur Rogue DNS (non délibérément, je suis préoccupé par une attaque sur le service DNS)?
Je pense à E.g.: Le site de CA (pour vérifier la connexion HTTPS) est résolu par mon serveur de noms (le compromis)?
Afin de vous connecter à n'importe quel site Web, via HTTPS ou non, vous avez besoin de l'adresse IP du site et vous demandez à votre serveur DNS à l'aide du nom de domaine de votre site. Si votre serveur DNS n'a pas mis en cache la réponse, il essaiera de résoudre votre demande en posant une série complète de serveurs DNS (le serveur DNS racine, le gestionnaire de domaine de niveau supérieur ... jusqu'à ce que le serveur DNS soit autorisateur pour le domaine) .
Un attaquant qui contrôle l'un de ces serveurs peut vous répondre avec une fausse adresse IP pour ce site Web, et c'est ce que votre navigateur essaiera de visiter. Cette adresse IP dans l'affaire Général aura une réplique du site Web hébergé, afin de le rendre identique à celle de l'original, ou d'agir simplement comme un transitaire silencieux de votre connexion au site correct après avoir capturé ce qu'il a besoin.
Maintenant, à plus de détails: Si le site Web est protégé HTTPS, il y aura de nombreux pièges. Le site Web normal aura un certificat émis qui lie les détails du nom de domaine sur le site Web, mais cela est effectué à l'aide d'un cryptage asymétrique.
Cela signifie que grâce au processus de la poignée de main SSL, le site Web doit prouver qu'il a une connaissance de la clé privée associée à la clé publique du certificat. Maintenant, la partie malveillante peut très bien vous servir le certificat original du site Web lorsque vous essayez d'accéder à la mauvaise adresse IP sous le nom d'hôte correct, mais il n'aura pas connaissance de la clé privée afin que la poignée de main SSL ne fonctionne jamais.
Mais il y a des moyens pour l'intercepteur de faire tout le travail, je peux penser à quatre:
1) La solution la plus simple consiste à vous servir un certificat auto-signé au lieu d'une normale. Cela sera émis par l'attaquant lui-même. Normalement, votre navigateur vous avertira à ce sujet et si vous exécutez une récente version de navigateur, les avertissements seront déplacés partout, mais les utilisateurs ont tendance à cliquer sur ce genre de choses.
2) Une autre approche, utilisée dans les attaques de Stuxnet, consiste à voler les clés privées utilisées pour un certificat valide de l'organisation que vous souhaitez imiter.
3) Une autre solution, qui s'est produite dans quelques cas (nous ne parlons pas de l'attaquant moyen ici) est qu'il exploite une faute de la procédure d'enregistrement que l'utilisation des autorités de certification (ou des autorités d'enregistrement) et parvient à émettre un certificat Pour un site Web qui ne lui appartient pas. Il y a eu des cas que RAS n'a tout simplement pas fait assez de chèques et délivré des certificats pour Google.com ..
4) Semblable à ce qui précède: un attaquant compétent "hacks" un certificat ou une autorité d'enregistrement et parvient à émettre certains certificats sous le nom de son nom qu'il souhaitait. Cela s'est passé en mai 2011 (le célèbre Comodo-Hack) et juillet 2011 (le piratage Diginotar). Voir plus de détails sur Quelle est la réalisabilité pour un CA d'être piraté? Quels certificats racines de confiance par défaut dois-je supprimer? - Sécurité informatique .
5) Enfin, la Tecnique la plus effrayante est celle que trois organismes de lettres et des partis similaires peuvent utiliser: Si un gouvernement contrôle une autorité de certification, en théorie, il peut forcer à émettre des certificats à volonté, pour n'importe quel site. Pensez maintenant que les autorités de certification sont diffusées dans le monde entier, certains étant dans des pays où cela peut sembler très possible. L'AC opéré par la Société Emirates Telecommunications (Etisalat), dont 60% appartenant au gouvernement des Émirats arabes unis (Émirats arabes unis). Etisalat a une fois déployé un patch Blackberry anodineux à la recherche de logiciels espions dans des appareils de rebord, permettant une surveillance de l'e-mail.
De plus, si le client prend toujours en charge l'ancien protocole SSL 2.0, un MITM peut rétrograder la connexion SSL et utiliser soit un algorithme de cryptage symétrique plus faible, soit un échange de clé plus faible.
Donc, pour résumer, si l'attaquant contrôle le serveur DNS, il peut faire des choses très malveillantes, mais pour intercepter le trafic crypté SSL, il a besoin de quelque chose de plus que cela.
Et pour répondre à votre dernière question: le site de l'autorité de certification n'a pas besoin d'être résolu chaque fois que vous visitez un site: le site Web vous sert généralement le certificat public qu'il utilise, mais il est possible que vous l'obtiens à la place de l'autorité de certification. Cela ne change aucune des choses mentionnées ci-dessus.
En plus de l'excellente réponse de @ John, un serveur Rogue DNS peut causer d'autres dommages, en plus de tout effet sur la connexion HTTPS actuelle (bien que cela soit strictement en dehors du cadre de votre question, je pense que c'est toujours pertinent). Il y a des types de dommages qu'il peut faire, en plus d'essayer d'écouter de l'écoute de votre connexion actuelle.
Si vous demandez à un serveur DNS malveillant de résoudre les adresses pour vous, il peut vous donner des réponses que vous n'avez pas demandé, affectant ainsi toutes les autres connexions que vous créez - même après avoir cessé d'utiliser le DNS Rogue .
Par exemple. Utilisation Techniques d'empoisonnement DNS . (Voir aussi ma réponse à cette question .)
En outre, le DNS malveillant peut vous rediriger volontairement sur un autre serveur, par exemple. Un serveur de victime qui sera maintenant inondé par de fausses demandes.
Outre tout cela, qui vous garantit réellement faire la connexion SSL? La plupart des utilisateurs ne prennent pas la peine de taper "aich tee tee pee ESS(!) colon whack whack... "... Ils formeront simplement le nom de domaine (par exemple "MyBank") et appuyez sur CTRL + Entrée, ou demandez au moteur de recherche, ou. .. et dans tous ces cas, il est probable que la demande initiale de l'utilisateur ne soit même pas du tout https. (Bien sûr, si vous do Tapez-le spécifiquement, c'est différent, donc YMMV sur ce point).
Je suggère également de jeter un coup d'œil à certaines des réponses à "Ce qui est impliqué dans la prise en charge du nom de domaine de quelqu'un d'autre?"
Certains procurations corporatives (qui fonctionnent via la redirection DNS ou une variété d'autres moyens) peuvent inspecter le contenu d'une connexion SSL. De plus, les utilisateurs d'un bureau géré ne recevront pas d'avertissement de navigateur si le certificat MITM a été installé dans le magasin local.
Selon qui gère le proxy et comment ses journaux sont utilisés, cela peut être acceptable ou une mauvaise chose de votre point de vue.
Pour plus d'informations sur la manière dont l'interception SSL est effectuée, voir ceci Link :
Lorsque le proxy SSL intercepte une connexion SSL, elle présente un certificat de serveur émulé au navigateur client. Le navigateur client émet une pop-up de sécurité à l'utilisateur final, car le navigateur ne fait pas confiance à l'émetteur utilisé par le proxyssg. Cette fenêtre contextuelle ne se produit pas si le certificat émetteur utilisé par SSL proxy est importé comme une racine de confiance dans le magasin de certificats du navigateur client.
Le proxysg rend tous les certificats configurés disponibles au téléchargement via sa console de gestion. Vous pouvez demander aux utilisateurs finaux de télécharger le certificat d'émetteur via Internet Explorer ou Firefox et l'installer en tant que CA de confiance dans son navigateur de choix. Cela élimine le contexte du certificat pour les certificats émulsés ...
Il y a une attaque mélangée qui tromperait la plupart des gens http://www.h-online.com/security/news/item/black-hat-new-ways-a-attack-sssl-740173.html
L'attaquant agit comme un homme au milieu et établit un lien non crypté vers la victum qui montre http: // ... dans le navigateur, mais le cadenas est réglé et vert de sorte que les gens manquent le manque de https: // ...
Son hautement improbable, sauf si vous cliquez pour permettre un certificat suspect; Autre que le piratage d'un navigateur mal configuré ou ancien avec SSL faible, c'est un ordre assez élevé. Ils pourraient avoir une base de données massive d'adresses IP de contenu mixtes utilisées sur des sites Web principaux communs qui résolvent à des adresses non sécurisées qui utilisent Java, des polices ou d'autres fichiers potentiellement dangereux et tout ce qui existe avec un contenu malveillant; Par conséquent, pourquoi désactiver le contenu mixte est une excellente idée ESP dans ces jours-ci.
Dans votre cas, la question est non, la connexion HTTPS ne peut pas être compromise.
Maintenant, découvrons pourquoi.
Votre navigateur a des clés publiques de la ca. Clés publiques de confiance.
En supposant que l'attaquant ne soit pas seulement capable de contrôler le DNS, mais aussi les serveurs eux-mêmes, dans ce cas, à la fois des serveurs HTTP CA et des serveurs HTTP ciblés.
L'attaquant ne peut pas simuler l'AC car il n'a pas correspondant aux clés privées correspondant à votre navigateur.
L'attaquant ne peut pas non plus simuler le serveur HTTP, car son certificat n'aura pas d'estampillé d'une ca.
Dans le cas extrême que l'attaquant puisse obtenir un certificat pour le domaine qu'il ne contrôle pas/possède, le point précédent est invalide. Et l'attaquant peut faire tout ce que son imagination peut évoquer. La chose est que cela viole notre très hypothèse que l'autorité de certification est conviviale! C'est la faute de l'AC qui accorde l'attaquant un tel certificat. Et quand CA n'est plus fiable, SSL n'est qu'un tigre de papier.