ssl https compression gzip

¿Puedes usar gzip sobre SSL? Y conexión: encabezados Keep-Alive



https compression (5)

  1. Probablemente nunca deberías usar compresión TLS. Algunos agentes de usuario (al menos Chrome) lo deshabilitarán de todos modos.

  2. Puedes usar selectivamente compresión HTTP

  3. Siempre puedes minimizar

  4. Vamos a hablar sobre el almacenamiento en caché también

Voy a suponer que está utilizando un sitio web de estilo HTTPS Everywhere.

Guión:

  1. Contenido estático como css o js:

    • Usar compresión HTTP
    • Usa la minificación
    • Largo período de caché (como un año)
    • etag solo es marginalmente útil (debido a la memoria caché larga)
    • Incluya algún tipo de número de versión en la URL en su HTML que apunta a este activo para que pueda cache-bust

  2. Contenido HTML con información confidencial ZERO (como una página Acerca de nosotros):

    • Usar compresión HTTP
    • Usa la minificación
    • Use un período corto de caché
    • Usa etag

  3. Contenido HTML con CUALQUIER información confidencial (como un token CSRF o número de cuenta bancaria):

    • SIN compresión HTTP
    • Usa la minificación
    • Cache-Control: no-store, must-revalidate
    • etag no 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 caduque la sesión, 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 usar compresión HTTP con datos confidenciales SI:

  1. Nunca devuelves la entrada del usuario en la respuesta (¿tienes un cuadro de búsqueda? No utilizas la compresión HTTP)
  2. O devuelve la entrada del usuario en la respuesta, pero rellena aleatoriamente la respuesta

Estoy evaluando el funcionamiento frontal 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 conexiones SSL una y otra vez. No veo Connection: Keep-Alive en los encabezados de respuesta . Veo Keep-Alive: 115 en los encabezados de las solicitudes, pero eso solo mantiene viva la conexión durante 115 milisegundos (parece que el servidor de la aplicación está cerrando la conexión después de procesar una sola solicitud). ¿No le gustaría que el servidor esté configurando? ese encabezado de respuesta durante el tiempo de espera de inactividad de la sesión?

Entiendo que los navegadores no almacenen en caché contenido 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.

A su primera pregunta: SSL está trabajando en una capa diferente a 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.)

El uso de compresión con SSL lo abre a vulnerabilidades como BREACH, CRIME u otros ataques de texto plano elegidos.

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

Sí, la compresión se puede usar 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: esto también abre una vulnerabilidad .

Después del primer apretón de manos, SSL es menos de lo que mucha gente piensa *: incluso si el cliente se reconecta, existe un mecanismo para continuar las sesiones existentes sin renegociar las claves, lo que resulta en menos uso de CPU y menos viajes redondos.

Sin embargo, 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 usando? Si no se puede configurar para usar keep-alive, comprimir archivos, etc., considere colocarlo detrás de un proxy inverso que pueda (y mientras lo hace, relajar los encabezados de caché enviados con contenido estático - el artículo vinculado de HttpWatchSupport tiene algunos consejos útiles en ese frente).

(* Los proveedores de hardware SSL dirán cosas como "hasta 5 veces más CPU", pero algunos colegas de Google informaron que cuando Gmail fue a SSL de manera predeterminada, solo representaba ~ 1% de carga de CPU)