Cifrados disponibles en los dispositivos NetScaler

El dispositivo NetScaler se entrega con un conjunto predefinido de grupos de cifrado. Para usar cifrados que no forman parte del grupo de cifrado DEFAULT, debe vincularlos explícitamente a un servidor virtual SSL. También puede crear un grupo de cifrado definido por el usuario para enlazar al servidor virtual SSL. Para obtener más información sobre la creación de un grupo de cifrado definido por el usuario, consulte Configurar grupos de cifrado definidos por el usuario en el dispositivo ADC.

Notas

• A partir de la versión 13.0 compilación 71.x y versiones posteriores, la aceleración de hardware TLS1.3 es compatible con las siguientes plataformas:

  • MPX 5900
  • MPX/SDX 8900
  • MPX/SDX 9100
  • MPX/SDX 15000
  • MPX/SDX 15000-50G
  • MPX/SDX 16000
  • MPX/SDX 26000
  • MPX/SDX 26000-50S
  • MPX/SDX 26000-100G

  - La compatibilidad con solo software para el protocolo TLSV1.3 está disponible en todos los demás dispositivos NetScaler MPX y SDX, excepto los dispositivos NetScaler FIPS.

• TLSV1.3 solo es compatible con el perfil mejorado. Para habilitar el perfil mejorado, consulte Habilitar el perfil mejorado.

• Para utilizar TLS1.3, debe utilizar un cliente que cumpla con la especificación RFC 8446.

• El cifrado RC4 no se incluye en el grupo de cifrado predeterminado del dispositivo NetScaler. Sin embargo, es compatible con el software de los dispositivos basados en N3. El cifrado RC4, incluido el apretón de manos, se realiza en el software.

• Citrix recomienda no utilizar este cifrado porque RFC 7465 lo considera inseguro y está obsoleto.

• Utilice el comando “show hardware” para identificar si su dispositivo tiene chips N3.

sh hardware

Platform: NSMPX-22000 16*CPU+24*IX+12*E1K+2*E1K+4*CVM N3 2200100

Manufactured on: 8/19/2013

CPU: 2900MHZ

Host Id: 1006665862

Serial no: ENUK6298FT

Encoded serial no: ENUK6298FT
<!--NeedCopy-->

• Para mostrar información sobre los conjuntos de cifrado enlazados de forma predeterminada en el front-end (a un servidor virtual), escriba: sh cipher DEFAULT
• Para mostrar información sobre los conjuntos de cifrado enlazados de forma predeterminada en el back-end (a un servicio), escriba: sh cipher DEFAULT_BACKEND
• Para mostrar información sobre todos los grupos de cifrado (alias) definidos en el dispositivo, escriba: sh cipher
• Para mostrar información sobre todos los conjuntos de cifrado que forman parte de un grupo de cifrado específico, escriba: sh cipher <alias name>. Por ejemplo, el cifrado sh ECDHE.

En los siguientes vínculos se enumeran los conjuntos de cifrado admitidos en diferentes plataformas NetScaler y en módulos de seguridad de hardware (HSM) externos:

• DispositivoNetScaler MPX/SDX Intel Lewisburg: compatibilidad con cifrado en un dispositivobasado en chip SSL NetScaler MPX/SDX Intel Lewisburg
• DispositivoNetScaler MPX/SDX (N3): compatibilidad con cifrado en un dispositivoNetScaler MPX/SDX (N3)
• DispositivoNetScaler MPX/SDX Intel Coleto: compatibilidad con cifrado en un dispositivobasado en chip NetScaler MPX/SDX Intel Coleto SSL
• Dispositivo NetScaler VPX: compatibilidad con cifrado en un dispositivo NetScaler VPX
• DispositivoFIPS NetScaler MPX/SDX 14000: compatibilidad con cifrado en un dispositivoFIPS NetScaler MPX/SDX 14000
• HSM externo (Thales/Safenet): cifrado compatible con un HSM externo (Thales/Safenet)
• Dispositivos NetScaler VPX FIPS y MPX: soporte de cifrado en dispositivos NetScalerVPX FIPSy MPX FIPS

Nota:

Para obtener compatibilidad con cifrado DTLS, consulte Compatibilidad con cifrado DTLS en dispositivos NetScaler VPX, MPX y SDX.

Tabla1: Soporte en servidor virtual/servicio frontend/servicio interno:

Tabla 2: Soporte en servicios de backend:

Para obtener la lista detallada de los cifrados ECDSA compatibles, consulte Compatibilidad con ECDSA Cipher Suites.

