¿Por qué no usar HTTPS para todo?

Si estaba configurando un servidor y tenía los certificados SSL, ¿por qué no usaría HTTPS para todo el sitio en lugar de solo para compras / inicios de sesión? Creo que tendría más sentido encriptar todo el sitio y proteger al usuario por completo. Evitaría problemas como decidir qué se debe asegurar porque todo lo sería, y no es realmente un inconveniente para el usuario.

Si ya estaba usando un HTTPS para parte del sitio, ¿por qué no querría usarlo para todo el sitio?

Esta es una pregunta relacionada: ¿Por qué solo se usa https para iniciar sesión? , pero las respuestas no son satisfactorias. Las respuestas suponen que no ha podido aplicar https a todo el sitio.

Puedo pensar en un par de razones.

• Algunos navegadores pueden no ser compatibles con SSL.
• SSL puede disminuir el rendimiento un poco. Si los usuarios descargan grandes archivos públicos, puede haber una carga del sistema para cifrarlos cada vez.

Además de las otras razones (especialmente relacionadas con el rendimiento), solo puede alojar un solo dominio por dirección IP * cuando usa HTTPS.

Un único servidor puede soportar múltiples dominios en HTTP porque el servidor HTTP de cabecera permite al servidor saber qué dominio de responder con.

Con HTTPS, el servidor debe ofrecer su certificado al cliente durante el protocolo de enlace TLS inicial (que es antes de que se inicie HTTP). Esto significa que el encabezado del servidor aún no se ha enviado, por lo que no hay forma de que el servidor sepa qué dominio se solicita y con qué certificado (www.foo.com o www.bar.com) responder.

* Nota al pie: Técnicamente, puede alojar múltiples dominios si los aloja en diferentes puertos, pero eso generalmente no es una opción. También puede alojar varios dominios si su certificado SSL tiene un comodín. Por ejemplo, puede alojar foo.example.com y bar.example.com con el certificado * .example.com

SSL / TLS no se usa con la suficiente frecuencia. HTTPS debe usarse para toda la sesión , en ningún momento se puede enviar una ID de sesión a través de HTTP. Si solo está utilizando https para iniciar sesión, entonces está violando claramente el top 10 de OWASP para 2010 "A3: autenticación y administración de sesión interrumpidas".

¿Por qué no enviar cada correo postal en un sobre opaco a prueba de manipulaciones por correo certificado? Alguien de la oficina de correos siempre tendría la custodia personal de la misma, por lo que podría estar bastante seguro de que nadie está husmeando en su correo. Obviamente, la respuesta es que, si bien vale la pena gastar parte del correo, la mayoría no lo es. No me importa si alguien lee mi "¡Me alegra que hayas salido de la cárcel!" postal al tío Joe.

El cifrado no es gratuito, y no siempre ayuda.

Si una sesión (como compras, banca, etc.) va a terminar usando HTTPS, no hay una buena razón para no hacer que toda la sesión sea HTTPS lo antes posible.

Mi opinión es que HTTPS debe usarse solo cuando sea inevitablemente necesario, ya sea porque la solicitud o la respuesta deben protegerse de la inspección intermedia. Como ejemplo, ve a Yahoo! página principal. Aunque haya iniciado sesión, la mayor parte de su interacción será a través de HTTP. Se autentica a través de HTTPS y obtiene cookies que prueban su identidad, por lo que no necesita HTTPS para leer noticias.

La razón más importante, más allá de la carga del sistema, es que rompe el alojamiento virtual basado en nombres. Con SSL, es un sitio: una dirección IP. Esto es bastante costoso y más difícil de administrar.

Para enlaces de alta latencia, el protocolo de enlace TLS inicial requiere viajes de ida y vuelta adicionales para validar la cadena de certificados (incluido el envío de cualquier certificado intermedio), acordar conjuntos de cifrado y establecer una sesión. Una vez que se establece una sesión, las solicitudes posteriores pueden utilizar el almacenamiento en caché de la sesión para reducir el número de viajes de ida y vuelta, pero incluso en este mejor caso todavía hay más viajes de ida y vuelta de los que requiere una conexión HTTP normal. Incluso si las operaciones de encriptación fueran libres, los viajes de ida y vuelta no lo son y pueden ser notorios en enlaces de red más lentos, especialmente si el sitio no aprovecha la canalización de http. Para los usuarios de banda ancha dentro de un segmento bien conectado de la red, esto no es un problema. Si realiza negocios a nivel internacional, solicitar https puede causar retrasos notorios.

Hay consideraciones adicionales, como el mantenimiento del servidor del estado de la sesión que requiere potencialmente más memoria y, por supuesto, operaciones de cifrado de datos. Prácticamente, los sitios pequeños no necesitan preocuparse por la capacidad dada del servidor versus el costo del hardware actual. Cualquier sitio grande fácilmente podría permitirse la descarga de CPU / w AES o tarjetas adicionales para proporcionar una funcionalidad similar.

Todos estos problemas se están volviendo cada vez más no problemáticos a medida que pasa el tiempo y las capacidades del hardware y la red mejoran. En la mayoría de los casos, dudo que haya alguna diferencia tangible hoy.

