Per motivi di usabilità è necessario offrire un reindirizzamento a HTTPS da tutti gli URL HTTP: s. In caso contrario, i visitatori per la prima volta che inseriscono semplicemente example.com/some/page nella barra dell'URL del browser verranno accolti da un errore di connessione.

Fornire il reindirizzamento non ti rende più vulnerabile. Gli utenti che non hanno la tua voce HSTS nei loro browser faranno comunque una richiesta HTTP. Che ci sia o meno un servizio reale su HTTP è irrilevante per un uomo nel mezzo.

Quindi è necessario eseguire un server HTTP, ma non ha bisogno di rispondere con nient'altro che i reindirizzamenti .

Perché non servo solo https?

I motivi principali sono il comportamento predefinito dei browser e la compatibilità con le versioni precedenti .

Comportamento predefinito

Quando un utente finale (cioè, senza conoscenza dei protocolli o della sicurezza) digita l'indirizzo del sito Web nel proprio browser, il browser utilizza HTTP di default. Vedi questa domanda per ulteriori informazioni sul motivo per cui i browser scelgono questo comportamento.

Pertanto, è probabile che gli utenti non saranno in grado di accedere al tuo sito web.

Compatibilità con le versioni precedenti

È 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 veramente vecchi browser.

qualcuno potrebbe falsificare http://www.example.com se non imposto HSTS?

Se un utente malintenzionato desidera falsificare http://www.example.com , deve assumere il controllo del dominio o assumere il controllo dell'indirizzo IP in qualche modo.

Presumo che intendessi: un attaccante può 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 al centro del tuo server e dell'utente ed essere attivo (cioè, modificare il contenuto) o passivo (cioè, intercettare)

• 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 di tempo limitata in cui può eseguire il suo attacco.

Cosa dovresti fare?

Come molti siti web, dovresti consentire le connessioni HTTP e fare in modo che il tuo server reindirizzi l'utente alla versione HTTPS. In questo modo sovrascrivi il comportamento predefinito dei browser e assicurati che i tuoi utenti utilizzino la versione HTTPS.

I vecchi sistemi senza i protocolli appropriati o i certificati di root non saranno in grado di accedere al sito (o almeno avranno un avviso ), ma a seconda della base di utenti questo non dovrebbe essere un problema.

Conclusione

Disabilitare HTTP farà più male che bene. 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 è predefinito su HTTP e tu non ascolti le connessioni HTTP, qual è il vantaggio?

Esegui semplicemente il reindirizzamento HTTP 301 alla versione HTTPS.

Domande correlate

• Perché per impostazione predefinita i browser sono http: e non https: per gli URL digitati?
• Perché HTTPS non è il protocollo predefinito?
• Perché non si dovrebbe usare SSL?
• Perché alcuni siti web impongono la mancanza di SSL ?

Le risposte votate sono molto buone. Sacrificherai l'usabilità senza un grande impatto sulla sicurezza se disattivi completamente HTTP.

Tuttavia, puoi mitigarlo con l'opzione HSTS Preload. Il precaricamento del tuo sito web significa che registri il tuo dominio con i fornitori di browser 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 ottenere prima l'intestazione HSTS prima di essere protetto. Si connetteranno sempre a te su un canale sicuro.

Ora questo non protegge gli utenti che utilizzano browser che non hanno aggiornato il loro elenco di siti Web solo HTTPS. Anche quando si utilizza il precaricamento, consiglio di non disattivare HTTP per le poche persone che utilizzano browser vecchi o non aggiornati.

Ma attenzione, il precaricamento è permanente! È estremamente difficile uscire dall'elenco di precaricamento.

Per accedere all'elenco di precarichi: https://hstspreload.org/

Non è necessario.

Alcuni browser e sistemi operativi meno recenti (questi di solito vanno di pari passo) non dispongono di autorità radice dei certificati più recenti, ma di solito non supportano HTTPS più recenti anche gli standard, quindi nulla va davvero perso.

Potresti avere un dispositivo che non supporta HTTPS, script personalizzati, ecc.

Nessuno può falsificare 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.

È necessario supportare HTTP solo per supportare la compatibilità con le versioni precedenti. E assicurati di eseguire il reindirizzamento corretto nel server back-end su HTTPS. Il modo migliore per implementare ciò è fornire il supporto HTTP solo alla tua home page o qualsiasi pagina che non contenga informazioni sensibili. Non è necessario 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 forzarli a utilizzare TLS (molti dispositivi attuali possono memorizzare 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> TLS 1.1.

È bene implementare l'HSTS. Ti consiglio di dare un'occhiata alla fattibilità di implementare HPKP anche sul tuo sito.

Uso http oltre a https per due scopi:

1. Reindirizza http al sito web https. Questo è per se qualcuno digita il nome del tuo sito nel browser.
2. Creo un sito web separato per http che è per se qualcuno cerca di accedere al sito web senza usare il nome punto com. (Un utente reale non lo farà.) Questo sito web mostrerà un semplice messaggio Prossimamente. Aggiungerà anche il loro indirizzo IP all'elenco di negazione delle tabelle IP per escludere permanentemente quell'IP dal server. Questo arresta rallenta gli hacker che utilizzano masscan. (Ho trovato masscan memorizzando le stringhe dell'agente utente di tutti gli IP che stavo bloccando per dimostrare a un altro programmatore che non era la scansione di Google, ma in realtà, hacker stranieri che eseguivano la scansione dell'IP alla ricerca di server web per tentare di hackerare).