Sto configurando un nuovo server web. Oltre a TLS / HTTPS, sto considerando l'implementazione di Strict-Transport-Security e altri meccanismi di applicazione HTTPS.
Tutti sembrano essere basati sul presupposto che sto scontando http://www.example.com oltre a https://www.example.com . Perché non utilizzo solo HTTPS? Cioè, esiste un motivo basato sulla sicurezza per servire HTTP - ad esempio, qualcuno potrebbe spoofare http://www.example.com se non si imposta HSTS?
Why don't I just serve https only?
I motivi principali sono il comportamento predefinito dei browser e retrocompatibilità .
Quando un utente finale (cioè senza conoscenza dei protocolli o della sicurezza) digita l'indirizzo del sito Web nel proprio browser, il browser utilizza per impostazione predefinita HTTP. Vedi questa domanda per ulteriori informazioni sul perché i browser scelgono questo comportamento.
Pertanto, è probabile che gli utenti non possano accedere al tuo sito web.
È possibile che alcuni utenti con vecchi sistemi e vecchi browser non supportino HTTPS o più probabilmente, non abbiano un database aggiornato di certificati radice , o non supportano alcuni protocolli.
In tal caso, non saranno in grado di accedere al sito Web o avranno un avviso di sicurezza. Devi definire se la sicurezza dei tuoi utenti finali è abbastanza importante da forzare HTTPS.
Molti siti web ascoltano ancora HTTP ma reindirizzano automaticamente a HTTPS e ignorano gli utenti con i vecchi vecchi browser.
could someone spoof http://www.example.com if I don't set up HSTS?
Se un utente malintenzionato vuole spoofare http://www.example.com , deve assumere il controllo del dominio o assumere il controllo dell'indirizzo IP in qualche modo.
Suppongo che intendessi: un attaccante potrebbe eseguire un attacco man-in-the-middle?
In tal caso sì, ma anche con o senza HSTS:
Senza HSTS : un utente malintenzionato può facilmente trovarsi nel mezzo del server e dell'utente e deve essere attivo (ad esempio, modificare il contenuto) o passivo (ad esempio, origliare)
con HSTS : la prima volta che un utente tenta di visitare il sito utilizzando HTTP, un utente malintenzionato potrebbe costringere l'utente a utilizzare HTTP. Tuttavia, l'attaccante ha una finestra temporale limitata in cui può eseguire il suo attacco.
Come molti siti Web, è necessario consentire le connessioni HTTP e fare in modo che il server reindirizzi l'utente alla versione HTTPS. In questo modo sostituisci il comportamento predefinito dei browser e assicurati che gli utenti utilizzino la versione HTTPS.
I vecchi sistemi senza i protocolli oi certificati di root appropriati non saranno in grado di accedere al sito (o almeno avranno un avvertimento), ma a seconda della base di utenti questo non dovrebbe essere un problema.
Farà più male che bene a disabilitare HTTP. In realtà non fornisce più sicurezza.
Qualsiasi sicurezza aggiunta per proteggere una risorsa è inutile se impedisce alla maggior parte dei suoi utenti di accedervi. Se i tuoi utenti finali non possono accedere al tuo sito Web perché il loro browser è impostato su HTTP e tu non ascolti le connessioni HTTP, qual è il vantaggio?
Esegui semplicemente il reindirizzamento HTTP 301 alla versione HTTPS.
Per motivi di usabilità devi offrire un reindirizzamento a HTTPS da tutti gli URL HTTP: s. Altrimenti, i visitatori che per la prima volta inseriscono semplicemente example.com/some/page nella barra degli indirizzi del browser verranno accolti da un errore di connessione.
La pubblicazione del reindirizzamento non ti rende più vulnerabile. Gli utenti che non hanno la tua voce HSTS nei loro browser effettueranno comunque una richiesta HTTP. Indipendentemente dal fatto che esista o meno un servizio reale o meno su HTTP, è irrilevante per un uomo nel mezzo.
Quindi è necessario eseguire un server HTTP, ma non è necessario rispondere con nient'altro che i reindirizzamenti.
Le risposte up-votate sono molto buone. Sacrificerai l'usabilità senza un impatto significativo sulla sicurezza se spegni completamente HTTP.
Tuttavia, è possibile attenuarlo con l'opzione Precarico HSTS. Il precaricamento del tuo sito web significa che registri il tuo dominio con i fornitori di browser e che codificheranno i loro browser per visitare il tuo sito web solo tramite HTTPS. Ciò significa che se un utente tenta di accedere al tuo sito web tramite HTTP, il browser modificherà la richiesta in HTTPS. L'utente non ha bisogno di prima ottenere l'intestazione HSTS prima di essere sicuro. Si connetteranno sempre a te tramite un canale sicuro.
Ora questo non protegge gli utenti che utilizzano browser che non hanno aggiornato il proprio elenco di siti Web HTTPS. Anche quando utilizzo il preloading, ti consiglio di non spegnere HTTP per le poche persone che utilizzano browser vecchi o non aggiornati.
Ma attenzione, il pre-caricamento è permanente! È estremamente difficile rimuovere l'elenco di precaricamento.
Per accedere all'elenco di precarichi: link
Non devi.
Alcuni browser e sistemi operativi meno recenti (che di solito vanno di pari passo) non dispongono di nuove autorità di certificazione dei certificati, ma in genere non supportano gli standard HTTPS più recenti, quindi nulla è realmente perso.
Potresti avere un dispositivo che non supporta HTTPS, script personalizzati, ecc.
Nessuno può spoofare HTTP, perché il record DNS appartiene a te e il record A punta al tuo indirizzo IP specifico (in un mondo perfetto).
Lo fai solo per mantenere la compatibilità, il gioco è fatto.
Dovresti supportare HTTP solo per supportare la retrocompatibilità. Assicurati di eseguire correttamente il reindirizzamento nel server back-end su HTTPS. Il modo migliore per implementare questo è fornire il supporto HTTP solo alla tua home page o qualsiasi pagina che non ha informazioni sensibili. Non devi supportare le richieste HTTP alle pagine a cui l'utente può accedere dopo l'autenticazione.
Anche se ci sono dispositivi (IoT) che accedono ai dati sensibili del tuo server, devi obbligarli a usare TLS (molti dispositivi attuali possono archiviare il tuo certificato e creare una connessione TLS). Tieni presente che le versioni SSL precedenti alla 3.0 hanno molte vulnerabilità come poodlebug, ecc. Quindi, disabilita tutte le versioni precedenti dal tuo server Web e consenti solo a > TLS 1.1.
È positivo implementare l'HSTS. Ti consiglio di dare un'occhiata alla possibilità di implementare HPKP anche sul tuo sito.
Uso http oltre a https per due scopi:
Un grosso motivo a volte non è richiesto HTTPS, ad esempio serve repository open source.
Perché proteggere un po 'di streaming quando tutti sono pubblici? per esempio, guarda il repository cygwin, tutti sono in forma semplice.
Ciò non significa che l'HTTPS non funzioni, non sacrifica l'elaborazione client e server quando non è realmente necessario.