Qu'est-ce qui empêche quelqu'un de simplement rediriger une connexion HTTPS vers une version HTTP du site?
Supposons que quelqu'un effectue une usurpation d'identité ARP ou une attaque d'empoisonnement DNS pour rediriger le trafic vers son propre serveur Web. Si le site réel possède un certificat SSL/TLS, cela empêcherait-il le pirate de rediriger, disons google.com vers son propre serveur? Le serveur Web ne détermine-t-il pas s'il doit se connecter via HTTP ou HTTPS? Et la recherche DNS est effectuée avant de se connecter au serveur. Ne pourraient-ils pas simplement dire au client de se connecter via HTTP au lieu de HTTPS?
La décision d'utiliser HTTP ou HTTPS appartient au client.
Si l'utilisateur accède directement à http://example.com, un attaquant pourrait simplement Détourner cette connexion et effectuer une attaque homme-au-milieu. Si l'utilisateur accède directement à https://example.com, l'attaquant doit usurper la connexion SSL/TLS d'une manière ou d'une autre; cela sans montrer à l'utilisateur un avertissement de certificat non valide nécessite que l'attaquant ait accès à la clé privée d'une autorité de certification. Cette situation ne devrait jamais se produire. Sans cela, le navigateur de l'utilisateur rejetterait la connexion, ne permettant pas à l'attaquant de rediriger.
Dans le cas de Google et d'un certain nombre d'autres sites Web, ils ont défini l'en-tête HTTP Strict Transport Security (HSTS), ce qui oblige le navigateur de l'utilisateur à mettre en cache une règle disant qu'il ne devrait jamais visiter le site via HTTP en texte brut, même si l'utilisateur le demande ou Google lui-même redirige vers une URL HTTP. Le navigateur réécrira automatiquement l'URL en HTTPS ou bloquera entièrement la demande. Cela empêche également l'utilisateur de cliquer sur un avertissement de certificat dans la plupart des navigateurs; l'option n'est tout simplement pas là.
Non, la recherche DNS ne dit pas au client s'il doit se connecter via HTTP ou HTTPS. Le navigateur décide que - si vous entrez une URL HTTP, il demandera sans TLS sur le port 80, et si vous entrez une HTTPS, il demandera avec TLS sur le port 443. C'est donc le client, et non le serveur, qui décide.
Si le serveur reçoit une demande sur un protocole, il ne préfère pas qu'il puisse émettre une redirection en répondant avec un code d'état 300 et un en-tête d'emplacement. Cependant, si la demande d'origine est sur HTTPS, l'homme du milieu aurait besoin d'un certificat valide pour pouvoir envoyer cette réponse. Et s'il l'avait, il ne serait pas nécessaire de rediriger vers HTTP en premier lieu.
Tout d'abord, je pense que la principale chose que l'OP a manqué est que la négociation SSL/TLS se produit en premier. Seule APRÈS une connexion sécurisée est négociée et validée, il peut y avoir une communication HTTP. HTTPS est un gros abus de langage, c'est juste votre ancien HTTP simple envoyé uniquement via SSL/TLS complètement indépendant.
Si le site réel possède un certificat SSL/TLS, cela empêcherait-il le pirate de rediriger, disons google.com vers son propre serveur?
Les certificats sont vérifiés et TLS est établi avant tout HTTP. Avec un faux certificat, la connexion ne sera jamais établie en premier lieu. Pas de place pour les redirections.
Le serveur Web ne détermine-t-il pas s'il doit se connecter via HTTP ou HTTPS?
Non, c'est le client. En ouvrant le socket et en envoyant la requête HTTP en texte brut, ou en ouvrant le socket, en effectuant une négociation SSL/TLS complète, puis en envoyant la requête HTTP.
Et la recherche DNS est effectuée avant de se connecter au serveur.
Oui, mais le client vérifie le certificat par rapport au nom DNS. Donc, je peux DNS vous usurper en venant à moi au lieu de Google, mais j'aurai toujours besoin d'un certificat délivré à google.com
Ne pourraient-ils pas simplement dire au client de se connecter via HTTP au lieu de HTTPS?
Non, ils n'ont jamais la chance de faire ça.
S'il vous arrive d'avoir une autorité de certification qui validera tous les certificats pour n'importe quel domaine, c'est quand vous avez un énorme problème. Avant que les navigateurs épinglent les certificats uniquement pour les domaines qui les intéressent, tout le monde doit dépendre du fait que les autorités de certification ne se comportent pas mal, c'est pourquoi il existe un référentiel de certificats SSL assemblés avec lequel vous pouvez vérifier si cela change de l'usurpation d'identité. Ou plutôt il devrait y en avoir.