02 septiembre 2010

Optimización de Mod_SSL

Afortunadamente, cada vez mas se está tomando en cuenta que determinados procesos realizados a través de la web estén lo suficientemente protegidos como para evitar que puedan ser comprometidos por cualquiera que comparta el canal donde estemos realizando la operación. Con el advenimiento del 'siempre conectado', las redes wifi abiertas, disponibilidad de internet en  hoteles y un largo etc se ha hecho necesario que cualquier proceso de identificación esté cifrado bajo SSL.

El 'problema' de usar SSL es que implementarlo de forma masiva supone dimensionar correctamente la carga extra computacional que conllevan las operaciones de cifrado. Evidentemente existen soluciones como los 'aceleradores criptográficos' que aligeran bastante la carga, no obstante, mod_ssl se puede 'tunear' de forma que sea mas óptimo. Con idea de hacer una pequeña checklist de tips para optimizar mod_ssl encontré un artículo bastante bueno que merece la pena resumir y traducir. Evidentemente estamos hablando de optimizar no de fortificar (difiere en el sentido que el objetivo no es proteger el webmail de Barack Obama, el objetivo es llegar a un compromiso de seguridad / desempeño a gran escala)

Longitud de clave en los certificados: Tal vez de los tips mas obvios: dimensiona la longitud de la clave en tu certificado en función de lo que vayas a proteger. Es obvio que un tamaño de 1024 en un banco suena a poco (máxime cuando ya se empieza a desaconsejar ese tamaño de clave), por otra parte, si lo que pretendes proteger es el acceso a un foro, una longitud de 2048 le dará una carga extra de trabajo a tu/s servidores que puedes ahorrarte.

Elección de algoritmos de cifrado y hash: La elección de tus algoritmos de cifrado puede suponer un desempeño de hasta tres veces mas óptimo si, por ejemplo, empleas RC4 en vez de AES-256. Obviamente RC4 es un algoritmo, a estas alturas, muy cuestionado y se debería usar para procesos donde la información NO sea crítica.

Para configurar mod_ssl empleando RC4-SHA como primera opción y AES128-SHA como segunda, debemos configurar las siguientes directivas:
SSLCipherSuite RC4-SHA:AES128-SHA:ALL:!ADH:!EXP:!LOW:!MD5:!SSLV2:!NULL
SSLHonorCipherOrder on
Es importante definir la directiva SSLHonorCipherOrder para especificar que, 'quien manda', es el servidor y no el cliente (lo habitual es que sea el cliente quien defina la suite de algoritmos)

Elección del tipo de cache para sesiones SSL: Normalmente cuando se carga una web, debido a lo ricas en contenido que suelen ser, no se hace en un simple GET, lo normal es lanzar varias peticiones en paralelo contra el servidor. La forma en la que funciona Apache, con sus procesos 'forkeados' provoca que al servir una pagina web en varias peticiones paralelas bajo SSL se necesite una forma en la que cada proceso tenga acceso a la sesión SSL ya negociada (evitando así un montón de nuevas negociaciones SSL), para eso implementa un sistema de 'cache' que admite diferentes tipos de almacenamiento (dbm y shm). shm es notablemente mas rápido así que esa debería ser la elección.

Para configurar mod_ssl empleando caché de sesiones con shm configuramos la directiva así:
SSLSessionCache shm:/usr/local/apache/logs/ssl_gcache_data(512000)
A la hora de elegir la ruta del fichero-cache hay que tener la precaución de que el fichero tenga los permisos correctos y no sea 'leible' por cualquier usuario.

Activación de OCSP Stapling: Este tip será probablemente del que menos beneficio vamos a obtener. Para dar contexto al tema, digamos que cuando un servidor web te ofrece un certificado SSL, tu navegador debería contactar con el servidor OCSP de la CA que emitió ese certificado y preguntar si ha sido revocado. En la práctica casi nadie lo hace (Firefox tiene la opción pero está desactivada por defecto). Como es de imaginar, si añadimos el punto extra de tener que contactar con el servidor OCSP y pedir una validación, esto nos va a suponer un buen número de segundos extra hasta que la negociación SSL inicial se completa. Para mitigar esto surge OCSP Stapling que, básicamente, lo que hace es almacenar una petición OCSP reciente y anidarla en la negociación SSL, de forma que el cliente, como parte de la información que le suministra el servidor, conoce que ese certificado ha sido validado hace relativamente poco tiempo, ahorrando de esa forma que el cliente tenga que lanzar la petición por su cuenta.

Para configurar OCSP Stapling debemos añadir las siguientes directivas:
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling_cache(128000)"
Una vez hecho esto y re-iniciado el servidor web, es muy deseable comprobar con el comando:
openssl s_client -host www.miweb.com -port 443 -tls1 -tlsextdebug -status
que obtenemos una respuesta positiva y que las peticiones al servidor OCSP están funcionando. Así mismo con el comando:
openssl s_client -debug -tls1 -host www.miweb.com -port 443
podemos ver si la elección del algoritmo de cifrado está funcionando correctamente.

[*] El artículo original en inglés con mas tips e ideas

7 comments :

tmeto dijo...

Soy yo o la mitad del articulo esta en un tipo de fuente y la otra mitad en otra?? Mas que ná porque la segunda fuente es muy pequeña y siento las dioptrias corriendo por mis ojos...

Saludos!

reverseskills dijo...

Muy util, para la proxima tal vez puedas añadir los aceleradores por Hardware :-).

José A. Guasch dijo...

@tmeto, gracias por avisar, ¡corregido queda!

Anónimo dijo...

Primero, me ha llamado la atención lo de "Activación de OCSP Stapling". La gracia de la verificación OCSP es que una tercera parte de confianza me asegure que el certificado no está revocado. Igual no lo he entendido bien pero da la impresión de que con esta técnica el cliente se fía de lo que le diga el servidor (imaginemos un certificado comprometido instalado en un servidor fraudulento pero revocado por su propietario legítimo).

Por otro lado, no quiero ser puntilloso pero me ha dolido: leíble -> legible.

Yago Jesus dijo...

@Anónimo, Interesante apreciación, precisamente si ojeas el enlace de la Wiki sobre OCSP Stapling, verás que la parte de 'ya esta comprobado' que envía el servidor viene firmada por la CA que emitió el certificado, no por el 'poseedor', cito: 'It may appear that allowing the site operator to control verification responses introduces an opportunity for fraud. Since the response is signed by the certificate authority, not the certificate holder, though, and since lack of a valid stapled response will just cause the client to ask the OCSP server directly, there is actually no increased risk with this approach'.

Respecto a lo de leíble VS legible, 'leíble' es un 'wrapper' de legible http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=leible si he usado ese término es porque me parece mas aproximado a 'Read' (por aquello de los permisos read / write / execute). Cuestión de gustos :P

Anónimo dijo...

Sobre lo de "leíble", pensaba que era incorrecto. Me suena extraño pero si lo dice la RAE ... siento la corrección indebida.

Sobre el tema en sí, entiendo. No había leído la entrada de la wikipedia.

Anónimo dijo...

Yo me he pasado toda la mañana buscando como actualizar el mod_ssl manteniendo la versión de apache, al final lo he encontrado:

http://andrade.blogaliza.org/2010/11/04/upgrade-mod_ssl-version-on-solaris-10/