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

Question

¿Puede un servidor proxy (||cualquier) almacenar en caché el contenido solicitado por un cliente a través de https?Como el servidor proxy no puede ver la cadena de consulta ni los encabezados http, creo que no pueden.

Estoy considerando una aplicación de escritorio, ejecutada por varias personas detrás del proxy de su empresa.Esta aplicación puede acceder a servicios a través de Internet y me gustaría aprovechar la infraestructura de almacenamiento en caché de Internet incorporada para "lecturas".Si los servidores proxy de almacenamiento en caché no pueden almacenar en caché el contenido entregado por SSL, ¿sería simplemente cifrar el contenido de una respuesta una opción viable?

Estoy considerando que todas las solicitudes GET que deseamos que se puedan almacenar en caché se soliciten a través de http con el cuerpo cifrado mediante cifrado asimétrico, donde cada cliente tiene la clave de descifrado.Cada vez que deseemos realizar una operación GET que no se pueda almacenar en caché o una operación 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á cifrada.Un proxy se encuentra entre el servidor y el cliente; para almacenarlo en caché, debe poder leerlo, es decir, descifrar el cifrado.

Puedes hacer algo para almacenarlo en caché.Básicamente, realiza el SSL en su proxy, interceptando el SSL enviado al cliente.Básicamente, los datos se cifran entre el cliente y su proxy, se descifran, se leen y se almacenan en caché, y los datos se cifran y se envían al servidor.La respuesta del servidor también se descifra, lee y cifra.No estoy seguro de cómo se hace esto en los principales software proxy (como Squid), pero es posible.

El único problema con este enfoque es que el proxy tendrá que utilizar un certificado autofirmado para cifrarlo ante el cliente.El cliente podrá saber 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 tendría que utilizar un certificado autofirmado si no es estrictamente cierto.

El proxy podría implementarse para generar un nuevo certificado para cada nuevo host SSL con el que se le solicite tratar y firmarlo con un certificado raíz común.En el escenario del OP de un entorno corporativo, el certificado de firma común se puede instalar con bastante facilidad como una CA confiable en las máquinas cliente y con gusto aceptarán estos certificados SSL "falsos" para el tráfico que se envía por proxy, ya que no habrá discrepancias en los nombres de host.

De hecho, así es exactamente como software como el Proxy de depuración web Charles permitir la inspección del tráfico SSL sin provocar errores de seguridad en el navegador, etc.

Answer 3

Creo que deberías usar SSL y confiar en una biblioteca cliente HTTP que realice almacenamiento en caché (por ejemplo:WinInet en Windows).Es difícil imaginar que los beneficios del almacenamiento en caché en toda la empresa valga la pena 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, realizar cifrados asimétricos en el cuerpo de la entidad suena como un gran éxito en el rendimiento en el lado del servidor de su aplicación;Hay una razón por la que SSL utiliza cifrados simétricos para la carga útil 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 de Internet.Lo que sucederá es que todas las instancias de la aplicación extraerán la misma parte aproximadamente al mismo tiempo.Estos datos deben protegerse, 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 es posible que se soliciten con frecuencia.Básicamente, todas las instancias de la aplicación solicitarán los mismos datos entre sí al mismo tiempo.

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

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

Answer 4

Consulte www.bluecoat.com, es un proxy comercial que, de hecho, PUEDE interceptar https para bloquear sitios, restringir contenido, inspeccionar en busca de virus y almacenar en caché el contenido (GET).

Answer 5

Creo que deberías usar SSL y confiar en una biblioteca cliente HTTP que realice almacenamiento en caché (por ejemplo:WinInet en Windows).Es difícil imaginar que los beneficios del almacenamiento en caché en toda la empresa valga la pena 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, realizar cifrados asimétricos en el cuerpo de la entidad suena como un gran éxito en el rendimiento en el lado del servidor de su aplicación;Hay una razón por la que SSL utiliza cifrados simétricos para la carga útil real de la conexión.

Answer 6

¿Qué tal configurar un caché de servidor en el servidor de aplicaciones detrás del componente que cifra las respuestas https?Esto puede resultar ú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)