Cosa impedisce a qualcuno di reindirizzare semplicemente una connessione HTTPS a una versione HTTP del sito?

La decisione se utilizzare HTTP o HTTPS è quella del client.

Se l'utente va direttamente a http://example.com , un utente malintenzionato potrebbe semplicemente dirottare quella connessione ed effettuare un attacco man-in-the-middle. Se l'utente va direttamente a https://example.com , allora l'attaccante deve in qualche modo spoofare la connessione SSL / TLS; facendo così senza mostrare all'utente un avviso di certificato non valido richiede che l'utente malintenzionato abbia accesso alla chiave privata dell'autorità di certificazione. Questa situazione non dovrebbe mai accadere. In caso contrario, il browser dell'utente rifiuterà la connessione, non consentendo al reindirizzatore di eseguire il reindirizzamento.

Nel caso di Google e di altri siti Web, impostano l'intestazione HTTP Strict Transport Security (HSTS), che fa in modo che il browser dell'utente memorizzi nella cache una regola che dice che non dovrebbero mai visitare il sito tramite testo in chiaro HTTP, anche se l'utente lo richiede o se Google stesso reindirizza a un URL HTTP. Il browser riscriverà automaticamente l'URL su HTTPS o bloccherà completamente la richiesta. Ciò impedisce inoltre all'utente di fare clic su un avviso di certificato nella maggior parte dei browser; l'opzione semplicemente non è lì.

No, la ricerca DNS non dice al client se dovrebbe connettersi tramite HTTP o HTTPS. Il browser decide che - se si inserisce un URL HTTP che richiederà senza TLS sulla porta 80, e se si inserisce uno HTTPS, esso richiederà con TLS sulla porta 443. Quindi è il client, e non il server, che decide.

Se il server riceve una richiesta su un protocollo, non preferisce che possa emettere un reindirizzamento rispondendo con un codice di stato di 300 e un'intestazione di posizione. Tuttavia, se la richiesta originale è su HTTPS, l'uomo nel mezzo avrebbe bisogno di un certificato valido per poter inviare quella risposta. E se avesse avuto questo, non ci sarebbe stato bisogno di reindirizzare a HTTP in primo luogo.

Prima di tutto penso che la cosa più importante che OP abbia mancato è che la negoziazione SSL / TLS avvenga prima. Solo AFTER connessione sicura è negoziata e convalidata, ci può essere qualsiasi comunicazione HTTP. HTTPS è un termine improprio, è solo il tuo semplice vecchio HTTP inviato solo su SSL / TLS completamente indipendenti.

If the real site has an SSL/TLS certificate, would that stop the hacker from redirecting let's say google.com to their own server?

I certificati vengono controllati e TLS viene stabilito prima che avvenga qualsiasi HTTP. Con il certificato errato, la connessione non verrà mai stabilita in primo luogo. Nessuno spazio per i reindirizzamenti.

Doesn't the web server determine whether to connect via HTTP or HTTPS?

No, il client lo fa. Aprendo socket e inviando richieste HTTP in testo normale o aprendo socket, eseguendo la negoziazione SSL / TLS completa e quindi inviando la richiesta HTTP.

And DNS lookup is done before they connect to the server.

Sì, ma il client controlla il certificato rispetto al nome DNS. Quindi posso DNS spoofarti per venire da me invece di Google, ma mi servirà comunque un certificato emesso a google.com

Couldn't they just tell the client to connect via HTTP instead of HTTPS?

No. Non hanno mai la possibilità di farlo.

Se ti capita di avere un'autorità di certificazione che convalida qualsiasi certificato per qualsiasi dominio, è quando hai un grosso problema. Prima del blocco dei certificati da parte dei browser effettuati solo ai domini di cui sono interessati, tutti gli altri devono dipendere dal fatto che le CA non si comportano in modo errato, motivo per cui esiste un repository di certificati SSL con cui è possibile verificare se cambia dallo spoofing. O meglio dovrebbe esserci.