Llegamos a ustedes gracias a:



Reportajes y análisis

TLS 1.3: Seguridad vs. Visibilidad

Por qué tiene preocupados a los administradores de centros de datos

[09/04/2018] El protocolo TLS, que proporciona el cifrado que hace que las transacciones web seguras sean posibles, necesita urgentemente una actualización. La última vez que se lanzó una gran actualización fue cuando salió la versión 1.2 hace casi diez años, y el Grupo de trabajo de ingeniería de Internet (IETF, por sus siglas en inglés) ha llevado a cabo una revisión importante del estándar, que tiene como objetivo ofrecer una seguridad mejorada, entre otras cosas, descartando soporte para sistemas de encriptación heredados.

Solo hay un inconveniente: varios administradores de centros de datos de grandes corporaciones financieras, de atención médica y minoristas han comenzado a considerar el borrador actual de la versión 1.3 del protocolo con alarma creciente. Uno de los mecanismos clave de intercambio que se desprende del borrador del estándar RSA estático, es una herramienta crucial para los administradores que desean monitorear y solucionar problemas de tráfico de datos dentro de la red de una compañía. "Creo que puede haber empresas que no se dan cuenta de que esto les va a afectar", señala Nalini Elkins, presidente del consorcio Enterprise Data Center Operators (EDCO, por sus siglas en inglés). "Van a hacer un upgrade y las cosas van a quedar ciegas. Van a tener interrupciones que no podrán arreglar y herramientas de seguridad que se apagarán".

Si bien se están realizando intentos para solucionarlo, vale la pena observar cómo llegó la comunidad a este punto. Es una historia de culturas enfrentadas, prioridades diferentes y caminos a veces enrevesados por los cuales los estándares técnicos se abren camino hacia la producción.

Las comodidades (y los problemas) del status quo

En el núcleo del protocolo TLS hay una serie de intercambios de claves criptográficas que se comunican entre los sistemas informáticos, lo que les permite comunicarse entre sí de forma segura. El intercambio estático de claves RSA es uno de estos, y los administradores de los centros de datos lo adoran mucho por la visibilidad que ofrece a sus redes. Como señala Elkins: "En el entorno actual, el tráfico que ingresa a través de Internet está encriptado, y ha sido NATeado por la red de entrega de contenido, por lo que no tenemos forma de encontrar una sesión defectuosa. Necesitamos obtener un nombre de usuario, la URL a la que intenta ir, y el momento en que ocurrió la falla. Y podemos ver eso en un paquete si podemos descifrarlo. Pero si no podemos descifrar el paquete, estamos completamente ciegos para la resolución de problemas".

La ventaja del intercambio de claves RSA estático es que permite ese tipo de descifrado, para que tenga lugar fuera de banda, es decir, los paquetes puedan ser descifrados e inspeccionados por herramientas que no están en el flujo principal de tráfico de red, lo que significa que las diversas herramientas de inspección pueden hacer su trabajo sin agregar latencia que puede detener el sistema.

Además, este tipo de herramientas van más allá de la solución de problemas para incluir la supervisión de la experiencia del cliente y la detección de intrusión y malware también: los paquetes se pueden rastrear y descifrar en cualquier lugar del centro de datos.

Entonces, ¿por qué deshacerse del intercambio de claves RSA estático? Bueno, el problema es que gran parte de lo que lo hace tan útil, también lo hace inseguro. Las capacidades de descifrado fuera de banda, en las que los administradores se basan para el monitoreo de la red, pueden ser objeto de abuso para husmear en los paquetes en Internet abierta. También hay vulnerabilidades potenciales para el mecanismo de clave RSA, incluido ROBOT y robo de clave. Sin embargo, si las claves privadas se usan dentro de un centro de datos y no en Internet, un pirata informático malintencionado tendría que penetrar en ese centro de datos y robar tanto los paquetes como las claves privadas de RSA para explotar esas debilidades.

