La maggior parte dei siti di e-commerce utilizza SSL / TLS quando si desidera effettuare il log. Ma la maggior parte ha homepage usando solo http. È sufficiente avere SSL / TLS nella pagina di accesso e nella pagina registrata per evitare sslstrip?
La maggior parte dei siti di e-commerce utilizza SSL / TLS quando si desidera effettuare il log. Ma la maggior parte ha homepage usando solo http. È sufficiente avere SSL / TLS nella pagina di accesso e nella pagina registrata per evitare sslstrip?
Il controllo dell'uso corretto di HTTPS è in definitiva la sola responsabilità dell'utente. Gli utenti devono guardare almeno 3 punti quando visitano una pagina Web:
Per utilizzare HTTPS correttamente è necessario rispondere a queste 3 domande.
Non abilitare HTTPS sulla pagina iniziale non è necessariamente la fine del mondo. Questa pagina potrebbe essere vulnerabile agli attacchi SSLStrip, ma non è necessario trasferire in sicurezza ciò che si trova su quella pagina.
La maggior parte dei siti web può avere una semplice pagina di benvenuto HTTP, se non altro per eseguire un reindirizzamento a HTTPS o inviare il primo intestazione HSTS . Questo potrebbe essere vulnerabile a SSLStrip in questa fase, ma è necessario che ci sia un punto di partenza se l'utente non sa cosa aspettarsi (e la maggior parte userà per prima cosa URL http:// ). I reindirizzamenti automatici possono (solo) mitigare il rischio . L'unico modo per farlo è che l'utente sappia che funzionerà solo il https:// URI o che il sito faccia parte di l'elenco HSTS precaricato .
(Nessun sito Web è protetto contro SSLStrip se l'utente o il browser non si aspetta l'utilizzo di HTTPS. Questa aspettativa può essere attivata automaticamente nel browser tramite HSTS, sia attraverso una prima visita da una rete in cui l'attacco non ha t ha luogo, o tramite la lista precaricata.)
No. La mancanza di HTTPS nella home page non impedisce SSLStrip. Se una qualsiasi delle connessioni viene trasmessa in formato testo (ad es. HTTP), può essere sniffata e la sessione potrebbe essere potenzialmente dirottata. È necessario utilizzare HTTPS per tutte le pagine che devono essere protette e utilizzare intestazioni HSTS .
Ogni volta che gli utenti visitano per la prima volta una pagina http: sul Web (a differenza di un file locale o di una pagina su un server locale), c'è il rischio che un proxy HTTP malevolo modifichi https: link a entrambi:
http: links https: link a un altro sito web, con un nome simile (example-login.com anziché example.com) Qualsiasi banca con una pagina principale http: che si collega a una pagina di accesso https: non comprende la sicurezza , punto e basta.
La banca dovrebbe capire che fornire un server "sicuro" (server HTTPS) non è sufficiente, un utente ragionevole responsabile dovrebbe essere in grado di collegarsi a questo server in tutti i casi. (Un utente che segue i collegamenti nelle e-mail è per definizione irragionevole.)
Ci si può aspettare che un utente ricordi (o annota) il nome di dominio principale della sua banca ( one nome di dominio), per non conoscere ogni altro dominio che la sua banca potrebbe usare per qualsiasi scopo . Aggiungi il fatto che molti utenti non capiscono la natura gerarchica del DNS, quindi non possono riconoscere che secure-login.mybank.com è un sottodominio di mybank.com ma mybank.secure-login.com, mybank-secure-login. com e secure-login-mybank.com non lo sono. Non sono stupidi, semplicemente ignorano i principi di base del DNS e non sono disposti a imparare questi aspetti tecnici. Non ci si può aspettare che gli utenti riconoscano che un nome di dominio è legittimo a meno che non conoscano esattamente questo nome di dominio completo.
L'utente deve essere garantito per arrivare nel posto giusto solo con semplici regole semplici. Le regole "negative", come "controlla che, fermati se rilevi un problema" sono difficoltà ad applicare in modo coerente:
Un altro problema è che nel mondo fisico, gli oggetti falsi possono essere riconosciuti perché tendono ad essere una cattiva imitazione di quelli reali, e molte caratteristiche sono oggetti fisici sensibili alla sicurezza (banconote, carte di credito) progettati per essere molto difficili per imitare, e la nostra intuizione è allenata a guardare le proprietà dell'oggetto per rilevare le imitazioni. Quando si tratta di sito Web, questa intuizione è completamente sbagliata: l'imitazione di una pagina web sembra altrettanto buona dell'originale - infatti, è l'originale , bit di bit ( e anche la legge porta la confusione che fare copie illegali è la stessa cosa che fare un'imitazione).
Quando si tratta di un sito Web falso (e-commerce, ISP, social ...), solo l'URL (l'indirizzo) sarà diverso. La pagina di accesso sarà esattamente la stessa (a meno che il truffatore non sia incompetente, cosa che succede anche).
Inoltre, siamo stati addestrati all'idea che potrebbero esistere banconote false, non banche false.
OTOH, una regola "positiva" come "inserisci questo URL" è impossibile da dimenticare, perché se la dimentichi, il tuo browser (di solito) non va da nessuna parte. Quindi se un giorno il tuo browser visita un sito web che assomiglia al tuo sito web (e-commerce, ISP, social ...) e non hai inserito l'URL corretto, sai che qualcosa non va (almeno estremamente sospetto) .
Quindi, in pratica, poiché l'utente non è un robot , la procedura consigliata sicura dovrebbe idealmente consistere solo di regole positive. Il browser è un robot, quindi dovrebbe implementare tutte le regole negative (SSL / TLS ha un mucchio di regole negative).
Leggi altre domande sui tag http tls sslstrip http-proxy