Notas

• El conjunto de cifrado TLS-Fallback_SCSV se admite en todos los dispositivos desde la versión 10.5 compilación 57.x

• La compatibilidad con HTTP Strict Transport Security (HSTS) se basa en directivas.

• Todos los certificados firmados SHA-2 (SHA256, SHA384, SHA512) se admiten en el front-end de todos los dispositivos. En la versión 11.1 compilación 54.x y posteriores, estos certificados también se admiten en el back-end de todos los dispositivos. En la versión 11.0 y anteriores, solo los certificados firmados SHA256 se admiten en el back-end de todos los dispositivos.

• En la versión 11.1 compilación 52.x y versiones anteriores, los siguientes cifrados solo se admiten en el front-end de los dispositivos FIPS MPX 9700 y MPX/SDX 14000:
  • TLS1.2-ECDHE-RSA-AES-256-SHA384
  • TLS1.2-ECDHE-RSA-AES256-GCM-SHA384 From release 11.1 build 53.x, and in release 12.0, these ciphers are also supported on the back end.
• Todos los cifrados ChaCha20-Poly1035 utilizan una función pseudo aleatoria TLS (PSF) con la función hash SHA-256.

Secrecía de avance perfecto (PFS)

Perfect Forward Secrecy garantiza la protección de las comunicaciones SSL actuales incluso si la clave de sesión de un servidor web se ve comprometida en un momento posterior.

¿Por qué necesitas Perfect Forward Secrecy (PFS)?

Se utiliza una conexión SSL para proteger los datos que se transmiten entre un cliente y un servidor. Esta conexión comienza con el protocolo de enlace SSL que tiene lugar entre el explorador web de un cliente y el servidor web contactado. Durante este apretón de manos, el explorador y el servidor intercambian cierta información para llegar a una clave de sesión que sirve de medio para cifrar los datos durante el resto de la comunicación.

RSA es el algoritmo más utilizado para el intercambio de claves. El explorador web utiliza la clave pública del servidor para cifrar y enviar el secreto premaestro a un servidor. Este secreto previo al maestro se utiliza para llegar a la clave de sesión. El problema en el enfoque de intercambio de claves RSA es que si un atacante logra obtener la clave privada del servidor en cualquier momento en el futuro, el atacante obtiene el secreto premaestro con el que se puede obtener la clave de sesión. Ahora el atacante puede usar esta clave de sesión para descifrar todas las conversaciones SSL. Como resultado, su comunicación SSL histórica que antes era segura ya no es segura porque la clave privada robada del servidor se puede usar para llegar a la clave de sesión y, por lo tanto, descifrar cualquier conversación histórica guardada también.

La necesidad es poder proteger la comunicación SSL pasada incluso si la clave privada del servidor se ha visto comprometida. La configuración de Perfect Forward Secrecy (PFS) ayuda a solucionar este problema.

¿Cómo ayuda PFS?

PFS protege la comunicación SSL anterior haciendo que el cliente y el servidor acuerden una nueva clave para cada sesión y manteniendo en secreto el cálculo de esta clave de sesión. Funciona sobre la base de que el compromiso de una clave de servidor no debe dar lugar a comprometer la clave de sesión. La clave de sesión se deriva por separado en ambos extremos y nunca se transfiere a través del cable. Las claves de sesión también se destruyen una vez finalizada la comunicación. Estos hechos garantizan que, incluso si alguien obtiene acceso a la clave privada del servidor, no pueda llegar a la clave de sesión. Por lo tanto, no podrían descifrar los datos anteriores.

Explicación con ejemplo

Supongamos que estamos mediante DHE para obtener PFS. El algoritmo DH garantiza que, aunque un hacker obtenga la clave privada del servidor, el hacker no pueda llegar a la clave de sesión. La razón es que la clave de sesión y los números aleatorios (utilizados para llegar a la clave de sesión) se mantienen en secreto en ambos extremos y nunca se intercambian por cable. El PFS se puede lograr mediante el intercambio de claves Ephemeral Diffie-Hellman, que crea nuevas claves temporales para cada sesión SSL.

La otra cara de crear una clave para cada sesión es que requiere un cálculo adicional. Sin embargo, este problema se puede superar mediante el uso de la curva elíptica, que tiene tamaños de clave más pequeños.

Configuración de PFS en el dispositivo NetScaler

PFS se puede configurar en un NetScaler configurando los cifrados DHE o ECDHE. Estos cifrados garantizan que la clave de sesión secreta creada no se comparta en el cable (algoritmo DH) y que la clave de sesión permanezca activa solo durante un breve período de tiempo (efímero). Ambas configuraciones se explican en las secciones siguientes.

