0

Tuning IHS: Rendimiento SSL

Cifrados

Cuando se establece una conexión SSL, el cliente (navegador) y el servidor web negocian el cifrado que se usará en la conexión. El servidor dispone de una lista de cifrados ordenada por prioridad, de modo que el primer cifrado soportado por el navegador será el usado en la comunicación.

Por defecto, nuestro IHS prefiere cifrados AES y RC4 antes que el 3DES, que necesita más CPU para procesarse. Generalmente no hay que tunear las directivas SSL para mejorar el rendimiento.

Los cifrados SSL soportados por el IHS son los siguientes:

SSL V2:

N. Corto Nombre Largo Significado Fuerza
========= ======== ============= ========
27 SSL_DES_192_EDE3_CBC_WITH_MD5 Triple-DES (168 bit) (fuerte)
21 SSL_RC4_128_WITH_MD5 RC4 (128 bit)
23 SSL_RC2_CBC_128_CBC_WITH_MD5 RC2 (128 bit) |
26 SSL_DES_64_CBC_WITH_MD5 DES (56 bit) V
22 SSL_RC4_128_EXPORT40_WITH_MD5 RC4 (40 bit)
24 SSL_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 RC2 (40 bit) (débil)

SSL V3 y TLSV1:

N. Corto Nombre Largo Significado Fuerza Compat
========= ======== ============= ======== ======
9D TLS_RSA_WITH_AES_256_GCM_SHA384 AES SHA2 (256-bit) (fuerte) v8 y sucesivas
3D TLS_RSA_WITH_AES_256_CBC_SHA256 AES SHA2 (256-bit) | v8 y sucesivas
9C TLS_RSA_WITH_AES_128_GCM_SHA256 AES SHA2 (128-bit) | v8 y sucesivas
3C TLS_RSA_WITH_AES_128_CBC_SHA256 AES SHA2 (128-bit) | v8 y sucesivas
3A SSL_RSA_WITH_3DES_EDE_CBC_SHA Triple-DES SHA (168 bit) |
35b TLS_RSA_WITH_AES_256_CBC_SHA AES SHA (256 bit) |
35 SSL_RSA_WITH_RC4_128_SHA RC4 SHA (128 bit) |
34 SSL_RSA_WITH_RC4_128_MD5 RC4 MD5 (128 bit) |
2F TLS_RSA_WITH_AES_128_CBC_SHA AES SHA (128 bit) | v8 y sucesivas
39 SSL_RSA_WITH_DES_CBC_SHA DES SHA (56 bit) |
62 TLS_RSA_EXPORT1024_WITH_RC4_56_SHA RC4 SHA(56 Bit) |
64 TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA DES SHA(56 Bit) V
33 SSL_RSA_EXPORT_WITH_RC4_40_MD5 RC4 MD5 (40 bit)
36 SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 RC2 MD5 (40 bit) (débil)
32 SSL_RSA_WITH_NULL_SHA
31 SSL_RSA_WITH_NULL_MD5
30 SSL_NULL_WITH_NULL_NULL

Aprobado por FIPS: NIST SSLV3 and TLSV1:

N. Corto Nombre Largo Significado
========= ======== =============
3A SSL_RSA_WITH_3DES_EDE_CBC_SHA Triple-DES SHA (168 bit)
35b TLS_RSA_WITH_AES_256_CBC_SHA AES SHA (256 bit)
2F TLS_RSA_WITH_AES_128_CBC_SHA AES SHA (128 bit)

Aprobado por FIPS: NIST TLSV12 (V8 y sucesivas):

N. Corto Nombre Largo Significado
========= ======== =============
3A SSL_RSA_WITH_3DES_EDE_CBC_SHA Triple-DES SHA (168 bit)
9D TLS_RSA_WITH_AES_256_GCM_SHA384 AES SHA2 (256-bit)
3D TLS_RSA_WITH_AES_256_CBC_SHA256 AES SHA2 (256-bit)
9C TLS_RSA_WITH_AES_128_GCM_SHA256 AES SHA2 (128-bit)
3C TLS_RSA_WITH_AES_128_CBC_SHA256 AES SHA2 (128-bit)

