security - significado - ¿Por qué no usar HTTPS para todo?

ssl (15)

¿Por qué no enviar todas las publicaciones de correo de caracol en un sobre opaco a prueba de manipulaciones por correo certificado? Alguien de la Oficina de Correos siempre tendrá custodia personal del mismo, por lo que puede estar seguro de que nadie está fisgoneando en su correo. Obviamente, la respuesta es que si bien vale la pena el costo de algunos correos, la mayoría no. No me importa si alguien lee mi "Me alegra que hayas salido de la cárcel". postal para el tío Joe.

La encriptación no es gratuita, y no siempre ayuda.

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

Mi opinión es que HTTPS debe usarse solo cuando sea inevitablemente necesario, ya sea porque la solicitud o la respuesta deben salvaguardarse del espionaje intermedio. Como ejemplo, ve a Yahoo! página principal. Aunque hayas iniciado sesión, la mayor parte de tu 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.

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 simplemente cifrar todo el sitio y proteger al usuario por completo. Evitaría problemas tales como decidir qué debe asegurarse, porque todo sería, y no es realmente un inconveniente para el usuario.

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

Esta es una pregunta relacionada: ¿Por qué https solo se utiliza para iniciar sesión? , pero las respuestas no son satisfactorias. Las respuestas suponen que no ha podido aplicar https a 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 un manto de seguridad garantizado. Este tipo de protección debe integrarse en la arquitectura de la aplicación, en lugar de tratar de confiar en alguna bala mágica.

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 solo servidor puede admitir múltiples dominios en HTTP porque el encabezado HTTP del servidor le permite al servidor saber con qué dominio responder.

Con HTTPS, el servidor debe ofrecer su certificado al cliente durante el intercambio inicial de TLS (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: técnicamente, puede alojar varios dominios si los aloja en puertos diferentes, pero generalmente no es una opción. También puede alojar varios dominios si su certificado SSL tiene un comodín. Por ejemplo, puede alojar tanto foo.example.com como bar.example.com con el certificado * .example.com

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

También es potencialmente confuso para los usuarios finales si todas las direcciones usan https:// lugar del familiar http:// . Además, mira esta respuesta:

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

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

Definitivamente no debe usar compresión SSL o compresión HTTP sobre SSL, debido a ataques de INCUMPLIMIENTO y CRIMEN. 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 compresión allí. También puedes usar la minificación de HTML.
Un certificado SSL, una dirección IP, a menos que use SNI, que no funciona en todos los navegadores (antiguo de Android, Blackberry 6, etc.).
No debe alojar ningún contenido externo en sus páginas que no provenga de SSL.
Pierde el encabezado HTTP Referer saliente cuando el navegador va a una página HTTP, lo que puede o no ser un problema para usted.

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 caro y más difícil de administrar.

Me dijeron que en un proyecto de nuestra compañía, descubrieron que el ancho de banda utilizado por los mensajes SSL era significativamente mayor que el de los mensajes sin formato. Creo que alguien me dijo que era una cantidad asombrosa de 12 veces más datos. No he verificado esto por mí mismo y suena muy alto, pero si hay algún tipo de encabezado agregado a cada página y la mayoría de las páginas tiene una pequeña cantidad de contenido, puede que no esté tan lejos.

Dicho eso, la molestia de ir y venir entre http y https y hacer un seguimiento de las páginas que me parecen demasiado esfuerzo. Solo una vez intenté construir un sitio que los mezclara y terminamos abandonando el plan cuando nos tropezamos con cosas complejas como ventanas emergentes creadas por Javascript que les daba un protocolo incorrecto y ese tipo de cosas. Terminamos haciendo que todo el sitio https sea menos problemático. Supongo que en casos simples en los que solo tiene una pantalla de inicio de sesión y una pantalla de pago que necesitan protección y son páginas simples, no sería un gran problema mezclar y combinar.

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

Otro punto pequeño (tal vez alguien puede verificarlo). Si un usuario ingresa datos en un elemento de formulario como un cuadro de texto y luego, por algún motivo, actualiza la página o el servidor falla por un segundo, los datos que el usuario ingresó 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.

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 certificados intermedios), acordar conjuntos de cifrado y establecer una sesión. Una vez que se establece una sesión, las solicitudes subsiguientes pueden utilizar el almacenamiento en caché de la sesión para reducir el número de viajes redondos, pero incluso en este caso, todavía hay más viajes redondos que lo que requiere una conexión HTTP normal. Incluso si las operaciones de encriptación fueran gratuitas, los viajes redondos no son y pueden ser bastante notorios en los 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 lleva a cabo negocios a nivel internacional, requerir https puede causar retrasos notorios.

Hay consideraciones adicionales como el mantenimiento del servidor del estado de la sesión que requiere potencialmente mucha más memoria y, por supuesto, las operaciones de cifrado de datos. Cualquier sitio pequeño prácticamente no necesita preocuparse por la capacidad del servidor dado frente al 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 vuelven cada vez más irrelevantes a medida que avanza el tiempo y mejoran las capacidades del hardware y la red. En la mayoría de los casos, dudo que haya una diferencia tangible hoy.

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

Puedo pensar en un par de razones.

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

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á en clara violación de los 10 mejores de OWASP para 2010 "A3: autenticación rota y gestión de sesiones".

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

Windows Server 2012 con IIS 8.0 ahora ofrece SNI, que es la Indicación de Nombre del Servidor que permite alojar varias Aplicaciones Web SSL en IIS en una Dirección IP.

https es más hambriento de recursos que el http normal.

Exige más de los servidores y los clientes.

https requiere que el servidor cifre y descifre las solicitudes y respuestas de los clientes. El impacto en el rendimiento se sumará si el servidor atiende a muchos clientes. Es por eso que la mayoría de las implementaciones actuales de https están limitadas a la autenticación de contraseña solamente. Pero con el aumento de poder de cómputo esto puede cambiar, después de todo, Gmail está usando SSL para todo el sitio.