Según el siguiente documento, es posible descifrar el tráfico HTTPS inspeccionando las llamadas AJAX y utilizando el parámetro de tamaño como un oráculo criptográfico.
¿Debo enviar una carga útil de longitud variable junto con cada GET o POST de HTTPS? ¿Es eso suficiente para protegerme de este ataque?
¿Debería la respuesta HTTPS tener una cadena de longitud variable adjunta también?
¿Qué tan grande debe ser ese apéndice aleatorio de datos de longitud aleatoria?
Desde el exterior, solo se puede ver la longitud de los datos intercambiados, es decir, la longitud total de la solicitud y la longitud total de la respuesta (redondeada a un múltiplo del bloque de cifrado simétrico tamaño, por ejemplo, 16 bytes si se usa AES, pero no se redondea en absoluto con RC4). Para evitar filtrar información, todas las solicitudes y todas las respuestas deben tener exactamente el mismo tamaño; por lo tanto, el relleno debe tener un tamaño variable que depende de la longitud de los datos rellenados . Si agrega un relleno con una longitud aleatoria pero con una distribución de probabilidad que no depende del tamaño de la solicitud o respuesta rellenada, entonces la longitud de la solicitud original se puede reconstruir estadísticamente si esa solicitud se realiza con regularidad.
No es necesario que los bytes de relleno sean aleatorios. Sólo la longitud es visible "desde el exterior". Puede usar valores constantes de bytes (por ejemplo, un encabezado HTTP personalizado X-Padding: ZZZZZZZZZ con, como contenido, una secuencia de 'Z' de la longitud apropiada). El uso de datos aleatorios podría realmente filtrar información adicional a través del tiempo (si el generador aleatorio no es muy rápido, el atacante podría observar el tiempo de reacción del cliente o servidor y deducir el tamaño del relleno, obteniendo así, de manera indirecta, el verdadero longitud de solicitud o respuesta).
El hecho de apuntar siempre a un tamaño fijo desperdicia el ancho de banda de la red, ya que todas las solicitudes tendrán el tamaño de la solicitud más grande posible y todas las respuestas el tamaño de la respuesta más grande posible. La sugerencia de @ Paŭlo de rellenar hasta el siguiente múltiplo de un valor dado (por ejemplo, hasta la siguiente longitud que es un múltiplo de 500 bytes) es apropiada: pierde un poco más que siempre el relleno a la misma longitud, pero no tiene fugas mucho; y evita el desperdicio de recursos de red.
Lea otras preguntas en las etiquetas encryption tls http random ajax