¿Puede un servidor proxy almacenar en caché los GET SSL? Si no, ¿sería suficiente el cifrado del cuerpo de respuesta?

Question

¿Puede (|| any) el contenido del caché del servidor proxy que es solicitado por un cliente a través de https? Como el servidor proxy no puede ver la cadena de consulta, o los encabezados http, reconozco que no pueden.

Estoy considerando una aplicación de escritorio, dirigida por un número de personas detrás de su proxy de empresas. Esta aplicación puede acceder a los servicios a través de Internet y me gustaría aprovechar la infraestructura incorporada de caché de Internet para 'leer'. Si los servidores proxy de almacenamiento en caché no pueden almacenar en caché contenido entregado con SSL, ¿sería simplemente una opción viable encriptar el contenido de una respuesta?

Estoy considerando solicitar todas las solicitudes GET que deseamos que sean cachables en lugar de http con el cuerpo cifrado mediante cifrado asimétrico, donde cada cliente tiene la clave de descifrado. Cada vez que deseamos realizar un GET que no sea de caché, o una operación de POST, se realizará a través de SSL.

Answer 1

No, no es posible almacenar en caché https directamente. Toda la comunicación entre el cliente y el servidor está encriptada. Un proxy se ubica entre el servidor y el cliente, para poder almacenarlo en caché, necesita poder leerlo, es decir, descifrar el cifrado.

Puede hacer algo para almacenarlo en caché. Básicamente haces SSL en tu proxy, interceptando el SSL enviado al cliente. Básicamente, los datos se cifran entre el cliente y su proxy, se descifran, leen y almacenan en caché, y los datos se cifran y envían al servidor. La respuesta del servidor también está descifrada, leída y encriptada. No estoy seguro de cómo hacer esto en el software de proxy principal (como calamar), pero es posible.

El único problema con este enfoque es que el proxy deberá usar un certificado autofirmado para encriptarlo al cliente. El cliente podrá decir que un proxy en el medio ha leído los datos, ya que el certificado no será del sitio original.

Answer 2

El comentario de Rory de que el proxy debería usar un certificado autofirmado, si no es estrictamente cierto.

El proxy podría implementarse para generar un nuevo certificado para cada nuevo host SSL que se le solicite y firmarlo con un certificado raíz común. En el escenario del OP de un entorno de protección, el certificado de firma común puede instalarse fácilmente como CA de confianza en las máquinas cliente y aceptarán gustosamente estos certificados SSL "falsificados" para el tráfico que se está procesando, ya que no habrá ningún desajuste entre los nombres de host.

De hecho, esto es exactamente cómo el software como el Charles Web Debugging Proxy permita la inspección de tráfico SSL sin causar errores de seguridad en el navegador, etc.

Answer 3

Creo que sólo debe utilizar SSL y confiar en una biblioteca de cliente HTTP que hace el almacenamiento en caché (Ej: WinInet en Windows). Es difícil imaginar que los beneficios del almacenamiento en caché en toda la empresa valen la pena de escribir un esquema de cifrado de seguridad personalizado o un certificado divertido en el proxy. Peor aún, en el esquema de cifrado que menciona, hacer cifrados asimétricos en el cuerpo de la entidad suena como un gran golpe de perforación en el lado del servidor de su aplicación; hay una razón por la que SSL usa cifras simétricas para la carga real de la conexión.

Answer 4

Creo que debería utilizar SSL y confiar en una biblioteca de cliente HTTP que almacena en caché (por ejemplo, WinInet en Windows). Es difícil imaginar que los beneficios del almacenamiento en caché en toda la empresa valen la pena de escribir un esquema de cifrado de seguridad personalizado o un certificado divertido en el proxy. Peor aún, en el esquema de encyrption que menciona, hacer cifrados asimétricos en el cuerpo de la entidad suena como un gran golpe de perforación en el lado del servidor de su aplicación; hay una razón por la que SSL usa cifras simétricas para la carga real de la conexión.

La aplicación en cuestión no es una aplicación de navegador, es una aplicación de escritorio que extrae datos a través de Internet. Lo que sucederá es que todas las instancias de la aplicación generarán la misma pieza aproximadamente al mismo tiempo. Estos datos deben estar seguros, pero espero aumentar el rendimiento haciendo que algunas instancias de la aplicación obtengan una versión en caché del servidor proxy corporativo.

Los fragmentos de datos son pequeños, pero se pueden solicitar con frecuencia. Esencialmente, todas las instancias de aplicaciones van a solicitar los mismos datos entre sí al mismo tiempo.

El cuerpo de los datos/mensajes en el lado del servidor se predefinirá y almacenará en caché en una tabla hash en memoria distribuida. El cifrado no se realizará por solicitud.

También estoy investigando el uso de un bus de mensajes, como NServiceBus en su lugar.

Answer 5

Salida www.bluecoat.com es un proxy comercial que, de hecho, podemos hacer https intercepción con el fin de bloquear los sitios, restringir el contenido, inspeccionar en busca de virus y contenido de la caché (GET)

Answer 6

Cómo sobre la configuración de un servidor caché en el servidor de aplicaciones detrás del componente que encripta las respuestas https Esto puede ser útil si tiene una configuración de proxy inverso.

Estoy pensando en algo como esto:

application server <---> Squid or Varnish (cache) <---> Apache (performs SSL encryption)