Tim Hudson, presidente de OpenSSL Corporation – Serie de entrevistas

Tim Hudson es coautor de SSLeay y uno de los organizadores de la OpenSSL Conference, Praga 13-15 de octubre de 2026. Tiene más de 30 años de experiencia en seguridad de sistemas y redes y es presidente de OpenSSL Corporation y director de tecnología (CTO) en Cryptsoft Pty Ltd. Desde 1995, su trabajo ha incluido cofundar SSLeay con Eric Young, la biblioteca criptográfica que se convirtió en la OpenSSL Library, cofundar el centro de desarrollo de RSA Security Australia, contribuir a cambios en las regulaciones estadounidenses de exportación de cifrado, liderar más de 30 validaciones FIPS 140, copresidir los comités técnicos OASIS KMIP y SAM, y hablar en conferencias de seguridad de primer nivel, como RSA Conference, AusCERT, ICMC, LinuxConf y la OpenSSL Conference.

OpenSSL es un proyecto global colaborativo de código abierto que desarrolla y mantiene la OpenSSL Library, una de las bibliotecas criptográficas más utilizadas del mundo. Utilizada en sistemas operativos, plataformas en la nube, software empresarial y dispositivos conectados, la OpenSSL Library ayuda a proteger miles de millones de interacciones seguras en línea cada día. A través de la OpenSSL Foundation y OpenSSL Corporation, el proyecto está comprometido con avanzar la criptografía confiable, apoyar el desarrollo sostenible de código abierto y reforzar la seguridad de Internet.

Usted cofundó SSLeay con Eric Young en 1995 después de reconocer la necesidad de una implementación de SSL que no fuera de EE. UU., y ese trabajo se convirtió finalmente en la base de OpenSSL. ¿Qué problema intentaba resolver originalmente, y tenía alguna idea en ese momento de que la tecnología podría llegar a ser una parte tan fundamental para asegurar Internet?

La problemática era totalmente concreta, y era comercial antes que nada. Yo estaba en Mincom en Brisbane, y teníamos clientes que necesitaban asegurar sus comunicaciones. No había forma de comprar esa capacidad. Las restricciones de exportación de EE. UU. sobre criptografía significaban que los productos estadounidenses o no podían suministrarse a nosotros en absoluto, o venían con tamaños de clave tan limitados que desplegarlos habría sido deshonesto. No se trataba de una objeción filosófica a la política de exportación. Era un problema de ingeniería en el que el componente que necesitaba no existía en ninguna forma que pudiera adquirir, y tenía clientes esperando.

Lo que sí tenía era conocimiento de algo que la mayoría de la gente había olvidado. Eric Young había escrito una implementación de DES algunos años antes: código bueno, limpio, disponible gratuitamente, escrito por sí mismo y totalmente ajeno a todo esto. Eric no estaba trabajando en SSL. No conocía SSL. Cuando Netscape publicó la especificación, la leí, me acerqué a Eric con el problema y le presenté como un paso relativamente modesto respecto a lo que ya había hecho.

Esto no era la imagen completa. Cada parte era sencilla, pero había un número significativo de partes. Una implementación de DES le brinda un cifrado simétrico. SSL requiere criptografía de clave pública, aritmética de precisión arbitraria, ASN.1, manejo de certificados X.509 y una máquina de estados de protocolo, todo correcto, porque en criptografía lo casi correcto y lo roto son lo mismo. Presenté la escala de manera optimista. Eric pronto comprendió cuánta había, y la disfrutó, porque la magnitud resultó ser la atracción más que el obstáculo. No estoy seguro de que hubiera comenzado de otra forma.

Él se encargó del núcleo criptográfico, por eso la biblioteca lleva sus iniciales. Yo asumí las partes que convierten una biblioteca en algo que otras personas pueden desplegar: la integración de aplicaciones, las pruebas, la documentación y el lado comunitario. También busqué activamente cualquier biblioteca de cifrado competidora que estuviera en uso y la convertí o reemplacé. SSLtelnet, SSLftp, NCSA httpd y muchos otros paquetes fueron mi trabajo, aplicaciones construidas sobre los algoritmos y protocolos criptográficos que Eric implementó. Esa combinación nos permitió a cada uno concentrarnos en lo que realmente nos interesaba, lo cual creo que es la razón principal de su continuidad.