Nota: El uso de cifrados ECDHE en lugar de DHE hace que la comunicación sea más segura con tamaños de clave más pequeños.

Configurar DHE mediante la GUI

1. Genere una clave DH.

   a. Vaya a Administración del tráfico > SSL > Herramientas.

   b. Haga clic en Crear clave Helman Diffie (DH).

   Nota: La generación de una clave DH de 2048 bits puede tardar hasta 30 minutos.

2. Habilite DH Param para el servidor virtual SSL y adjunte la clave DH al servidor virtual SSL.

   a. Vaya a Configuración > Administración del tráfico > Servidores virtuales.

   b. Seleccione el servidor virtual en el que quiere habilitar DH.

   c. Haga clic en Modificar, en Parámetros SSLy, a continuación, en Habilitar parámetro DH.

3. Enlazar los cifrados DHE al servidor virtual.

   a. Vaya a Configuración > Administración del tráfico > Servidores virtuales.

   b. Seleccione el servidor virtual en el que quiere habilitar DH y haga clic en el icono del lápiz para modificarlo.

   c. En Configuración avanzada, haga clic en el icono más junto a Cifrados SSL y seleccione los grupos de cifrado DHE y haga clic en Aceptar para vincular.

   Nota: Asegúrese de que los cifrados DHE estén en la parte superior de la lista de cifrado enlazada al servidor virtual.

Configurar ECDHE mediante la GUI

1. Enlazar las curvas ECC al servidor virtual SSL.

   a. Vaya a Configuración > Administración del tráfico > Equilibrio de carga > Servidores virtuales.

   b. Seleccione el servidor virtual SSL que quiere modificar, haga clic en Curva ECC y, a continuación, en Agregar enlace.

   c. Enlazar la curva ECC requerida al servidor virtual.

2. Enlazar los cifrados ECDHE al servidor virtual.

   a. Vaya a Configuración > Administración del tráfico > Servidores virtuales y seleccione el servidor virtual en el que quiere habilitar DH.

   b. Haga clic en Modificar > Cifrados SSL, seleccione los grupos de cifrado ECDHE y haga clic en Enlazar.

   Nota: Asegúrese de que los cifrados ECDHE estén en la parte superior de la lista de cifrados enlazados al servidor virtual.

Nota: Para cada caso, compruebe que el dispositivo NetScaler admite los cifrados que quiere utilizar para la comunicación.

Configurar PFS mediante un perfil SSL

Nota: La opción de configurar PFS (cifrado o ECC) mediante un perfil SSL se introduce a partir de la versión 11.0 64.x en adelante. Ignore la siguiente sección si se encuentra en versiones anteriores.

Para habilitar PFS mediante un perfil SSL, es necesario realizar una configuración similar (como se explica en secciones de configuración anteriores) pero en el perfil SSL en lugar de configurarla directamente en un servidor virtual.

Configurar PFS mediante un perfil SSL mediante la GUI

1. Enlazar las curvas ECC y los cifrados ECDHE en el perfil SSL.

   Nota: Las curvas ECC ya están enlazadas de forma predeterminada a todos los perfiles SSL.

   a. Vaya a Sistema > Perfiles > Perfiles SSL y elija el perfil en el que quiere habilitar PFS.

   b. Enlazar los cifrados ECDHE.

2. Enlazar el perfil SSL al servidor virtual.

   a. Vaya a Configuración > Administración del tráfico > Servidores virtuales y seleccione el servidor virtual.

   b. Haga clic en el icono del lápiz para modificar el perfil SSL.

   c. Haga clic en Aceptar y en Listo.

Configurar PFS mediante SSL mediante la CLI

En la línea de comandos, escriba:

1. Enlazar curvas ECC al perfil SSL.

   bind sslprofile <SSLProfileName> -eccCurveName <Name_of_curve>
   <!--NeedCopy-->
   

2. Enlazar el grupo de cifrado ECDHE.

   bind sslprofile <SSLProfileName> cipherName <ciphergroupName>
   <!--NeedCopy-->
   

3. Establezca la prioridad del cifrado ECDHE como 1.

   set sslprofile <SSLProfileName> cipherName <ciphergroupName> cipherPriority <positive_integer>
   <!--NeedCopy-->
   

4. Enlazar el perfil SSL al servidor virtual.

   set SSL vserver <vservername> sslProfile <SSLProfileName>
   <!--NeedCopy-->