La siguiente configuración obliga al servidor a preferir cifrados de 128 bit RC4 (fuerte) y producirá una mejora en el rendimiento respecto a la configuración por defecto. Esta configuración no soporta cifrados débiles como 40 bit, 56 bit o texto plano (o NULL).

El orden de las directivas SSLCipherSpec establece la prioridad de los cifrados, por lo que se puede ordenar de manera que el IHS prefiera aquellos que necesitan menos CPU. SSLv2 está desabilitada implícitamente al no incluir ningún cifrado de ese tipo.

<VirtualHost *:443>

SSLEnable
Keyfile keyfile.kdb

## Cifrados SSLv3 128 bit
SSLCipherSpec SSL_RSA_WITH_RC4_128_MD5
SSLCipherSpec SSL_RSA_WITH_RC4_128_SHA

## Aprobados por FIPS: SSLV3 y TLSv1 128 bit AES
SSLCipherSpec TLS_RSA_WITH_AES_128_CBC_SHA

## Aprobados por FIPS: SSLV3 y TLSv1 256 bit AES
SSLCipherSpec TLS_RSA_WITH_AES_256_CBC_SHA

## Cifrados Triple DES 168 bit
## Estos pueden usarse todavía, pero sólo en caso de
## que el cliente no soporte ninguno de los listados arriba.
SSLCipherSpec SSL_RSA_WITH_3DES_EDE_CBC_SHA

## El bloque a continucación excluye SSLv2. Si está presente
## la configuración SSLv3 arriba se deshabilita la SSLv2.

## descomentar para activar SSLv2 (con cifrado de 128 bit)
#SSLCipherSpec SSL_RC4_128_WITH_MD5
#SSLCipherSpec SSL_RC4_128_WITH_SHA
#SSLCipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5

</VirtualHost>

A partir de la v8 de IHS se soportan nuevos cifrados y nueva sintaxis para SSLCipherSpec para contemplar los nuevos cifrados TLS. Estas releases también favorecen el uso de cifrados robustos, pero también desabilitan por completo los cifrados más débiles.

Para configurar esos certificados más débiles en la v8:

SSLCipherSpec SSLv3 SSL_RSA_WITH_RC4_128_SHA SSL_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA

SSLCipherSpec TLSv10 SSL_RSA_WITH_RC4_128_SHA SSL_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA

SSLCipherSpec TLSv11 SSL_RSA_WITH_RC4_128_SHA SSL_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA

# TLSv12 deja de configurarse por defecto: TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA

Podemos usar la directiva LogFormat para ver la negocicación del cifrado SSL de cada conexión:

LogFormat “%h %l %u %t \”%r\” %>s %b \”SSL=%{HTTPS}e\” \”%{HTTPS_CIPHER}e\” \”%{HTTPS_KEYSIZE}e\” \”%{HTTPS_SECRETKEYSIZE}e\”” ssl_common

CustomLog logs/ssl_cipher.log ssl_common

La salida del log ssl_cipher.log será algo parecido a esto:

127.0.0.1 – – [18/Feb/2005:10:02:05 -0500] “GET / HTTP/1.1” 200 1582 “SSL=ON” “SSL_RSA_WITH_RC4_128_MD5” “128” “128”

Tamaño del certificado

El tamaña sí importa. Los certificados de servidor grandes son más costosos de procesar. Doblar el tamaño de las keys implica entre 4 y 8 veces más consumo de CPU para su proceso.

Por desgracia, no hay muchas opciones en cuanto al tamaño del certificado del servidor. Actualmente se están usando certificados de 2048 bits para evitar que la creciente potencia de las CPUs facilite los ataques por fuerza bruta a los SSL, pero todavía podemos utilizar algunos factores a nuestro favor para mejorar el rendimiento…

El mayor consumo de CPU se produce en la hora del handshake, cuando se crea la nueva sesión. El uso de keep-alive y la reutilización de sesiones SSL pueden ahorrarnos muchos recursos de máquina.

ThreadsPerChild (IHS 2 y superiores en Unix / Linux)