Estar en Australia fue lo que hizo posible resolverlo, y luego resultó que muchísimas otras personas tenían exactamente el mismo problema por la misma razón. Algo creado para satisfacer un requisito específico de un cliente en Brisbane se volvió útil para todos fuera de Estados Unidos, y eventualmente también para muchas personas dentro de él.

¿Sabíamos en qué se convertiría? No. Nadie se propone construir infraestructura crítica. La infraestructura crítica es lo que descubres que has construido, algunos años después, cuando te das cuenta de quién depende de ella. Lo que creíamos que hacíamos era resolver un problema frente a nosotros y luego responder preguntas de otras personas que habían topado con la misma barrera. La parte de responder preguntas resultó ser tan importante como el código.

Ha trabajado en criptografía y seguridad de Internet durante más de tres décadas. ¿Qué ha cambiado de forma más dramática en el panorama de amenazas durante ese período, y qué problemas de seguridad han permanecido sorprendentemente similares a pesar de los enormes avances tecnológicos?

El cambio más grande es que atacar sistemas se convirtió en una profesión con un modelo económico detrás. A mediados de los noventa, la gente que infiltraba sistemas lo hacía mayormente porque les resultaba interesante. Hoy existe una industria, con especialización, herramientas, cadenas de suministro, soporte al cliente y, en algunos casos, financiación estatal. Eso lo cambia todo en la forma de pensar, porque ya no se defiende contra la curiosidad, sino contra alguien con presupuesto, plazo y caso de negocio.

El segundo cambio es la escala y la dependencia. La aplicación promedio en 1995 era algo que usted escribía. La aplicación promedio hoy es algo que usted ensambla, y la mayor parte del código que contiene fue escrito por personas que nunca ha conocido y no puede nombrar. La superficie de ataque pasó de su código a sus dependencias, y la mayoría de las organizaciones no ha ajustado su pensamiento en consecuencia.

Lo que ha permanecido notablemente constante son los modos de falla. Seguimos escribiendo errores en código que analiza entradas no confiables. Seguimos entregando sistemas con valores predeterminados que nadie revisó. Los certificados siguen expirando un sábado. Las credenciales siguen terminando en lugares donde no deberían estar. Y la criptografía sigue casi nunca rota a nivel matemático. Se elude, se configura mal o simplemente no se activa. Si me entregara una lista de las diez causas principales de brechas en 1996 y otra del mes pasado, tendría dificultades para distinguirlas. La tecnología se transformó por completo. Los errores no.

OpenSSL 4.0 se lanzó en abril de 2026, marcando la primera versión importante del proyecto en varios años. ¿Qué nos indica este lanzamiento sobre la dirección de la infraestructura criptográfica, y qué cambios cree que serán los que finalmente importen más a las organizaciones que dependen de OpenSSL?

Lo más útil para entender sobre la 4.0 es que es, fundamentalmente, una versión de sustracción, y ese era su objetivo.

Eliminamos por completo la interfaz ENGINE. Eliminamos SSLv3 y el ClientHello de SSLv2. Desactivamos curvas elípticas obsoletas y curvas EC explícitas en tiempo de compilación. Hicimos que ASN1_STRING fuera opaco y reforzamos un gran número de firmas de API. Esos son los cambios que generan trabajo para la gente, y son los cambios que importan, porque una biblioteca criptográfica que solo acumula no puede mantenerse segura. Cada ruta de código obsoleta que mantiene viva constituye una superficie de ataque que alguien mantiene en su nombre y nadie prueba.

Hay adiciones: Encrypted Client Hello, soporte de RFC 8998 que incluye el grupo híbrido SM2/ML‑KEM, cSHAKE, KDFs SNMP y SRTP, FFDHE negociado para TLS 1.2. ECH, en particular, cierra una brecha real de privacidad, porque Server Name Indication ha estado filtrando la identidad de cada sitio que visita desde que se lanzó TLS 1.3. Pero las eliminaciones son la historia.

