Amazon ritiene che il sovraccarico di TLS sia sufficientemente elevato da giustificare la mancata crittografia del traffico quando non eseguono azioni sensibili (come l'immissione di ordini, l'elaborazione dei pagamenti, la gestione degli account, la cronologia degli ordini, il login, ecc.). Mentre il costo lato server di TLS è quasi insignificante con l'hardware di oggi, ha comunque un costo non zero. L'impatto sul lato client può essere molto peggiore, specialmente su collegamenti ad alta latenza o inaffidabili come alcune connessioni mobili; TLS può causare ritardi significativi nel caricamento delle pagine, che può portare i clienti a spostarsi altrove.
Personalmente ritengo che sia meglio usare TLS per tutto il traffico fino a quando, a meno che non si abbia un motivo non , non ci siano molti di quelli, non che io Chiamami valido - ma io sono un ragazzo di sicurezza prima di tutto. Amazon esiste per fare soldi, non per essere un modello di sviluppo sicuro del web. Se tutto-TLS-tutto-un-anno costa loro più dell'uso di HTTP a volte, allora andranno con la seconda opzione anche se espongono i loro clienti a determinati tipi di attacchi.
Un esempio di tale rischio: sebbene il modulo di login sia servito su HTTPS, il pulsante che ti porta lì viene servito su HTTP. Un utente malintenzionato potrebbe utilizzare un attacco Stripping SSL per modificare la home page in modo che il pulsante di accesso sia collegato a HTTP anziché HTTPS, e l'utente malintenzionato potrebbe quindi falsificare la pagina di accesso quando l'utente ha tentato di accedere. L'utente malintenzionato potrebbe quindi visualizzare le credenziali dell'utente. Amazon potrebbe impedirlo utilizzando l' Strict-Transport-Security
header , ma poi dovrebbero servi l'intero sito su HTTPS in ogni momento.
Come modello per i ruoli di sicurezza, Amazon fa alcune cose molto bene. Ad esempio, il loro schema SigV4 fornisce ad AWS l'autenticazione, l'integrità e un limite per gli attacchi di riproduzione. È abbastanza buono che, supponendo che non ci siano dati intrinsecamente sensibili (un numero di carta di credito è intrinsecamente sensibile, una stringa identificativa che associa a un numero di carta di credito non lo è) nella richiesta o nella risposta, può effettivamente essere sicuro di non utilizzare TLS su alcune funzioni di AWS (sebbene in generale impongano TLS per la maggior parte di AWS comunque). Il loro sito di vendita al dettaglio, tuttavia, fa alcuni compromessi che sacrificano un po 'di sicurezza per ottenere un profitto leggermente maggiore.
Se stai cercando di emulare il successo di business di Amazon, copiare le loro scelte di sicurezza potrebbe essere saggio ... ma ricorda anche che il sito di vendita al dettaglio di Amazon.com è vecchio e ha subito un sacco di cambiamenti nel corso degli anni che aggiungono sempre più sicurezza. Dato quanto costa loro avere dei tempi di fermo sul sito, probabilmente sono molto riluttanti a complicarlo più del necessario. Se stessero progettando il sito da zero oggi, potrebbero usare TLS per tutto, con HST precaricati. O forse non lo farebbero; dopo tutto, sono sicuro che hanno preso in considerazione l'idea di farlo e hanno ragioni per non implementarlo (ancora).
Un'ultima nota: il sito funziona sicuramente su HTTPS, sempre. Il mio browser in realtà utilizzava l'HTTPS per il sito di vendita al dettaglio, anche se non l'avevo usato in precedenza su questo computer e certamente non avevo effettuato l'accesso o altro. Per favore non essere uno di quei siti (guardandoti, Slashdot) che reindirizza gli utenti da HTTPS a HTTP anche se l'utente preferisce in particolare utilizzare HTTPS.