El consumo de CPU será más bajo si utilizamos valores pequeños en el ThreadsPerChild. Se recomienda un máximo de 100 si el servidor maneja mucho tráfico SSL, de forma que ese tráfico se soporte entre varios procesos hijo. Esto no se puede hacer en sistemas Windows, pues sólo soportan un proceso.

Ajuste de MALLOCMULTIHEAP en variables de entorno (IHS 2 y superiores en AIX)

Si la carga de tráfico SSL es elevada, ajustar el valor a true ayudará al heap con el procesamiento SSL.

Uso de aceleradores criptográficos

Desaconsejado su uso. La instalación y mantenimiento de tarjetas criptográficas es un proceso relativamente complejo y normalmente la reducción de uso de CPU es poca.

Keep-alive HTTP

El uso de keep-alive tiene mucho más sentido cuando trabajamos con SSL. Si nuestro objetivo es limitar el número de hilos que se utilizan para manejar el keep-alive, el rendimiento será mucho mejor si keep-alive está activado con un timeout pequeño que si está desactivado.

Ejemplo:

<VirtualHost *:443>
KeepAlive On
KeepAliveTimeout 1
</VirtualHost>

Un valor elevado de keep-alive resultaría en una ligera mejora a la hora de gestionar la sesión SSL, pero implicaría también utilizar un hilo por un periodo elevado de tiempo que no podría atender nuevas peticiones del servidor.

Lo mejor para configurar el timeout del keep-alive es observer cómo interactua nuestra aplicación con los navegadores de los clientes.

Balanceadores de carga

IHS no puede compartir un session ID cacheado entre máquinas. Esto implica que una sesión SSL sólo puede ser reutilizada si la siguiente petición TCP que realiza un cliente es enviada por el balanceador al mismo servidor web. Si va a otro servidor web, la sesión no puede ser reutilizada y hay que volver a generar la clave compartida para establecer la comunicación SSL, con el correspondiente gasto de CPU.

Debido a la importancia de reutilizar estas sesiones SSL, los balanceadores suelen tener la capacidad de establecer la afinidad entre un cliente y un servidor web concreto mientras dicho cliente intente reutilizar la sesión SSL, evitando de este modo la generación de las claves explicadas más arriba.

El cliente no sabrá si la sesión SSL está reutilizándose o no, a no ser que el consumo de CPU que implica la negociación SSL empiece a retrasar sus peticiones. Los administradores generalmente sólo se dan cuenta de esta situación cuando el consumo de CPU empieza a aproximarse al 100%, de modo que cuando se den ambos factores a la vez (alto consumo de CPU y afinidad de sesión no activada en el balanceador), conviene empezar a mirar por aquí.

Comprobar el reutilizamiento de sesiones SSL (IHS 6.0.2.1 en adelante)

[Sat Oct 01 15:30:17 2005] [info] [client 9.49.202.236] Session ID: YT8AAPUJ4gWir+U4v2mZFaw5KDlYWFhYyOM+QwAAAAA= (new)

[Sat Oct 01 15:30:32 2005] [info] [client 9.49.202.236] Session ID: YT8AAPUJ4gWir+U4v2mZFaw5KDlYWFhYyOM+QwAAAAA= (reused)

$ grep “Session ID.*reused” logs/error_log | wc -l 1115

$ grep “Session ID:.*new” logs/error_log | wc -l 163

El porcentaje de handshakes con consumo elevado de CPU en el ejemplo superior es de 12,8% (viene de dividir 163 entre la suma de todas las sesiones). Si realizamos un test de carga con y sin el balanceador activado podremos comparar estos porcentajes para ver si el balanceador está permitiendo la reutilización de sesiones SSL.

Limitar el tamaño de la caché de sesiones SSL

IHS utiliza un sistema externo de cache sin límite de sesions ID, a no ser que utilizemos windows o tengamos activada la directiva SSLCacheDisable en la configuración. En estos casos se utiliza la cache del GSKit, limitada a 512 entradas por defecto. Este límite se puede subir hasta 4095 al ajustar la variable de entorno GSK_V3_SIDCACHE_SIZE.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *