Al recibir un mensaje ClientHello , la mayoría de las veces un servidor web (y sin autenticar al cliente) realiza una operación modular exponencial diferencial de hellie para calcular y guardar el f = g^a mod p que se comunicaría al cliente en su mensaje ServerKeyExchange . ¿No hace eso que el servidor sea vulnerable a los ataques DDoS? ¿Implementa el protocolo un mecanismo para mitigar este tipo de ataques?
Si bien hay una sobrecarga en esos cálculos, esto generalmente no es un problema, ya que los ataques DDoS tienden a exceder las capacidades de la interfaz de red antes de que la RAM o la CPU se vean superadas por los cálculos de reconocimiento de TLS.
Los cálculos realizados para un sitio web dinámico de vanguardia y regular entregado a través de HTTP superan los cálculos de reconocimiento de TLS en al menos un orden de magnitud. Por lo tanto, contar con las conexiones TLS abiertas DDoS-ing a un servidor web parece algo superficial. Sí, hay algunos gastos generales, sí, ocupa recursos, pero no lo suficiente como para detener la (s) máquina (s). Solo hacer que las máquinas entreguen el contenido puede ser mucho peor.
Además, de esta manera, los métodos de amplificación DDoS no se pueden utilizar: atacar directamente a la conexión de red es más prometedor, desde el punto de vista de los atacantes.
Un protocolo de enlace TLS es computacionalmente costoso en comparación con una simple conexión TCP. Y, para algunos sistemas de cifrado, el gasto es mayormente en el sitio del servidor, como se puede ver en el diagrama en enlace que muestra un factor de 25 para el intercambio de claves RSA con RSA-4096 o factor 7 para el intercambio de claves RSA con RSA-2048.
Esto se puede usar en ataques de DOS y también hay herramientas de denegación de servicio que intentan agregar aún más carga al servidor al hacer muchas renegociaciones dentro de una sola conexión TLS, aunque muchos servidores ahora limitan la cantidad de renegociaciones que se pueden hacer.
Por otro lado, este es solo uno de los varios ataques de DOS posibles en la capa de aplicación. Otros ataques, por ejemplo, implican simplemente llamar a una página que realiza búsquedas de bases de datos costosas y, por lo tanto, también vincula los recursos en el servidor. Existen mitigaciones posibles, como limitar la cantidad de conexiones TCP, emplear certificados y cifrados que se basan en recursos o similares. Pero, es imposible detener estos ataques por completo, ya que no siempre son distinguibles de las solicitudes válidas, como en el caso del efecto slashdot .