Puede haber consideraciones operativas tales como restricciones administrativas en el tráfico https (piense en filtros de contenido intermedios ... etc.) posiblemente en algunas regulaciones corporativas o gubernamentales. Algunos entornos corporativos requieren descifrado de datos en el perímetro para evitar fugas de información ... interferencia con puntos de acceso y sistemas de acceso basados ​​en la web similares que no son capaces de inyectar mensajes en transacciones https. Al final del día, desde mi punto de vista, las razones para no usar https por defecto probablemente sean bastante pequeñas.

https consume más recursos que el http normal.

Exige más de los servidores y los clientes.

Si toda la sesión está encriptada, no podrá utilizar el almacenamiento en caché de recursos estáticos como imágenes y js a nivel de proxy, por ejemplo, ISP.

Debe usar HTTPS en todas partes, pero perderá lo siguiente:

1. Definitivamente no debe usar la Compresión SSL o la Compresión HTTP sobre SSL, debido a los ataques BREACH y CRIME. Entonces no hay compresión si su respuesta contiene identificadores de sesión o csrf. Puede mitigar esto colocando sus recursos estáticos (imágenes, js, css) en un dominio sin cookies, y use la compresión allí. También puede usar la minificación HTML.

2. Un certificado SSL, una dirección IP, a menos que use SNI, que no funciona en todos los navegadores (antiguo Android, Blackberry 6, etc.).

3. No debe alojar ningún contenido externo en sus páginas que no provenga de SSL.

4. Pierde el encabezado Referer HTTP saliente cuando el navegador va a una página HTTP, lo que puede o no ser un problema para usted.

Bueno, la razón obvia es el rendimiento: el servidor deberá cifrar todos los datos antes de la transmisión y luego el cliente los descifrará al recibirlos, lo que es una pérdida de tiempo si no hay datos confidenciales. También puede afectar la cantidad de su sitio que se almacena en caché.

También es potencialmente confuso para los usuarios finales si todas las direcciones usan en https://lugar de las familiares http://. Además, vea esta respuesta:

¿Por qué no usar siempre https cuando se incluye un archivo js?

https requiere que el servidor cifre y descifre las solicitudes y respuestas de los clientes. El impacto en el rendimiento aumentará si el servidor atiende a muchos clientes. Es por eso que la mayoría de las implementaciones actuales de https se limitan solo a la autenticación de contraseña. Pero con el aumento de la potencia informática, esto puede cambiar, después de todo, Gmail está utilizando SSL para todo el sitio.

Además de la respuesta de WhirlWind, debe considerar el costo y la aplicabilidad de los certificados SSL, los problemas de acceso (es posible, aunque poco probable, que un cliente no pueda comunicarse a través del puerto SSL), etc.

Usar SSL no es una garantía de seguridad garantizada. Este tipo de protección debe integrarse en la arquitectura de la aplicación, en lugar de tratar de confiar en una bala mágica.

Me dijeron que en un proyecto en nuestra empresa, descubrieron que el ancho de banda ocupado por los mensajes SSL era significativamente mayor que el de los mensajes simples. Creo que alguien me dijo que era una información asombrosamente 12 veces mayor. No lo he verificado yo mismo y suena muy alto, pero si se agrega algún tipo de encabezado a cada página y la mayoría de las páginas tienen una pequeña cantidad de contenido, puede que no esté tan lejos.

Dicho esto, la molestia de ir y venir entre http y https y hacer un seguimiento de qué páginas son, lo que me parece demasiado esfuerzo. Solo una vez traté de construir un sitio que los mezclara y terminamos abandonando el plan cuando nos tropezamos con cosas complejas como ventanas emergentes creadas por Javascript al conectarles un protocolo incorrecto y ese tipo de cosas. Terminamos haciendo que todo el sitio https fuera menos problemático. Supongo que en casos simples en los que solo tienes una pantalla de inicio de sesión y una pantalla de pago que deben protegerse y son páginas simples, no sería un gran problema mezclar y combinar.

No me preocuparía mucho la carga del cliente para descifrar. Normalmente, el cliente pasará mucho más tiempo esperando que los datos lleguen a través del cable de lo que se necesita para procesarlos. Hasta que los usuarios habitualmente tengan conexiones a Internet de gigabit / seg, la potencia de procesamiento del cliente probablemente sea bastante irrelevante. La potencia de la CPU requerida por el servidor para cifrar páginas es un problema diferente. Es posible que haya problemas de que no pueda mantenerse al día con cientos o miles de usuarios.

Otro pequeño punto (tal vez alguien puede verificar): si un usuario escribe datos en un elemento de formulario, como un cuadro de texto y luego, por alguna razón, actualiza la página o el servidor falla por un segundo, los datos que ingresó el usuario se pierden usando HTTPS pero se conserva utilizando HTTP.

Nota: No estoy seguro de si esto es específico del navegador, pero ciertamente sucede con mi navegador Firefox.

Windows Server 2012 con IIS 8.0 ahora ofrece SNI, que es la Indicación de nombre del servidor que permite que múltiples aplicaciones web SSL en IIS se alojen en una dirección IP.