Por supuesto, la"I" en IETF significa que Internet es la principal preocupación del organismo de normalización. Elkins anota que, desde la perspectiva del IETF, el esfuerzo por actualizar TLS "tiene a Internet en mente. En Internet, los paquetes pasan por diferentes equipos, y su intención es asegurar ese tránsito. Pero el punto que intentamos es que el caso de uso de la empresa es diferente".

Para representar ese caso de uso empresarial, EDCO se formó en agosto del 2017. El consorcio está formado por participantes de los sectores manufacturero, de seguros, gubernamental, minorista, financiero y de otro tipo. Como Elkins lo describe, ella leyó el borrador de especificaciones de TLS 1.3 de 112 páginas y señala: "¿Qué? ¿Están quitando RSA? Oh-oh".

"Mucha gente supone que los proveedores nos están representando", añade. "No debemos arriesgar nuestro futuro sobre si los proveedores están entendiendo y comunicando problemas a la persona adecuada. ¡Tenemos que involucrarnos! Varios proveedores se han unido a EDCO".

El modelo de estándares

Para tratar de obtener la perspectiva del IETF sobre esto, CSO online habló con los copresidentes del Grupo de Trabajo de TLS, Sean Turner de sn3rd y Joseph Salowey, gerente senior de Producto de Tableau Software. Turner y Salowey enfatizaron que su rol en IETF, que está separado de sus trabajos diarios, es servir como árbitros neutrales y ayudar a eliminar el consenso de la comunidad sobre el estándar emergente. (Ofrecieron su visión y algunas opiniones sobre la controversia, pero dejaron en claro que al hacerlo estaban hablando por sí mismos, no por el IETF o el grupo de trabajo).

Una cosa que acordaron con la gente de EDCO: muchos colaboradores del grupo de trabajo tienen una perspectiva sobre desencriptación fuera de banda informada, pensando principalmente en términos de Internet. "Si miramos la historia de IETF", indica Salowey, "parte de la comunidad se ha preocupado por la capacidad o los intentos de introducir cosas que podrían ser utilizadas por una organización nefasta para interceptar tráfico. Ese segmento estaba preocupado por la construcción en las capacidades de monitoreo que algún estado-nación podría usar para reprimir a las personas. El centro de datos no es ese escenario, pero existía la preocupación de que cualquier capacidad que pudiera construir para un centro de datos no permanecería en el centro de datos".

Turner ve lo que llamó la "pelea" de la seguridad frente a la visibilidad aquí como parte de una batalla que ha durado casi tanto como la propia web. "Se están desarrollando otros protocolos, y algunas personas dicen: 'Deberíamos encriptar esto'. Y luego otras personas dicen, '¿Cómo vamos a manejar eso?' Desde donde estoy sentado como presidente del grupo de trabajo, solo trato de dejar que la conversación suceda y luego vamos a juzgar el consenso".

Choque cultural

Pero navegar a un consenso es complicado para los miembros de EDCO, sobre todo porque la cultura de los organismos de estándares abiertos como el IETF, es muy diferente del mundo corporativo. Comience con los participantes. En teoría, cualquiera puede participar en cualquier grupo de trabajo, simplemente participando en la lista de correo electrónico. "En términos de proceso de IETF, todo se 'lleva a una lista'", indica Salowey.

En la práctica, sin embargo, esto hace que los grupos se auto seleccionen. "Principalmente, el grupo ha sido formado por muchos criptógrafos, que necesitan estar allí, y estamos contentos de que estén", agrega Elkins. "Una gran parte de ellos trabaja para desarrolladores de navegadores, y hay mucha gente de la academia, y han hecho un gran trabajo. Pero su enfoque se ha centrado en la seguridad, y tienen una fuerte inclinación hacia la privacidad. Es necesario que haya un enfoque en compatibilidad igual. De lo contrario, terminaremos en situaciones donde la red es muy segura y privada, pero lenta porque no podemos ver los paquetes para resolver el problema".

