¿Se puede usar gzip sobre SSL? Y Conexión: encabezados Keep-Alive

Question

Estoy evaluando el rendimiento de la interfaz de usuario de una aplicación web segura (SSL) aquí en el trabajo y me pregunto si es posible comprimir archivos de texto (html/css/javascript) a través de SSL. He hecho algunas búsquedas en Google pero no he encontrado nada específicamente relacionado con SSL. Si es posible, ¿vale la pena los ciclos adicionales de la CPU ya que las respuestas también se cifran? ¿Las respuestas de compresión dañarían el rendimiento?

Además, quiero asegurarme de que mantenemos viva la conexión SSL, por lo que no estamos haciendo un intercambio de protocolos SSL una y otra vez. No veo Conexión: Keep-Alive en el respuesta encabezados. Veo Keep-Alive: 115 en el solicitud de encabezados, pero eso solo mantiene la conexión activa durante 115 milisegundos (¿parece que el servidor de la aplicación está cerrando la conexión después de que se procesa una sola solicitud?) ¿No le gustaría que el servidor establecer ese respuesta cabecera mientras dure el tiempo de espera de inactividad de la sesión?

Entiendo que los navegadores no almacenan en caché el contenido de SSL en el disco, por lo que estamos publicando los mismos archivos una y otra vez en visitas posteriores, aunque nada ha cambiado. Las principales recomendaciones de optimización son reducir el número de solicitudes http, minimizar, mover scripts al fondo, optimizar la imagen, la posible fusión del dominio (aunque es necesario sopesar el costo de otro protocolo de enlace SSL), cosas de esa naturaleza.

Answer 1

A su primera pregunta: SSL está trabajando en una capa diferente de la compresión. En cierto sentido, estas dos características son características de un servidor web que puede funcionar en conjunto y no superponerse. Sí, al habilitar la compresión, usará más CPU en su servidor pero tendrá menos tráfico saliente. Entonces es más una compensación.

A su segunda pregunta: el comportamiento Keep-Alive realmente depende de la versión HTTP. Puede mover su contenido estático a un servidor que no sea SSL (puede incluir imágenes, películas, audio, etc.)

Answer 2

Sí, la compresión gzip y Keep-Alive se puede usar con HTTPS/SSL. Además, los navegadores pueden almacenar en caché contenido SSL.

Este blog tiene más información acerca de cómo ajustar un sitio web HTTPS/SSL:

http://blog.httpwatch.com/2009/01/15/https-performance-tuning/

Answer 3

Sí, la compresión se puede utilizar a través de SSL; se lleva a cabo antes de cifrar los datos, por lo que puede ayudar a los enlaces lentos. Cabe señalar que esta es una mala idea : this also opens a vulnerability.

Después del saludo inicial, SSL es menos de lo que mucha gente piensa * - incluso si el cliente se reconecta, hay un mecanismo para continuar sesiones existentes sin renegociar claves, lo que resulta en menos uso de CPU y menos viajes redondos.

Los equilibradores de carga pueden atornillarse con el mecanismo de continuación: si las solicitudes se alternan entre servidores, se requieren más apretones de manos completos, lo que puede tener un impacto notable (~ unos cientos de ms por solicitud). Configure su equilibrador de carga para reenviar todas las solicitudes desde la misma IP al mismo servidor de aplicaciones.

¿Qué servidor de aplicaciones estás utilizando? Si no se puede configurar para usar keep-alive, comprimir archivos y así sucesivamente, considere ponerlo detrás de un proxy inverso que puede (y mientras lo hace, relaje los encabezados de caché enviados con contenido estático - HttpWatchSupport está vinculado el artículo tiene algunos consejos útiles en ese frente).

(* proveedores de hardware SSL se dicen cosas como "hasta 5 veces más CPU" pero algunos chaps from Google informó que cuando Gmail fue a SSL por defecto, sólo representó carga de la CPU ~ 1%)

Answer 4

Uso de la compresión con SSL lo abre a vulnerabilidades como BREACH, CRIME u otros ataques elegidos de texto sin formato.

Debe desactivar la compresión ya que SSL/TLS no tienen forma de mitigar actualmente estos ataques de oráculo de longitud.

Answer 5

1. Probablemente nunca use la compresión TLS. Algunos agentes de usuario (al menos Chrome) lo deshabilitarán de todos modos.

2. Puede utilizar selectivamente la compresión HTTP

3. Siempre se puede minify

4. Hablemos de almacenamiento en caché demasiado

Voy a asumir que usted está usando un HTTPS Everywhere web de estilo sitio.

Escenario:

1. El contenido estático como CSS o JS:

   • Usar compresión HTTP
   • Uso minimización
   • periodo largo de caché (como un año)
   • etag es solo marginalmente útil (debido a la memoria caché larga)
   • incluir algún tipo de número de versión en la URL en el código HTML que apunta a este activo para que pueda almacenar en caché y caída

2. contenido HTML con cero información sensible (como una página Acerca de nosotros):

   • utilizar la compresión HTTP
   • uso minimización
   • uso de un período corto de caché
   • uso etag
contenido

3. HTML con cualquier información sensible (como un número de fichas o cuenta bancaria CSRF):

   • NO compresión HTTP
   • Uso minimización
   • Cache-Control: no-store, must-revalidate
   • etag tiene sentido aquí (debido a la revalidación)
   • Refresh: ${seconds until session expires + small buffer}

Lo anterior actualizará la página justo después de que la sesión caduque, lo que "desconectará" al usuario, mostrando la pantalla de inicio de sesión. Si alguien presiona el botón Atrás del navegador, la información confidencial no se muestra debido al encabezado del caché.

Puede utilizar la compresión HTTP con datos sensibles SI:

1. Nunca regrese a la entrada del usuario en la respuesta (tiene un cuadro de búsqueda no utilice la compresión HTTP?)
2. O lo hace volver la entrada del usuario en la respuesta, pero rellene aleatoriamente la respuesta