2010-01-03 11 views
7

Quindi hai eseguito il login usando https per prevenire gli attacchi man in the middle e assicurati che la tua password non venga inviata in chiaro. Buona chiamata Ma molti siti tornano a http per il resto della sessione.Sta eseguendo il login con https, ma poi tutto in http è un po 'inutile?

Una volta scambiato tutto in chiaro non può un uomo nel mezzo iniziare a dirottare di nuovo la sessione? Ok, quindi non hanno la tua password ma non ne hanno bisogno! Per tutto il tempo in cui rimani connesso, l'uomo nel mezzo può semplicemente dirottare la sessione e inviare qualsiasi richiesta desideri. Non possono?

Quali misure vengono messe in atto per impedirlo? O in realtà non è un problema a causa di qualcosa che ho trascurato? O è solo un rischio accettabile da prendere?

+1

IMO, solo che tutto in HTTPS. La crittografia non è certo un compito costoso –

+0

@Jeffrey, in un sito affollato come Google, ad esempio, il sovraccarico di SSL può sommarsi a molto. La maggior parte dei siti non avrà quel problema anche se – Glen

+0

c'è un sacco di persone che non sono d'accordo con il fatto che la crittografia costa poco! – Matthew

risposta

3

Dipende da cosa intendi per inutile. :) Sei corretto che in una configurazione standard, in cui stai creando una sessione su HTTPS, e poi ritornando a HTTP ma passando un cookie di sessione (diciamo) in giro con le tue richieste, che il teorico "ragazzo nella caffetteria" possa in effetti vedi i tuoi dati e/o intraprendi azioni per tuo conto.

Lo svantaggio dell'utilizzo di tutto-SSL (HTTPS) è tradizionalmente costoso da un punto di vista del lato server oltre che dal calcolo del lato client. (Dollari e server per il sito, pagine a caricamento più lento per voi.)

Pertanto, la maggior parte di un sito in chiaro è stato tradizionalmente considerato un "rischio accettabile" per la maggior parte degli usi del web.

I due rischi che si incontrano sono la possibilità che i dati siano visibili agli altri e che altri possano agire come te (utilizzando i cookie, che possono rubare). Quando progetti un nuovo sito, dovresti pensare ai rischi relativi di entrambe queste cose. Si noti che le istituzioni finanziarie serviranno sempre tutte le loro pagine su HTTPS perché il rischio non è accettabile, ogni pagina contiene dati sensibili e persino l'intercettazione è errata. Gmail offre un'opzione di attivazione per ottenere anche HTTPS per tutte le sessioni. (Facebook, tuttavia, non lo è, ad esempio Yahoo! Mail).

Probabilmente avrete notato che molti siti che funzionano principalmente su HTTP proteggeranno le modifiche critiche delle impostazioni con la re-autenticazione della password. Questo è uno dei motivi per cui lo fanno: anche se il ragazzo nel coffee shop può leggere i tuoi post di Facebook che passano, non può cambiare la tua password e bloccarti senza conoscere la tua password corrente.

Filosoficamente, la mia ipotesi è che nel corso del tempo un numero crescente di servizi con dati utente privati ​​sarà sottoposto a pressioni per passare a (o offrire) all-HTTPS man mano che le persone vengono a conoscenza dei rischi e dell'utilizzo delle reti Wi-Fi pubbliche.

+0

"incorrere nel calcolo del lato client" Mentre tecnicamente vero, dubito che il sovraccarico della crittografia possa fare una differenza per il cliente. Se si utilizza un sito Web, le prestazioni sono quasi sempre limitate dal throughput di rete e dal momento che la velocità effettiva di tutti i moderni codici simmetrici è superiore di qualsiasi ordine di grandezza anche a una rete veloce, non ci dovrebbe essere un ulteriore rallentamento. Un processore moderno può facilmente decodificare AES a 50+ MiB/s; Dubito che la tua rete sia così veloce :-). – sleske

-1

Se la tua stretta di mano https includeva lo scambio di una chiave segreta, un uomo nel mezzo può essere teoricamente impedito di fare del male, trasferendo le considerazioni sulla sicurezza dal livello di trasporto al livello dell'applicazione.

Ad esempio, le parti potrebbero includere un numero di sequenza di messaggi e una firma digitale utilizzando la chiave condivisa. Ciò impedirebbe la riproduzione di messaggi, la manomissione del messaggio esistente e la creazione di messaggi falsi.

+0

Non vedo come, se tutto il resto è fatto su testo in chiaro? – ZoFreX

+0

concordato. non c'è molto che tu possa fare con una chiave segreta una volta tornato nel mondo in chiaro del http. – Matthew

+0

In teoria: una volta che hai lasciato le comunicazioni sicure, hai lasciato comunicazioni sicure. – yfeldblum

-2

È possibile far sì che tutte le richieste provengano dallo stesso indirizzo IP da cui è stata eseguita l'autenticazione. Questo renderebbe il dirottamento molto più difficile, penso. Parecchi siti fanno questo, o hanno l'opzione.

+0

un uomo nel mezzo potrebbe spoofare il suo indirizzo IP. concesso, non avrebbe ricevuto alcuna risposta, ma poteva ancora inviare le sue richieste. – Matthew

+0

, in realtà, se è davvero "in mezzo", può ottenere anche le risposte. – SpliFF

+0

Ho preso dalla domanda che lo scopo dell'attacco era quello di prendere il controllo della sessione, come nel compiere azioni, non semplicemente vedere cosa sta succedendo che è ovviamente banale. – ZoFreX

2

I siti che si preoccupano così poco della sicurezza da non utilizzare SSL in modo coerente rischiano di essere insicuri in molti modi. Ad esempio, probabilmente hanno il modulo di login stesso consegnato su una pagina non criptata.L'utente malintenzionato può semplicemente modificare la destinazione del post del modulo https su un non criptato e ora ha la tua password.

Una volta entrato in scambio tutto in chiaro non può un uomo in mezzo iniziare il dirottamento di nuovo la sessione?

Sì.

È come bloccare la porta di casa senza pareti esterne.

, anche se il ragazzo nel negozio di caffè può leggere i tuoi post di Facebook che passava, non può modificare la password e bloccare fuori senza conoscere il vostro attuale password di

Può assumere il tuo cookie di sessione? Può cambiare il tuo indirizzo email? Può richiedere una e-mail di reimpostazione della password? Può farti dire cose stupide nei forum pubblici? Probabilmente.

Lui certamente può sostituire ogni link https su ogni pagina con http. Google per "SSLStrip". Più che probabile, la vittima non finirà mai più su una pagina https. Quindi, quando la vittima fa clic sul link "cambia la mia password", l'utente malintenzionato ottiene le vecchie (e nuove) password in chiaro.

  • Marsh
Problemi correlati