Domanda:
Perché dovrei offrire HTTP oltre a HTTPS?
lofidevops
2017-04-18 18:00:56 UTC
view on stackexchange narkive permalink

Sto configurando un nuovo server web. Oltre a TLS / HTTPS, sto valutando l'implementazione di Strict-Transport-Security e altri meccanismi di applicazione di HTTPS.

Questi sembrano tutti essere basati sul presupposto che io sia che offre http://www.example.com oltre a https://www.example.com . Perché non offro solo HTTPS? Cioè, c'è un motivo basato sulla sicurezza per servire HTTP: ad esempio, qualcuno potrebbe falsificare http://www.example.com se non imposto HSTS?

i non browser possono avere molti più problemi a recuperare il contenuto, se questo è un problema.Siti come Craigslist prosperano sui mashup, ad esempio.non vedo il danno nel lasciare aperte alcune sezioni http, per "utenti" non umani;non si preoccupano di phishing, xss o privacy e non è nemmeno necessario fornire HTML ...
@dandavis - è davvero un problema?Se Craigslist andasse solo su HTTPS, non convertiresti tutti i loro script di recupero in HTTPS?La maggior parte delle librerie client HTTP include il supporto HTTPS.
In che modo le persone dovrebbero diffondere FUD sul fatto che HTTPS sia poco pratico se esegui un sito solo HTTPS senza problemi?Pensa, amico!E i poveri hacker che vogliono attaccare le nonne che non hanno sentito parlare di HTTPS ovunque?È come se stessi cercando di promuovere un Web più sicuro o qualcosa del genere.
@Johnny: non supporta tanto infra quanto http, tutto qui.andrà meglio...
@dandavis Questo è qualcosa che mi lascia perplesso ... tutti i principali browser dovrebbero iniziare a provare https * prima * http ... questo risolverebbe un sacco di problemi di sicurezza ...
Sei risposte:
#1
+161
Anders
2017-04-18 18:58:32 UTC
view on stackexchange narkive permalink

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 .

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/57580/discussion-on-answer-by-anders-why-should-i-offer-http-in-addition-to-https).
#2
+69
Ronny
2017-04-18 18:44:48 UTC
view on stackexchange narkive permalink

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

Mi riferivo al punto in grassetto "With HSTS", dove la dicitura suggerisce che c'è meno sicurezza se il server serve un reindirizzamento da HTTP a HTTPS.
@BenVoigt Oh ok capisco.Ho rimosso il "Se servi HTTP" per evitare malintesi.Grazie
Inoltre, alcuni utenti potrebbero non essere in grado di accedere ai siti `https`.Ad esempio, la Cina ha precedentemente bloccato tutto il traffico https verso i progetti Wikimedia.
Solo una correzione per la scelta della parola: l'utente non inserisce un "URL", ma un "indirizzo web".(Non esiste uno schema / protocollo predefinito.)
@OskarSkog Ho cambiato in "indirizzo del sito web", grazie.
Nota che per "With HSTS", HSTS precaricato in realtà proteggerà anche i visitatori del tuo sito per la prima volta dagli attacchi MITM.
#3
+20
Taul
2017-04-18 23:40:49 UTC
view on stackexchange narkive permalink

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/

Quale problema si risolverebbe uscendo dall'elenco di precarico?Voglio dire, perché qualcuno dovrebbe volerlo?(Sto facendo una domanda tecnica; non retorica. La mia comprensione è che vorrebbero smetterla solo se decidessero di * interrompere * il servizio HTTPS per qualche motivo, giusto?)
@Wildcard che è corretto.Un caso d'uso a cui potrei pensare è che se un dominio è stato registrato dalla persona X, lo lasciano scadere o altrimenti trasferiscono il dominio alla persona Y. Ora la persona Y è costretta a usare https anche se potrebbe non volerlo per qualsiasi motivo come il costo, limitazioni tecniche con il loro creatore di siti Web drag and drop, ecc.
@Erik, grazie.Da una prospettiva di progettazione a lunghissimo termine, quindi, sospetto che il precaricamento HSTS sia permanente per * scelta deliberata *, con l'obiettivo finale di * completamente * deprecare http in pratica, in modo che i browser più diffusi richiedano di passare attraverso "impostazioni avanzate"menu anche per abilitarlo.Almeno possiamo sognare.:)
@Wildcard Sono d'accordo che probabilmente è l'obiettivo.Mi chiedo quale accadrà prima a Internet tramite IPv6 per impostazione predefinita o solo https?;) Entrambi sono necessari ma sono una battaglia in salita ...
Scott Hemle ha delle ottime informazioni su questo.Si prega di leggere la sua pagina del blog su questo: https://hpkp.scotthelme.co.uk/death-by-copy-paste/ In breve, Scott fornisce tre ragioni.1) non considerare gli effetti su tutti i sottodomini che gestisci 2) non considerare gli effetti su tutti i sottodomini che permetti a terze parti di gestire.3) copia / incolla le configurazioni dell'intestazione per includere il precaricamento (e poi qualcuno registra il tuo sito con o senza il tuo permesso).
#4
+5
Root
2017-04-18 18:05:02 UTC
view on stackexchange narkive permalink

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.

"Nessuno può falsificare http" - Intendi "Nessuno può" o "Tutti possono"?"il record DNS appartiene a te e il record a punta al tuo indirizzo IP specifico" - In base a questo ragionamento, gli attacchi man-in-the-middle non si verificano mai, quindi non sono necessarie autorità di certificazione e catena di fiducia.
"Nessuno può falsificare http, perché il record DNS appartiene a te" - Vero.A meno che qualcuno non falsifichi la voce DNS, nel qual caso può essere falsificata.
#5
+3
user3496510
2017-04-18 22:12:54 UTC
view on stackexchange narkive permalink

È 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.

#6
  0
Russell Hankins
2017-04-22 01:19:21 UTC
view on stackexchange narkive permalink

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).


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...