El mensaje que más quiero que las organizaciones extraigan es este: la 4.0 no es la versión LTS. Tiene soporte hasta mayo de 2027. La versión estable a largo plazo actual es la 3.5, con soporte hasta abril de 2030, y la 3.5 ya incluye los algoritmos postcuánticos. Si desea el código más reciente, use la 4.0. Si quiere un objetivo estable alrededor del cual pueda construir un plan de migración de cinco años, use la 3.5. Elegir el número más alto solo porque es mayor es un error que vemos que la gente comete en cada ciclo.

La criptografía postcuántica ha pasado de ser un problema de investigación a un desafío de migración, y OpenSSL ya soporta ML‑KEM, ML‑DSA y SLH‑DSA, así como intercambio de claves híbrido postcuántico. Para los líderes empresariales que asumen que la computación cuántica aún está demasiado lejana como para preocuparles, ¿qué riesgos están pasando por alto hoy?

El error más frecuente es tratar esto como una cuestión de cuándo llegará una computadora cuántica relevante criptográficamente. Esa es la variable equivocada. La pregunta correcta es cuánto tiempo necesita que sus datos permanezcan confidenciales y cuánto tardará su migración. Restar el segundo del primero le da su fecha límite real, y para muchas organizaciones esa fecha límite ya está en el pasado.

El tráfico cifrado puede capturarse hoy y almacenarse indefinidamente. Si la información que contiene tiene un horizonte de sensibilidad de veinte años (historias clínicas, archivos de personal, propiedad intelectual, material diplomático, posiciones financieras), entonces un adversario no necesita una computadora cuántica ahora. Necesitará una eventualmente, y almacenamiento barato mientras tanto. Eso no es un ataque especulativo; es una decisión de archivado.

Lo segundo que se pasa por alto es que la migración no es un único proyecto. El intercambio de claves es la parte fácil, y gran parte ya está en marcha: OpenSSL 3.5 convirtió el intercambio de claves híbrido postcuántico en la opción predeterminada de TLS, de modo que muchas organizaciones ya están ejecutando acuerdos de claves postcuánticas sin haber tomado una decisión al respecto. Las firmas y la jerarquía de certificados son la parte difícil, porque involucran autoridades de certificación, raíces de confianza hardware, claves de firma de firmware, módulos de seguridad hardware y dispositivos con una vida útil de quince años que se construyeron bajo la suposición de que RSA sería suficiente para siempre.

Lo tercero es la restricción para la que nadie asigna presupuesto: las firmas postcuánticas son voluminosas. Una firma ML‑DSA‑65 es aproximadamente cincuenta veces el tamaño de una firma ECDSA P‑256, y SLH‑DSA es aún mayor. Eso rompe cosas: tamaños de handshake, dispositivos con recursos limitados, protocolos con límites de campo codificados, enlaces satelitales e IoT. Estos problemas se descubren mediante pruebas, no leyendo un estándar.

Uno de los retos de la migración postcuántica es que las organizaciones pueden no saber siquiera en qué lugares se utiliza la criptografía en sus aplicaciones, infraestructura, dispositivos y dependencias de terceros. ¿Cómo deberían las empresas abordar el inventario criptográfico y la agilidad criptográfica para que la próxima transición importante de algoritmos no se convierta en una emergencia?

Comience con una verdad incómoda: no puede construir un inventario criptográfico enviando a sus proveedores un cuestionario. Recibirá una mezcla de textos de marketing, incertidumbre honesta y respuestas que eran válidas hace tres versiones. Lo digo después de haber dedicado recientemente una cantidad sustancial de tiempo a leer la documentación de proveedores de hardware en un campo relacionado, y la brecha entre lo que la documentación afirma y lo que el producto realmente hace es mayor de lo que la mayoría de los compradores asume.

Debe buscar. Hay tres capas, y cada una requiere técnicas diferentes. Código que usted escribió: análisis estático, escaneo de dependencias y búsqueda de los identificadores de algoritmos que codificó hace años. Código que usted enlazó: listas de materiales de software, ampliadas a listas de materiales criptográficos, donde el trabajo de CBOM resulta realmente útil. Cosas que compró o conectó: observación de red, porque lo que sus sistemas realmente negocian en la línea es la verdad real y con frecuencia no es lo que nadie creía.

En cuanto a la agilidad, el principio es simple y la práctica no lo es: el algoritmo debe ser una decisión de configuración, no un cambio de código. Si cambiar un cifrado requiere a un desarrollador, una compilación, un ciclo de pruebas y una versión, no tiene agilidad. Tiene un proyecto. Centralice las operaciones criptográficas detrás de una interfaz que controle, de modo que haya un solo punto de cambio en lugar de cuatrocientos.

Y luego la parte que casi todos omiten: ponerla a prueba. La agilidad que nunca ha usado es una afirmación, no una capacidad. Elija un fin de semana tranquilo, desactive un algoritmo en un entorno no productivo y descubra qué se rompe. Algo se romperá. Es mejor descubrirlo en su propio calendario que durante una transición de emergencia obligatoria.

Una función impulsora útil es la vida útil de los certificados. La industria se está moviendo hacia certificados de vida mucho más corta, lo que hace inviable la gestión manual de certificados y obliga a la automatización que ya necesitaba de todos modos. Si automatiza la emisión y rotación de certificados correctamente, habrá construido la mayor parte de la maquinaria que una futura transición de algoritmos requerirá.

La IA está cambiando tanto la defensa de ciberseguridad como las capacidades disponibles para los atacantes. ¿Dónde cree que la IA cambia genuinamente la ecuación de seguridad, y dónde piensa que las organizaciones pueden estar enfocándose demasiado en la tecnología mientras pasan por alto debilidades más fundamentales?

La IA realmente cambia una cosa, y puedo hablar de ello directamente porque nos ha ocurrido.

Un número considerable de vulnerabilidades divulgadas en OpenSSL este año fueron descubiertas mediante análisis impulsado por IA. En enero lanzamos una versión que corregía doce problemas, esencialmente todos provenientes de un grupo de investigación que utilizó análisis automatizado, y aportaron parches junto con los informes. En junio corregimos un uso después de liberación de alta gravedad en la verificación PKCS#7 encontrado por un investigador que trabajaba con un sistema de IA. Eso representa un cambio real de capacidad para encontrar errores de seguridad de memoria y de análisis en código C maduro que ha sido revisado por expertos durante años. He observado el mismo patrón en otras bibliotecas criptográficas. Analizando un lote de CVE de Bouncy Castle de este año, la huella del análisis de código automatizado es clara.

La implicación obvia es que esto funciona en ambos sentidos. Las mismas técnicas están disponibles para quien quiera usarlas, en los mismos bases de código, y los defensores no tienen acceso exclusivo.

La implicación menos evidente, y la que enfatizaría, es la carga que impone a los mantenedores. Generar un informe de vulnerabilidad plausible ahora es casi gratuito. Clasificar uno no lo es. Aún cuesta tiempo real a un experto humano. Los equipos de seguridad de código abierto, que suelen ser pequeños y en su mayoría voluntarios, están absorbiendo un volumen creciente de informes de calidad muy variable. Los buenos, como la investigación que mencioné, vienen con reproducibles y parches. Los malos son un ataque de denegación de servicio contra las personas de las que depende. Si su organización está desplegando IA contra código abierto, financie la capacidad de triage en el otro extremo.

Donde creo que la atención está equivocada: la IA no parchea sus sistemas. No inventaria sus activos, no rota sus credenciales, no retira su hardware sin soporte, ni hace responsable a alguien del certificado que expira el próximo mes. Las organizaciones que compran herramientas de seguridad basadas en IA mientras ejecutan software con vulnerabilidades conocidas sin parchear tienen su secuencia equivocada. El trabajo poco glamoroso sigue siendo donde está el riesgo.

Muchas organizaciones invierten fuertemente en herramientas pero siguen siendo vulnerables debido a errores de configuración, sistemas obsoletos, procesos débiles o una preparación deficiente para incidentes. ¿Cuáles son los errores de seguridad más trascendentales que sigue viendo, y qué deberían tener en su lugar los equipos de liderazgo antes de que ocurra un ataque?

El error más trascendental es tratar la seguridad como una actividad de adquisición. Se compran herramientas, se cumplen los presupuestos, los paneles están verdes, y nadie ha preguntado si la organización realmente puede hacer las cosas fundamentales.

