Una red de (des)confianza: Comodogate, parte II

Desde que publicamos la entrada del blog sobre el problema con las Autoridades de Certificación y los arreglos que se hicieron a los navegadores como consecuencia, el incidente pasó a llamarse “Comodogate”. Se ha publicado más información sobre el acontecimiento desde entonces. Hasta apareció una voz que se hizo responsable del ataque, describió su supuesto ataque y publicó una llave privada para demostrar su éxito.

El Director Ejecutivo de Comodo (la Autoridad de Certificación comprometida) lanzó muchas teorías para tratar de determinar a quién atribuir el ataque y sus motivaciones. Hasta llegó a compararlo y asociarlo con el reciente incidente de RSA, diciendo que se está atacando toda la capa de autentificación de Internet. Aunque el ataque a RSA podría provenir de una parte del mundo diferente (pero conectada), fue otro ataque a la confianza inherente en los servicios de autentificación y criptografía. Hay más de un fondo de verdad en esta afirmación.

Es fácil decir que los servicios de autentificación están siendo atacados en todo Internet. Es como decir que se están atacando los navegadores, es repetir lo obvio.

La voz que tomó el crédito por el ataque y del robo de certificados publicó la clave privada de uno de los certificados robados. Este es un dato que, además de la Autoridad de Certificación y los verdaderos desarrolladores, sólo el ladrón podría tener. Puedes verificar la clave tú mismo si sigues estas instrucciones (en inglés). El supuesto atacante realizó entrevistas anónimas y creó una cuenta de Twitter, desde donde respondió varias preguntas y tweets de todo tipo.

El autor a menudo habla de sí mismo. Es interesante escuchar su voz, porque se supone que el autor del ataque es el causante de la ruptura de la confianza fundamental en la autentificación y en Internet tal como lo conocemos. La voz suena como si el lector debiera confiar en el atacante. ¿Se podrá confiar en que este individuo es *sólo* el chico de 21 años que dice ser? ¿Por qué lo haríamos?

Al mismo tiempo, es bueno ver que el equipo de Mozilla está interesado en mejorar el uso de los certificados en su propio código. La empresa lanzó una respuesta completa al incidente de Comodo, en la que se incluyen refuerzos HSTS, OCSP, TOFU y, tal vez un poco tarde, DNSSEC, además de comentarios sobre mejoras a PKI.

Considerando que analistas como Moxie Marlinspike demostraron hace unos años en foros públicos que se pueden lanzar ataques MITM exitosos a SSL, uno habría imaginado que los desarrolladores de navegadores habrían tomado más en serio a SSL. ¿Hay alguna razón especial o necesidad para insertar con “hard-code” el código de certificados SSL en el código del navegador? ¿Cuán seguro te hace sentir eso?

Aquí puedes conseguir información actualizada sobre las políticas de las Autoridades de Certificación y de las Autoridades Root, muchas de las cuales, al parecer, no se respetaron en la relación de Comodo con sus afiliados italianos (GlobalTrust e Instant SSL.it), cuyas cuentas se encuentran suspendidas. Espero que esta discusión mejore el estado de la seguridad relacionada con SSL. Las comunicaciones confiables no se pueden basar en una implementación tan destruida como esta.