"Gran parte de la discusión es a nivel de código", agrega Elkins. "El tipo de soporte operacional empresarial promedio se encuentra en un mundo muy diferente. No entendemos completamente su mundo de nivel de código y no entienden completamente nuestro mundo operacional".

Y parte de esa falta de comprensión entre ellos ha tomado la forma de retroceso en las preocupaciones de EDCO que pueden sentirse condescendientes, en esencia, diciéndoles que simplemente deberían reorganizar sus redes para evitar la necesidad de descifrado fuera de banda. "Algunas personas han dicho, 'Simplemente puede hacer la transición y dejar de usar TLS y usar IPsec'", indica Elkins. "Es un proyecto multimillonario y de tres o cinco años. O dirán 'Tu topología está equivocada'. Bueno, hay una razón por la cual las topologías de red se construyeron de ciertas maneras. Comencemos con la suposición de que la otra parte es inteligente y entiende cómo hacer su trabajo".

Tarde en el juego

Pero parte del retroceso que han recibido proviene de la sensación de que están interviniendo tarde en el proceso de establecer el estándar TLS 1.3. "Si nos fijamos en uno de los estándares que RSA publicó en el 2003", señala Turner, "básicamente dice, 'no use esto para nuevas aplicaciones'. Por lo tanto, es difícil crear una nueva versión de un protocolo que lo incluya". Y una mirada rápida a través de los archivos de la lista de correo del grupo de trabajo muestra que la discusión sobre la eliminación del soporte para el intercambio de claves RSA estáticas de la norma surgió ya en el 2013.

"La conversación sobre la visibilidad no ha estado sucediendo", admite Elkins. "Y cuando tratamos de comenzar esa conversación, dijeron, bueno, ¿dónde has estado durante los últimos tres o cuatro años? Y tenemos que caer sobre nuestras espadas: no estábamos allí. Y al parecer, nadie más estuvo tampoco. Pero un centro de datos cifrado con TLS 1.3 no es compatible. Es un caso de uso diferente que el tráfico de Internet y debe abordarse de manera diferente".

¿Una solución en proceso?

"No estamos pidiendo que RSA regrese", señala Elkins. En cambio, EDCO ha propuesto una solución. En la conferencia IETF 99 desarrollada en Praga en julio pasado, el equipo extendido de EDCO presentó una forma de crear una clave Diffie-Hellman estática que permita a los operadores del centro de datos continuar inspeccionando el tráfico en la red de una manera similar a cómo funciona el RSA estático hoy en día.

Pero el lanzamiento no fue tan fácil como esperaban. Algunos participantes del IETF se opusieron porque en la solución propuesta, el cliente puede no saber que está ocurriendo la inspección del tráfico, ya que no es obvio en el cable. "Fue muy polémico", anota Elkins. "Al final, nos dieron algunas sugerencias sobre cómo hacer que nuestra solución esté más orientada hacia la privacidad".

Las objeciones se convirtieron en la base de un nuevo borrador de RHRD, que le permite al cliente indicar su acuerdo para que se inspeccione su tráfico. El servidor no puede realizar la inspección de tráfico, a menos que el cliente esté de acuerdo; después de ese acuerdo, se crean las extensiones de protocolo apropiadas para permitir que las claves sean exportadas y reutilizadas por el dispositivo de descifrado. El borrador se presentó en Londres en la pasada conferencia IETF llevada a cabo del 18 al 23 de marzo.

Sin embargo, algunas preocupaciones mayores surgieron en Praga, según Elkins. "Tomaron un zumbido", una técnica que utiliza el IETF para evaluar el consenso, que involucra a los participantes literalmente zumbando en respuesta a las propuestas, "no es nuestra solución, sino la necesidad de visibilidad. Y el resultado fue un zumbido de 50/50". mostrando el apoyo creciente y la necesidad de visibilidad interna. El riesgo es que, si no obtenemos un zumbido de "consenso aproximado" en la solución propuesta que planeamos presentar en marzo, entonces TLS 1.3 perderá visibilidad interna. Eso a su vez causa una menor capacidad de administración de la red, y es probable que el rendimiento de la red sufra hasta que se haga algo para rectificarlo. Realmente entender y pronosticar con precisión el impacto de los estándares futuros es difícil, pero todos queremos hacerlo bien".

