Attenuazione di SSLStrip semplicemente servendo un sito su HTTPS?

Sì, senza ulteriori misure, l'attaccante può ancora eseguire SSLStrip. Per far funzionare SSLStrip, l'utente malintenzionato deve essere solo un uomo nel mezzo, non correlato al suo comportamento rispetto all'HTTP. Su una richiesta HTTP in arrivo, l'utente malintenzionato apriva una connessione HTTPS al server reale e "elimina" il protocollo SSL dall'HTTPS. Quindi, non ci sarebbe alcuna comunicazione HTTP tra l'attaccante e il server. Anche se il comportamento HTTP del server sembra irrilevante, è meglio per ulteriori attenuazioni disabilitare HTTP o creare un reindirizzamento permanente.

Quando offri solo HTTPS e sei sicuro di voler utilizzare HTTPS in futuro, puoi attenuare parzialmente utilizzando HTTP Strict Transport Security (HSTS) per comunicare agli utenti di servire solo HTTPS. Ciò mitigherà SSLStrip per tutti gli utenti dal momento in cui si connettono almeno una volta senza essere attaccati.

Puoi raggiungere la piena mitigazione per Firefox e Chrome richiedendo di aggiungerti a un HSTS whitelist . Firefox e Chrome presumono che HTTPS utilizzi i siti web in tale whitelist, ma un requisito per essere presenti in tale elenco è l'invio dell'intestazione HSTS. Ulteriori informazioni sull'applicazione di qui .

If your site only serves content over HTTPS and hard fails on HTTP requests, with no redirect, are you still vulnerable?

Se l'utente inserisce accidentalmente http://example.com nella barra degli indirizzi anziché https://example.com , sslstrip potrebbe ancora intercettare la connessione e ingannare l'utente.

Questo potrebbe anche essere vero per i seguenti link dannosi dell'utente - se non si accorgono che il lucchetto mancante nella barra degli indirizzi potrebbero essere vulnerabili.

Sicurezza di trasporto rigorosa HTTP può proteggersi da questo se stai inviando l'intestazione, ma solo se l'utente ha ha precedentemente visitato il tuo sito su HTTPS utilizzando quell'istanza particolare se il suo browser o se hai richiesto che i fornitori di browser includano il tuo sito nell'elenco HSTS precaricato. Nota che IE non supporta ancora HSTS .

Un'altra cosa da notare che se non sei che segna i cookie come sicuri , un utente malintenzionato potrebbe essere in grado di MITM qualsiasi altra richiesta HTTP da parte della vittima e inietta una richiesta per la versione non sicura del tuo sito (ad esempio aggiungendo <img src="http://example.com/mitm.jpg"/>checonsentiràquindiaMITMeventualicookieperiltuosito.SinoticheancheHSTSproteggeràcontroquesto.

Inoltre, se ci sono delle vulnerabilità XSS sul tuo sito dal rendering dei valori dei cookie, è possibile che un utente malintenzionato usi un Attacco MITM per iniettare script dannosi qui a meno che HSTS non sia attivo. Ciò è possibile anche se si impostano cookie sicuri - il server non può distinguere quali cookie sono sicuri quando li legge (riceve solo i valori) in modo che non sappia se l'autore dell'attacco ha manipolato qualcosa durante un attacco MITM su una qualsiasi connessione HTTP a il tuo server.

Ho coperto un po 'di terreno con quanto sopra, espandendo quello che hai chiesto, tuttavia questi sono tutti i tipi di attacco che possono essere utilizzati anche se non stai ascoltando su un semplice HTTP sul lato server.

Can an attacker intercept your HTTPS request and perform the request "on your behalf", so-to-speak, and serve your browser an HTTP version

Se si accede direttamente a un sito HTTPS (ad esempio da un segnalibro), un attacco MITM SSLStrip sarebbe altamente improbabile. La richiesta potrebbe non riuscire a causa del browser in cerca di un handshake TLS, o richiedere un errore di certificato se l'utente malintenzionato utilizza un certificato falso.

Ora, se si impone questo sul lato server, non è sempre possibile fare affidamento sul server per reindirizzare HTTP a HTTPS poiché questo reindirizzamento potrebbe essere intercettato.

Inoltre, se accedi alla pagina tramite un collegamento ipertestuale da una fonte non criptata, sarai anche vulnerabile a SSLStrip. So che la tua domanda non è stata rivolta specificamente a queste ultime due situazioni, ma volevo solo menzionarle per essere esaurienti. Ci sono modi per mitigare questi ultimi attacchi usando HSTS.

Con HSTS , il server dice a un client Web di utilizzare solo HTTPS. Finché la prima richiesta al sito viene eseguita senza modifiche, tutte le successive visite al sito saranno costrette a utilizzare SSL / TLS. Ciò funzionerebbe per impedire a SSLStrip di funzionare su un collegamento ipertestuale da un sito Web non protetto, poiché anche se https:// è stato modificato in http:// , il browser sa utilizzare solo https:// .

Come parte dell'attacco sta facendo un MITM per tutto il traffico TCP / UDP delle vittime, a patto che l'utente non usi esplicitamente un indirizzo https, potrebbe essere ingannato.

Ad esempio: se una vittima tenta di andare a "mail.google.com" e si fida del reindirizzamento automatico, Google fa da http a https (provalo tu stesso), e non controlla la barra degli indirizzi. icona / barra verde / altro, un utente malintenzionato che ha già eseguito il MITM otterrà tutto il traffico da quel sito in testo non crittografato.

Tuttavia, esiste una nuova intestazione HTTP che può essere inclusa in tutte le risposte del server che è stata progettata per ridurre al minimo le possibilità di subire un tale attacco se il client si è connesso correttamente all'HTTPS almeno una volta prima (e usa un browser Web moderno che lo supporta):

Strict-Transport-Security

link

Per un server Apache includere questa intestazione in tutte le risposte:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

NOTA: se hai entrambe le versioni HTTP e HTTPS del tuo sito web, non appena il client ottiene quell'intestazione dal tuo server, non sarà in grado di connettersi alla versione HTTP (fino cancella i cookie o utilizza un browser diverso o (forse) utilizza la navigazione privata)