¿Cómo defenderse contra los ataques de agotamiento de SSL?

"Agotamiento SSL" es una expresión de aspecto medio para un ataque más genérico conocido como "no jugar bien". En términos generales, esto es así: un servidor está ofreciendo un servicio de red que, en el servidor, no es gratuito: cuando llega un cliente, el servidor debe invertir parte de sus preciosos ciclos de CPU para responder a ese cliente. El "atacante" es entonces alguien que imita a muchos clientes necesitados, sobrecargando el servidor. En el caso de SSL, la inversión es sustancial debido a la criptografía involucrada; pero el concepto también funciona cuando el esfuerzo del servidor es la escasa cantidad de CPU y RAM necesaria para establecer simplemente una conexión TCP (lo que se denomina inundación SYN , pero, desde un punto de vista de alto nivel, esto es lo mismo).

Una posible contramedida (no es posible en el caso de SSL tal como es, pero podría agregarse como parte de una modificación del protocolo) es requerir una "prueba de trabajo" del cliente. En SSL, es fácil imitar los pasos iniciales de una conexión de cliente sin hacer nada del trabajo criptográfico duro (simplemente envíe basura aleatoria en lugar de la clave pre-maestra cifrada RSA esperada, o la clave pública del cliente Diffie-Hellman): Esto es lo que se debe cambiar. Hay algunos consejos en la página de Wikipedia sobre ese tema.

Para SSL como se especifica y se implementa actualmente, no tiene más remedio que:

• intente identificar a los infractores con suficiente antelación, por ejemplo, demasiadas solicitudes de conexión repetidas desde la misma IP (esto significa que bloqueas DoS que no es DDoS - en palabras sencillas, el atacante deberá contratar subordinados / zombies);
• seleccione suites de cifrado que son "baratas" para el servidor (¡no use claves de gran tamaño! 1536 bits son suficientes) (pruebe RSA en lugar de DHE_RSA);
• contrarresta al atacante poniendo más músculo en él, por ejemplo. aceleradores de hardware, o más PC (la PC puede ser más barata, pero usa más espacio de alojamiento y el balanceo de carga requiere una administración adicional del sistema).

Creo que te perdiste el punto, la herramienta de THC no se trata de explotar sistemas. Se trata más de probar sus propios sistemas para asegurarse de que está seguro. Si está preocupado, lo primero que debe hacer es ejecutar THC-SSL-DOS contra su propio sistema para ver cuán sostenible es atacar . SSL no está roto, sigue siendo lo mejor que tenemos.

Las formas de mitigar este ataque son usar una suite de cifrado de peso ligero . Y como señaló Cisco recomienda usar un acelerador de hardware SSL ($$$) y deshabilitando la "renegociación segura" de ssl.