Salowey fue más optimista sobre las perspectivas de resolución. "Hubo mucha discusión activa, y no pudimos llegar a un consenso sobre cuál era el enfoque correcto en ese momento", indica. "Desde entonces, se ha dado una discusión constante. Nuestro principal objetivo dentro del grupo de trabajo como presidentes es mantener al grupo enfocado en entregar TLS 1.3, y asegurar que ese producto sea el consenso del grupo de trabajo. Pero este sigue siendo un tema de discusión dentro del IETF, más allá del grupo de trabajo de TLS".

¿A dónde va?

Los miembros de EDCO están ansiosos por una resolución. "Los solucionadores de problemas no pueden migrar a TLS 1.3 tal como está", señala Elkins. "Produciría interrupciones en las aplicaciones que no podemos tolerar. Nuestra capacidad para solucionar problemas de manera oportuna se deterioraría rápidamente hasta el punto en que no sería viable, por lo que tenemos que encontrar una solución en cualquier ventana de tiempo que tengamos".

Salowey y Turner toman una posición más mesurada. "Esta es una nueva versión de un protocolo con nuevas características", indica Turner. "Se necesita tiempo para la implementación y para que otras herramientas se construyan con el protocolo".

"La realidad es que", continúa, "documentos adicionales relacionados con TLS 1.3 pueden y serán especificados después de que se publique TLS 1.3. En otras palabras, habrá una RFC que sea TLS 1.3, a la que me refiero como la especificación base. También habrá otros documentos que amplíen TLS 1.3 en el futuro, estos se hacen en documentos separados y no son lo que yo consideraría parte de la base. (Ambas propuestas de EDCO hasta la fecha han sido propuestas como borradores por separado, que es la razón por la cual he dicho que no son parte de la especificación base, no pretende ser un diss.) Algunos de estos documentos se convertirán en RFC, otros no, algunos ni siquiera se procesarán a través del IETF. Por ejemplo, los consorcios podrían perfilar TLS 1.3 para elegir las opciones que desean utilizar para su propia comunidad".

Y el trabajo continúa. La nueva versión de la propuesta de EDCO se presentó en IETF 101 en Londres. "Esperemos que lleguemos al punto donde estamos discutiendo los aspectos técnicos de lo que se está proporcionando, que [EDCO] haga una pregunta. Porque hasta este punto, los proponentes no han preguntado a toda costa, '¿Vas a adoptar esto?, 'Aquí está nuestro problema, 'Aquí está una de nuestras soluciones', y obtuvieron muchos comentarios. Espero que lleguemos al punto en el que nos retiramos el vendaje. ¿Va a hacer esto o no? "

Mientras tanto, EDCO tuvo su propio seminario en, dos días antes de la conferencia, pero no está afiliado al IETF, para discutir el tema y otros puntos relacionados. Elkins hizo un pitch para una amplia participación en la reunión de Londres. "Los usuarios de protocolo generalmente no se esfuerzan por asistir a una conferencia de normas", señala la ejecutiva. "Los desarrolladores dirán: 'Bueno, si te importa, entonces ven a trabajar con nosotros'. Pero muchos de los usuarios no saben cómo participar, quizás pensando erróneamente que alguien más está cuidando sus intereses. Pero al final del día, operan según los estándares disponibles, por lo que deben formar parte del proceso de creación de estándares. Esto les permite ayudar a dar forma a su propio destino y aportar una perspectiva adicional para ser considerado".

Elkins espera que el impulso atraiga a más personas de la industria interesadas en trabajar en temas similares. "Escuché, de algunas personas con las que hablé en otros organismos de normalización, decir que no hay suficiente participación de la industria", señala. "Y es por eso es que formamos EDCO. Realmente necesitamos estar en todos los organismos normativos: ICANN, IETF, ETSI, etc.".