Justo cuando estaba pensando que era una lástima que uno de los oradores que más me gustaba de estos congresos era Dan Kaminsky he estado en la charla de djb, Daniel J Bernstein, que propone una aproximación a la seguridad en internet enteramente opuesta a la que proponía Dan el año pasado.
Y cuando digo que es opuesta es que la mitad de la charla ha sido para apuntar todos los problemas que presentaría añadir más seguridad a Internet mediante DNSSEC:
- Para empezar, el hecho de que los servidores DNSSEC incluyan certificados en sus respuestas en lugar de lo que habitualmente responde un servidor de DNS (direcciones), hace que los paquetes de respuesta sean mucho más grandes que las preguntas. ¿Es esto un problema? En sí no lo es, pero resulta que (por ahora) es fácilmente explotable para crear denegaciones de servicio, ya que si se falisfica la dirección origen, se puede hacer que el servidor envíe hacia la víctima un tráfico mucho mayor del que dispone el atacante (factor de amplificación: entre 30x y 50x). Y según cálculos que ha mostrado en la charla, la implantación de DNSSEC está teniendo un éxito relativo y ha crecido el último año hasta llegar a 2,5k servidores (una gota de agua, todavía) que conjuntamente podrían conseguir un tráfico de 10-40 Gb/s. Esto da por supuesto que los propietarios de los servidores no tienen ningún tipo de protección y que se puede suplantar la dirección origen... algo que cada vez es más difícil en las redes comerciales.
- Muchas implantaciones de DNSSEC son más bien de cara a la galería, por ejemplo .org ya tiene DNSSEC, pero fundamentalmente es para decir que ninguno de sus dominios de siguiente nivel (cita por ejemplo wikipedia.org) está realmente firmado.
- Las respuestas de DNSSEC son seguras porque están precalculadas "offline" y por tanto son estáticas, pero la web es dinámica (por ejemplo para balancear el tráfico) y por tanto difícil de firmar. Esto mismo hace que sea una pesadilla actualizar los certificados de una raíz.
Pero directamente a la propuesta: el uso de criptografía de clave pública de 256 bits mediante curvas elípticas. Resulta que este cifrado ha mantenido su complejidad desde 1985, a diferencia de otros tipos cuyos ataques se han ido simplificando con el tiempo (RSA, MD5, DES...). Además ya existen implementaciones con gran capacidad: djb cita que esa implementación es capaz de crear 10M de pares clave pública/privada (la operación más compleja de los cifrados con clave pública) en 10 minutos.
Nota al margen: dentro de sus argumentos para identificar qué es seguro o no, djb pone el límite de lo que es alcanzable hoy en día en 2^80 operaciones, que estima que son 2048 tarjetas gráficas calculando durante un año, o una pequeña botnet utilizada únicamente para criptografía... Pero eso quizá será el tema de otra charla.
Utilizando por tanto el hipotético protocolo CurveCP, basado en UDP, con cada paquete cifrado independientemente y con el control de flujo en la parte cifrada (reimplementando TCP pero protegido), se tendría por fin una Internet segura (confidencial, íntegra y disponible, que son los tres atributos que djb propone como básicos para la seguridad de las comunicaciones).
Como en realidad además hay que arrancar de alguna manera, propone añadir una modificación de este protocolo al DNS, el DNSCurve, de modo que con el mismo tipo de cifrado se puedan conseguir transacciones DNS seguras. Eso sí, para la raíz y por ejemplo .com propone que quizá no sea la mejor idea tener un único certificado para proporcionar redundancia...
Hay que aceptar que djb es casi tan buen orador como Kaminsky, pero en realidad el tiempo y las implementaciones dirán si su idea es práctica. Aunque sea más segura, su impacto en la red es mucho mayor, ya que no hay reemplazar sólo el DNS sino prácticamente todo el tráfico de Internet... que es precisamente el título de la charla.
No hay comentarios:
Publicar un comentario