El segundo es no saber qué está ejecutando. No puede parchear software que no sabe que tiene, y la mayoría de las organizaciones descubren el verdadero contenido de su infraestructura durante un incidente. Por eso el trabajo de lista de materiales es importante, no como un artefacto de cumplimiento, sino como lo que busca a las dos de la mañana cuando aparece una alerta crítica y alguien pregunta si está afectado.

El tercero son los valores predeterminados. Los sistemas se instalan, funcionan, y la configuración nunca se revisa. Cinco años después esa configuración se vuelve una responsabilidad, y nadie involucrado en la decisión original sigue trabajando allí.

El cuarto es la gestión de claves y certificados delegada a individuos. Una proporción notable de interrupciones autoinfligidas son certificados caducados que una persona seguía discretamente en una hoja de cálculo hasta que cambió de empleo.

Antes de un incidente, el liderazgo necesita tener cuatro cosas en su lugar. Un responsable designado con autoridad para desconectar el negocio, decidido con antelación y por escrito, porque el debate sobre quién tiene esa autoridad no es algo que quiera mantener activo. Contratos ya firmados con peritos externos y asesores especializados, porque esa adquisición lleva semanas y usted tendrá horas. Un canal de comunicación que no dependa de los sistemas que puedan estar comprometidos. Y una capacidad de restauración que realmente haya sido probada de extremo a extremo, no un régimen de copias de seguridad verificado solo en el sentido de que los trabajos se completaron con éxito.

Luego enséñelo. Un ejercicio de simulación a nivel ejecutivo, una vez al año, revelará más brechas reales que otra herramienta.

Cuando ocurre un ciberataque serio, los ejecutivos pueden encontrarse de repente tomando decisiones técnicas, legales, operativas y de comunicación bajo una enorme presión. ¿Qué separa a las organizaciones que responden eficazmente de aquellas que permiten que un incidente empeore sustancialmente?

Las organizaciones que lo manejan bien han tomado las decisiones importantes antes del incidente, de modo que durante el incidente están ejecutando en lugar de deliberar. Eso es la mayor parte.

Más allá de la preparación, algunas cosas separan consistentemente las buenas respuestas de las malas.

Separan la investigación técnica de la pista ejecutiva y de comunicaciones, con una interfaz definida entre ellas. Cuando las mismas personas intentan contener una intrusión y redactar una notificación al cliente, ambos trabajos se hacen mal.

Preservan la evidencia antes de remediar. El impulso de reconstruir la máquina comprometida de inmediato es fuerte y destruye la información que necesita para establecer el alcance. Si no puede responder “qué más tocaron”, no puede decir crediblemente a nadie que el incidente ha terminado.

Aceptan que la información temprana es provisional y comunican en consecuencia. La mayor parte del daño reputacional que he observado no provino de la brecha sino de declaraciones tempranas y seguras que tuvieron que retractarse. Decir “esto es lo que sabemos, esto es lo que aún no sabemos, esto es cuándo le actualizaremos” no es una debilidad. Es la única posición que no tendrá que revertir.

Y, críticamente, crean condiciones donde los ingenieros pueden decirles malas noticias a los ejecutivos. El patrón de falla que más he visto es una organización donde la exposición legal era tan evidente que nadie quería ser la persona que anotara lo que realmente ocurrió. El incidente empeora en silencio. Si sus ingenieros gestionan su propia responsabilidad en lugar del incidente, tiene un problema de gobernanza que ninguna cantidad de herramientas solucionará.

OpenSSL ocupa una posición inusual como infraestructura de código abierto crítica utilizada en todo el ecosistema tecnológico, mientras que OpenSSL Corporation se centra en servir a comunidades comerciales junto con la OpenSSL Foundation, operada de forma independiente. ¿Cómo equilibra las necesidades de empresas, desarrolladores, reguladores y la comunidad de código abierto en general cuando las decisiones sobre seguridad y compatibilidad pueden afectar a una parte tan grande de Internet?

La respuesta honesta es que no los equilibra intentando complacer a todos en cada decisión. Los equilibra teniendo una política publicada y aplicándola de forma predecible, de modo que la gente pueda planificar en torno a usted incluso cuando no le guste un resultado concreto.

