Cómo funciona la compresión SSL
La compresión SSL tiene acceso a los datos de texto claro de la conexión, ya que el dispositivo del lado del servidor actúa como delegado de seguridad de los servidores de extremo. Este comportamiento es posible porque el dispositivo del lado del servidor está configurado con copias de las credenciales de seguridad de los servidores (claves privadas y certificados), lo que le permite actuar en nombre de los servidores. Para el cliente, este comportamiento es equivalente a comunicarse directamente con el servidor de extremo.
Dado que el dispositivo funciona como delegado de seguridad del servidor, la mayor parte de la configuración se realiza en el dispositivo del servidor. El dispositivo del cliente (o complemento) actúa como satélite del dispositivo del servidor y no requiere configuración por servidor.
Los dispositivos del lado del servidor y del lado del cliente comparten el estado de la sesión a través de una conexión de señalización SSL. Todas las conexiones aceleradas entre los dos dispositivos se envían a través de conexiones de datos SSL, independientemente de que las conexiones originales estuvieran cifradas o no.
Nota: La compresión SSL no encripta necesariamente todo el tráfico de enlaces. El tráfico que se cifró originalmente permanece cifrado, pero el tráfico no cifrado no siempre está cifrado. Los dispositivos no intentan cifrar el tráfico no acelerado. Debido a que no hay ninguna garantía absoluta de que una conexión determinada se acelerará (varios eventos evitan la aceleración), no hay garantía de que los dispositivos cifrarán una conexión no cifrada determinada.
La compresión SSL funciona en uno de los dos modos: proxy transparente o proxy dividido. Estos dos modos admiten funciones SSL ligeramente diferentes. Seleccione el modo que proporciona las funciones que requiere una aplicación determinada.
Modo proxy SSL utilizar: Utilice el modo proxy transparente SSL solo si necesita autenticación de cliente real (es decir, autenticación que identifique correctamente al cliente de extremo individual) y no necesita entradas de sesión Diffie-Hellman, Temp RSA, TLS, SSL versión 2, o renegociación de sesión. Utilice el proxy dividido SSL para todas las demás implementaciones.
Proxy transparente SSL
En el modo proxy transparente SSL (que no debe confundirse con el modo transparente en Citrix SD-WAN WANOP Plug-in), el dispositivo del lado del servidor se hace pasar por el servidor. Las credenciales del servidor (par de certificados y claves) se instalan en el dispositivo del lado del servidor para que pueda actuar en nombre del servidor. A continuación, el dispositivo del lado del servidor configura el dispositivo del lado del cliente para controlar el extremo del cliente de la conexión. Las credenciales del servidor no están instaladas en el dispositivo del cliente.
En este modo se admite la autenticación de cliente verdadera, pero Temp RSA y Diffie-Hellman no lo son. El modo proxy transparente SSL es adecuado para aplicaciones que requieren autenticación de cliente, pero solo si no se requiere ninguna de las siguientes funciones: Diffie-Hellman, Temp RSA, tickets de sesión TLS, SSL versión 2. Además, no se debe intentar la renegociación de la sesión o la conexión termina.
No se requiere ninguna configuración en el dispositivo del cliente (aparte de configurar una relación de peering segura con el dispositivo del lado del servidor) y no se requiere ninguna configuración en el cliente, lo que trata la conexión exactamente como si se estuviera comunicando directamente con el servidor.
Proxy de división SSL
Elmodo proxy dividido SSL es preferido en la mayoría de las instancias, ya que soporta Temp RSA y Diffie-Hellman, que requieren muchas aplicaciones. En el modo proxy dividido SSL, el dispositivo del lado del servidor se hace pasar por un servidor para el cliente y como cliente para el servidor. Instalar credenciales de servidor (un par de claves de certificado) en el dispositivo del lado del servidor para que pueda actuar en nombre del servidor.
El modo de proxy dividido también admite la autenticación de cliente proxy si instala credenciales de cliente opcionales, que se presentan a la aplicación de servidor de extremo si solicita autenticación de cliente. Estas credenciales de cliente se presentarán en lugar de las credenciales reales del cliente de punto final. (Utilice proxy transparente si la aplicación requiere las credenciales del cliente de extremo).
Dado que la autenticación de cliente verdadero no se admite en este modo, el servidor no puede autenticar el cliente de extremo real. Si el dispositivo del lado del servidor no está configurado con credenciales de cliente, se producirá un error en todos los intentos de la aplicación del lado del servidor en la autenticación del cliente. Si el dispositivo del lado del servidor está configurado con credenciales de cliente, todas las solicitudes de autenticación del cliente se responderán con estas credenciales, independientemente de la identidad del cliente real.
No se requiere ninguna configuración en el dispositivo del cliente (aparte de configurar una relación de peering segura con el dispositivo del lado del servidor) y no se requiere ninguna configuración en el cliente, lo que trata la conexión como si se estuviera comunicando directamente con el servidor. Las credenciales del servidor en el dispositivo del servidor no están instaladas en el dispositivo del cliente.
Para admitir varios servidores, se pueden instalar varios pares privados de clave de certificado en el dispositivo, uno por perfil SSL. Las reglas SSL especiales en las definiciones de clase de servicio coinciden con los servidores con los perfiles SSL y, por lo tanto, los perfiles SSL con las credenciales.
En el modo proxy dividido SSL, los certificados de CA y los pares de clave de certificado y certificados de CA no tienen que coincidir con los de los servidores, aunque pueden hacerlo. Debido a la naturaleza de un proxy dividido, el dispositivo del lado del servidor puede utilizar credenciales aceptables para la aplicación cliente (credenciales válidas emitidas por una autoridad de confianza). Tenga en cuenta que, en el caso de conexiones HTTPS, los exploradores web emiten una advertencia si el nombre común no coincide con el nombre de dominio en la URL. En general, el uso de copias de las credenciales del servidor es la opción más libre de problemas.
