A finales de la semana pasada, el Grupo de Trabajo de Ingeniería de Internet (Internet Engineering Task Force, IETF) aprobó una corrección en un protocolo que salvaguarda las transacciones y comunicaciones más delicadas por internet. Sin embargo los expertor creen que se tardará un año antes de que la corrección se aplicada completamente.

El parche repara un fallo en el protocolo que cifra comunicaciones delicadas, entre las que se incluyen la mayoría de las transacciones de bancos y tarjetas de crédito. Repara el protocolo Transport Layer Security (TLS), que ha sucedido al protocolo Secure Socket layer (SSL). TLS está incluido en los navegadores y servidores web, y protege la información de alto valor.

El fallo actual, descubierto por Marsh Ray y Steve Dispensa en una compañía de autenticación con sede en Kansas llamada Phone Factor, da al atacante la capacidad de secuestrar el primer momento de la conversación cifrada entre el navegador web y el servidor web. Esto permite al atacante añadir un comando propio, que podría ser tan grave como el hecho de sacar dinero de la cuenta de la víctima. Un investigador de seguridad demostró el ataque en Twitter, mostrando que el fallo se podía usar para forzar al servidor a que revelase la palabra clave de un usuario.

“La razón por la que resulta tan chocante es porque en realidad es un fallo del TLS, o al menos eso parece,” afirma Eric Rescorla, consultor de seguridad en una compañía llamada RTFM y uno de los autores del borrador del parche del protocolo. Rescorla afirma que el fallo muestra lo sumamente difícil que es diseñar protocolos de seguridad para internet.

Para poder aprovecharse del fallo, el atacante tendría primero que configurar “un ataque hombre-en-medio” e interceptar el tráfico entre el cliente y el servidor. Esto podría hacerse mediante el secuestro de un servidor particular en intenet, por ejemplo.

El atacante después podría aprovecharse de una característica de TLS llamada “renegociación,” que permite al servidor web o al cliente cambiar algunos de los parámetros de una sesión cifrada al mismo tiempo que dicha sesión está sucediendo. Dispensa explica que el protocolo no se asegura de que las partes comunicantes después de la renegociación sean las mismas que antes.

Ray y Dispensa admiten que el aprovechamiento del fallo requeriría unas dotes técnicas considerables, aunque afirman que es significativo puesto que afecta a los servidores y a los clientes incluso si han implementado el protocolo perfectamente. “Está bastante claro que nadie entendió esta propiedad del TLS,” afirma Rescorla.

Frank Breedijk, profesional de la seguridad en un proveedor de servicios de outsourcing de importancia crítica para misiones llamado Schuberg Philis, con sede en los Países Bajos, afirma que el borrador de Rescorla arregla el protocolo, aunque señala que crea dos versiones efectivas del TLS. Si tanto el cliente como el servidor no han instalado aún el parche, afirma, el ataque aún es posible. “Los clientes y servidores TSL/SSL son omnipresentes,” afirma. “No se trata sólo de los navegadores y los servidores web. Los teléfonos móviles, los puntos de acceso inalámbricos, los teléfonos DECT, los sistemas de seguridad en el hogar, etcétera, todos tienen la tecnología instalada.”

“Si crees que necesitas el SSL, entonces tienes que tenerlo arreglado,” afirma Ben Laurie, director y fundador de la Apache Software Foundation y desarrollador de OpenSSL.

Puede que, sin embargo, sea más fácil decirlo que hacerlo.

Ray y Dispensa informaron acerca del fallo a los fabricantes afectados a finales de septiembre, y Lauria afirma que ha sido “muy sencillo” escribir el software capaz de arreglarlo. Lo que ha sido difícil, señala, es hacer que el parche se instale en todos los sitios donde tiene que ser instalado. El arreglo “no tiene precedente,” afirma Laurie, puesto que nadie está completamente protegido hasta que tanto el cliente como el servidor hayan instalado el parche. Como resultado, los fabricantes de navegadores que se hayan puesto manos a la obra para solucionar el problema puede que tengan que permitir que durante un periodo de tiempo el cliente siga comunicándose con servidores sin parche y, posiblemente, vulnerables.

“No puedes hacer que el cliente diga, ‘Este servidor es viejo y es maligno, no me voy a conectar a él,’ puesto que eso haría que el mundo entero se fracturase,” afirma Laurie. Esto significa que se tendrá que aplicar un segundo parche a los clientes más tarde, cuando los expertos determinen que una cantidad suficiente de servidores han sido parcheados.

El proceso de salida de todos los parches es lo suficientemente complejo como para que Joe Salowey, copresidente del grupo de trabajo TLS y líder técnico de Cisco Systems, crea que pasará un año o más antes de que el arreglo se adopte de forma total.