In che modo un login HTTPS è sicuro quando le pagine utilizzano HTTP?

Potresti non averlo notato, ma stackexchange funziona esattamente allo stesso modo. L'autenticazione in cui vengono inviati nome utente e password viene effettuata tramite una connessione https (quindi protetta con SSL o TLS) dopo che l'ID di sessione viene inviato su HTTP normale, che potrebbe consentire agli aggressori di rubare la sessione.

Ora stackexchange funziona esattamente allo stesso modo e molti utenti hanno chiesto la stessa cosa, " Perché stai facendo questo? " La spiegazione era che l'impostazione delle connessioni SSL è molto intensiva della CPU, potresti non accorgertene sui tuoi server web, ma quando ricevi migliaia di richieste al secondo, questo può diventare problematico. Ora ci sono soluzioni per questo tipo di scaricamento SSL, ma sono piuttosto costosi.

Quindi la mia ipotesi è che la ragione per cui ebay lo fa è molto simile al motivo per cui stackexchange lo fa: costa denaro.

C'è un risultato spesso citato da Google che afferma che quando hanno cambiato Gmail in SSL a livello di sito, hanno visto solo un piccolo sovraccarico che potrebbe essere trascurato. Un punto importante, tuttavia, è che è per Gmail che non è necessariamente una tipica applicazione Web.

Il sovraccarico della CPU per SSL è piccolo. Un core CPU base per PC può eseguire la crittografia AES a oltre 100 MB / s. La crittografia che avviene durante la creazione di una sessione (la "stretta di mano") può essere eseguita diverse centinaia di volte al secondo con lo stesso tipo di core, e non si verifica spesso, grazie sia a HTTP keep-alive che a SSL "abbreviato handshake". È logico che SSL implementato correttamente non ostruisca la CPU del server per la maggior parte dei tipi di siti Web.

Anche il sovraccarico di rete per una singola connessione è lieve. Quando è in pieno svolgimento, una connessione SSL / TLS interrompe i dati in singoli record, con un'intestazione e alcuni byte per il supporto crittografico: 5 byte per l'intestazione, 16 byte per IV per per record se si utilizza TLS 1.1+ e AES / CBC, 32 byte per un HMAC SHA-256 e da 1 a 16 byte di padding per l'allineamento. Al massimo 69 byte. Ma il record può incorporare fino a 16384 byte di dati applicativi, quindi stiamo parlando di una larghezza di banda extra dello 0,4%. Di nuovo, è trascurabile.

Tuttavia, esiste un sovraccarico della rete a livello di sito a causa della memorizzazione nella cache . Quando lo stesso pezzo di dati deve essere scaricato da molti client distinti, vale la pena utilizzare le cache, situate tra il server principale e i client: quando una connessione client, passando per una cache, è per un file che ha la cache, la cache può rispondere senza dover disturbare il server principale. Il client e il server non devono essere consapevoli di tale meccanismo; si chiama un proxy trasparente . Molti ISP eseguono questo tipo di sistema.

Le cache non sono di grande aiuto con Gmail, perché ogni utente ha la propria casella di posta e ci sono pochi file che saranno condivisi tra utenti diversi. Tuttavia, la situazione con Ebay potrebbe essere diversa, con tutte le foto degli articoli che inviano, per definizione, a molti clienti. È altamente plausibile che il caching sia molto più utile per le infrastrutture di Ebay rispetto a Gmail. Tuttavia, e questo è il punto delicato, SSL previene la maggior parte di questo caching. Se si utilizza SSL su tutto il sito, Ebay potrebbe possibilmente avere un impatto non trascurabile, abbastanza da dare loro motivo di fermarsi e riflettere. Non dico che Ebay non sta facendo SSL a livello di sito è provato per essere una questione di prestazioni relative alla cache, ma almeno è un motivo possibile .

Ovviamente, non fare SSL significa che l'intercettazione passiva e gli attacchi attivi sono una possibilità. Dal punto di vista di Ebay, ci sono dei compromessi ovunque tra sicurezza e usabilità. In definitiva, come dice @Lucas, si tratta di soldi.