Forzare l'intero sito https senza reindirizzare http a https

14

Ci sono state molte discussioni mentre stavo cercando come rendere il mio intero sito https. La maggior parte delle risposte è stata quella di reindirizzare http su https (file .htaccess), il che non va bene, perché non è bene fare lo stesso lavoro due volte (due richieste). Inoltre, "man in the middle" prende prima http e voglio che il mio sito vada direttamente su https. C'è un altro modo per rendere https tutto il tuo sito e come farlo? Ad esempio, quando l'utente digita example.com, quell'esempio.com passa automaticamente a https, senza prima reindirizzare da http o altro?

http  https 
— Marko Tamburic
fonte
se non vuoi che le persone vengano reindirizzate su https, cosa vuoi che accada invece?
— Michael Hampton
@MichaelHampton Forse sto facendo una domanda da principiante, ma voglio praticamente "eliminare" http, e l'unica cosa che esiste è https. O se questo non è possibile, potrei semplicemente usare il reindirizzamento se è abbastanza buono per la sicurezza. Ho sentito che il reindirizzamento http-> https non è così buono perché è ancora http e il traffico può essere intercettato durante il reindirizzamento.
— Marko Tamburic,
Il reindirizzamento permanente HTTP 301 è tuo amico, non dimenticare di impostare la scadenza.
— Marcel,
Puoi semplicemente rimuovere http. Ma poi, l'utente riceve solo un messaggio di rifiuto della connessione, se non sta inserendo https: // Per alcuni siti questo è meglio, perché la sicurezza è maggiore. Se è disponibile una versione http, può accadere che i cookie vengano inviati con la prima richiesta non crittografata. Per cose come un sistema di posta aziendale solo https + la formazione degli utenti è ok, per un sito generale probabilmente perderai molti visitatori.
— Josef dice di ripristinare Monica
Dopodiché è diventato possibile con HTTP2, tuttavia non eviterà ancora l'attacco di striping ssl (descritto nelle risposte di seguito).
— Peter - Ripristina Monica il

Risposte:

22

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security consente al tuo server di indicare che il dominio dovrebbe essere accessibile solo tramite HTTPS. Questo vale solo per le richieste successive, quindi ci sarebbe un carico HTTP iniziale, ma le richieste future caricerebbero HTTPS anche se qualcuno digitasse esplicitamente HTTP.

IE non lo supporta ancora, ma tutte le altre major lo fanno.

— ceejayoz
fonte
Non protegge ancora dalla prima richiesta.
— Jenny D,
3
@JennyD Ho già detto esattamente questo nella mia risposta.
— Ceejayoz,
@JennyD Cosa intendi con "proteggere"? Un MiM non può fare nulla contro un reindirizzamento http -> https, a meno che non stiano scherzando con il DNS / routing locale e fingendo l'intero dominio. In tal caso, non importa cosa fai, dato che i tuoi server non sono mai accessibili.
— Avviso rosso
2
@JennyD Bene, HSTS è davvero una soluzione migliore del tuo post, che dice "un reindirizzamento è il modo di farlo". Un reindirizzamento può essere MITMed in qualsiasi momento. Un reindirizzamento con HSTS può essere MITMed solo una volta all'anno per utente + browser (o qualunque sia il tempo di scadenza nell'intestazione) - tutte le altre volte non è richiesto.
— Ceejayoz,
1
@MarkoTamburic Nessun motivo per cui non puoi unire i due.
— Ceejayoz,
7

Come altri hanno già detto, non è possibile forzare gli utenti a scegliere il protocollo giusto. Ma quando l'utente tenta di utilizzare HTTP, cosa dovresti fare? Anche un reindirizzamento non è sufficiente, perché un utente malintenzionato seduto tra te e il client può intercettare il reindirizzamento, quindi il client non lo vede mai. Il client continuerà a inviare un semplice HTTP e l'attaccante eliminerà il livello SSL dal server ( attacco di stripping SSL ).

L'unico modo sicuro per impedirlo è di non servire affatto HTTP . Non rispondere sulla porta 80, tranne forse per servire una pagina di testo semplice che indichi all'utente di riprovare con HTTPS (ma non fornisce un collegamento che l'utente malintenzionato potrebbe manipolare). Ciò costringerà l'utente a digitare https://nel proprio browser, quindi avvierà la connessione con SSL e impedirà l'attacco MITM.

— Andrew Schulman
fonte
3
È un compromesso, tuttavia, poiché la maggior parte degli utenti non sta per digitare https://. Invece, diranno "eh, il sito è rotto" e se ne andranno. Lo scenario migliore potrebbe essere la www.example.comrisposta a HTTP e HTTPS, ma l'app stessa è in esecuzione su qualcosa di simile admin.example.comsolo con HTTPS.
— Ceejayoz,
Concordato. In pratica, quasi nessuno lo fa.
— Andrew Schulman,
Non vedo davvero come sarebbe più a prova di MiM. Se l'uomo nel mezzo può modificare il tuo collegamento ipertestuale per puntare altrove, significa che ha il controllo dei pacchetti in arrivo dell'utente. Può anche reindirizzare facilmente al suo sito o aggiungere qualsiasi collegamento ipertestuale che desidera, indipendentemente da come dovrebbe essere il sito.
— Avviso rosso
Ma non, in teoria, se il client avvia la connessione con SSL.
— Andrew Schulman,
3
è vero, ma se il client si avvia con SSL, OP non ha problemi. Il suo problema è quando si avviano senza SSL e non c'è modo di portarli in modo affidabile se c'è un MiM che lo sta sabotando attivamente.
— Avviso rosso
1

ceejayoz ha la migliore risposta per prevenire l'attacco specificamente menzionato qui, ma voglio anche sottolineare ciò che manca a un sacco di gente qui, fondamentalmente che HTTP ha già capito l'altra parte. Vuoi fare un reindirizzamento permanente 301. Questo dice al cliente di effettuare ulteriori richieste al nuovo indirizzo. Quindi sì, se qualcuno digita l'URL sbagliato, farà 2 richieste MA, in futuro, un buon cliente dovrebbe rilevare le richieste a quell'URL ed effettuare invece la richiesta corretta per evitare ulteriori richieste sprecate. Il problema è che questo è solo per quell'URL esatto. HSTS migliora questo schema dicendo anche che "per i successivi n secondi non consentono connessioni non sicure da questo dominio".

Gli utenti non devono visitare siti sensibili in luoghi non sicuri. In particolare, non dovrebbero registrarsi per loro in luoghi non sicuri. Si tratta di principi di base per la sicurezza degli utenti che dovrebbero essere insegnati proprio come "non aprire allegati da fonti non attendibili". Quali sono davvero la risposta migliore per prevenire attacchi MiM per siti che non sono mai stati visitati.

Come nota a margine, alcuni browser migliorano questo affermando anche che alcuni siti noti usano sempre HSTS. Sfortunatamente, non puoi semplicemente aggiungerti facilmente a questo elenco.

Ulteriori letture: http://coderrr.wordpress.com/2010/12/27/canonical-redirect-pitfalls-with-http-strict-transport-security-and-some-solutions/

http://dev.chromium.org/sts

— krowe
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.