Amazon parece creer que la sobrecarga de TLS es lo suficientemente alta como para justificar no cifrar el tráfico cuando no se realizan acciones confidenciales (como realizar pedidos, procesar pagos, administrar cuentas, historial de pedidos, iniciar sesión, etc.). Si bien el costo del lado del servidor de TLS es casi insignificante con el hardware actual, todavía tiene un costo distinto de cero. El impacto del lado del cliente puede ser mucho peor, especialmente en enlaces de alta latencia o no confiables, como algunas conexiones móviles; TLS puede causar retrasos significativos en la carga de la página, lo que puede hacer que los clientes vayan a otra parte.
Personalmente, opino que es mejor usar TLS para todo el tráfico hasta que, a menos que tenga una razón, no para hacerlo, y no hay muchos de ellos, no es que yo Llamaría válido, pero ante todo soy un tipo de seguridad. Amazon existe para ganar dinero, no para ser un modelo a seguir de desarrollo web seguro. Si a veces T-all-the-time les cuesta más que el uso de HTTP, entonces optarán por la segunda opción a pesar de que expone a sus clientes a ciertos tipos de ataques.
Un ejemplo de tal riesgo: aunque el formulario de inicio de sesión se sirve a través de HTTPS, el botón que lo lleva allí se sirve a través de HTTP. Un atacante podría usar un Ataque de eliminación de SSL para modificar la página de inicio de modo que el botón de inicio de sesión se vincule a HTTP en lugar de HTTPS. y el atacante podría falsificar la página de inicio de sesión cuando el usuario intentara iniciar sesión. El atacante podría ver las credenciales del usuario. Amazon podría evitar esto usando el Strict-Transport-Security
header , pero entonces tendrían que Servir todo el sitio a través de HTTPS todo el tiempo.
Como modelo de rol de seguridad, Amazon hace algunas cosas muy bien. Por ejemplo, su esquema SigV4 proporciona a AWS con autenticación, integridad , y un límite en los ataques de repetición. Es lo suficientemente bueno como para suponer que no hay datos intrínsecamente confidenciales (un número de tarjeta de crédito es inherentemente sensible; una cadena de identificación que se asigna a un número de tarjeta de crédito no lo está) en la solicitud o respuesta, en realidad puede ser Es seguro no usar TLS en algunas funciones de AWS (aunque en general exigen TLS para la mayoría de AWS de todos modos). Sin embargo, su sitio de venta al por menor hace algunas concesiones que sacrifican un poco de seguridad por un beneficio ligeramente mayor.
Si está buscando emular el éxito de business de Amazon, copiar sus opciones de seguridad puede ser una buena idea ... pero también tenga en cuenta que el sitio de ventas minoristas de Amazon.com es antiguo y se ha realizado Muchos cambios a lo largo de los años que añaden más y más seguridad. Debido a lo mucho que les cuesta tener un tiempo de inactividad en el sitio, es probable que duden mucho en meterse con él más de lo necesario. Si hoy estuvieran diseñando el sitio desde cero, podrían utilizar TLS para todo, con HSTS precargados. O tal vez no lo harían; después de todo, estoy seguro de que han considerado hacerlo y tienen razones para no (todavía) implementarlo.
Una nota final: el sitio ciertamente funciona con HTTPS todo el tiempo. Mi navegador en realidad usaba de forma predeterminada el uso de HTTPS para el sitio de venta minorista, aunque no lo había usado anteriormente en esta computadora y ciertamente no había iniciado sesión ni nada. No seas uno de esos sitios (mirándote a ti, Slashdot) que redirige a los usuarios de HTTPS a HTTP, incluso si el usuario prefiere específicamente usar HTTPS.