La predictibilidad es lo que debemos a nuestros usuarios. Publicamos versiones con nuevas funciones en abril y octubre. Anunciamos con antelación cuál versión es estable a largo plazo y hasta cuándo. Anunciamos eliminaciones significativas mucho antes de que ocurran. La eliminación del ENGINE en la 4.0 se describió públicamente meses antes del lanzamiento, y fue acordada tanto por la Corporación como por la Fundación. Quien se sorprendió en abril no estaba prestando atención, y lo hicimos tan fácil como razonablemente pudimos para que prestaran atención.

La respuesta estructural es la propia separación. La Fundación existe para servir a la biblioteca de código abierto y a la comunidad que la rodea. La Corporación existe para servir a organizaciones con requisitos comerciales (compromisos de soporte, validación FIPS, plazos específicos) y para hacer que todo sea financieramente sostenible. Mantenerlas distintas significa que ninguno de los conjuntos de necesidades se resuelve silenciosamente a favor del otro. Cuando los requisitos empresariales y los de la comunidad realmente entran en conflicto, ese conflicto ocurre entre dos organizaciones con mandatos claros, en lugar de dentro de la cabeza de una sola persona.

La otra parte es escuchar adecuadamente, lo que requiere mecanismos reales en lugar de suposiciones. Esa es una gran parte de por qué organizamos la conferencia, que se celebrará en Praga este octubre, y por qué existe la infraestructura comunitaria. Es muy fácil que los mantenedores desarrollen teorías confiadas sobre lo que los usuarios necesitan. Es mucho más útil estar en una sala con ellos.

Mirando la próxima década, ¿qué transición de seguridad o criptográfica cree que las organizaciones siguen subestimando hoy, y qué lecciones de la evolución de SSL, OpenSSL y los últimos 30 años de seguridad en Internet deberían aplicar los líderes al prepararse para ella?

La transición que creo que está más subestimada no es la criptografía postcuántica como problema de algoritmo. Es la identidad de las máquinas y la jerarquía de certificados que sustenta todo.

El intercambio de claves postcuántico se resolverá en gran medida mediante valores predeterminados, y gran parte ya lo está. Lo que no se resolverá con valores predeterminados es la infraestructura de confianza: certificados raíz en hardware, claves de firma de firmware quemadas en los dispositivos, HSM con una década de vida útil restante, sistemas industriales y médicos que seguirán operando en 2040 con supuestos criptográficos incorporados en su fabricación. Eso no puede actualizarse simplemente enviando una nueva versión de la biblioteca, y en algunos casos no puede actualizarse en absoluto. La escala de ese problema de reemplazo no se refleja actualmente en la planificación de capital de nadie.

Paralelamente, hay una transición regulatoria. La Ley de Resiliencia Cibernética en Europa, y marcos comparables en otras regiones, cambiarán las obligaciones vinculadas al envío de software con componentes que no usted escribió. La mayoría de las organizaciones no ha analizado lo que eso significa para su dependencia del código abierto, o para las personas que lo mantienen.

1. Las transiciones tardan una década más de lo anunciado. SSLv3 se desaprobó en 2015, se desactivó por defecto en 2016, y finalmente eliminamos el código en abril de 2026. Son once años, para un protocolo que todos acordaron que estaba roto. Planifique la migración postcuántica contra esa realidad, no contra el comunicado de prensa.
2. Los valores predeterminados son el único control de seguridad que funciona a escala. Cualquier cosa que requiera que cada administrador tome una decisión correcta no ocurrirá. La razón por la que el intercambio de claves híbrido postcuántico se ha desplegado tan rápido es que está activado por defecto y no requiere ninguna decisión. Diseñe para las personas que nunca leerán su documentación, porque eso es casi todos.
3. Depende de menos personas de lo que cree. Casi todas las organizaciones del planeta dependen de código criptográfico mantenido por un número muy reducido de individuos. Eso era cierto cuando éramos dos en Brisbane, y la estructura no ha cambiado fundamentalmente aunque las apuestas se hayan multiplicado por órdenes de magnitud. Sea lo que sea que esté planificando para la próxima década, alguna parte depende de un mantenedor al que nunca ha contactado y que no está financiando. Eso es importante saberlo antes de necesitarlos.

Gracias por la excelente entrevista. Los lectores que deseen obtener más información deberían visitar OpenSSL.