OpenPGP: Buscando a Kristian desesperadamente

Hace un año, OpenPGP sufría un problema de vandalismo en sus servidores de claves. El sistema agonizaba y necesitaba un cambio que no resultaba trivial sin traicionar unos principios basados en una Internet de los 90 y que resultan ingenuos a ojos de hoy. Hace poco, una simple anécdota revela de nuevo unas graves carencias, un anacronismo impropio de las redes actuales. Una voluntad inquebrantable pero incapaz de adaptarse a los nuevos tiempos que sigue buscando a Kristian desesperadamente.

¿Qué ha pasado?

Los key servers (SKS) son básicos en la infraestructura OpenPGP. Se ocupan de que podamos localizar las claves públicas de las personas. Permiten que se incorporen al sistema, jamás se pierdan y se repliquen para ofrecer disponibilidad. Para interactuar con ellos se usa el protocolo OpenPGP HTTP Keyserver protocol o HKP. A través del puerto 11371 se pueden subir y buscar claves.

Los servidores públicos nunca han funcionado del todo bien y arrastran demasiadas carencias. Para probarlo, basta con conectarse a cualquier sistema de claves (como podría ser https://pgp.mit.edu) y buscar claves. Después de varios errores de servidor (y de adaptar el ojo a la estética noventera), quizás tendrás la respuesta. Sucede igual con https://keys.gnupg.net, https://pgp.key-server.io o cualquier otro. Servidores poco fiables y poco mantenidos son la base de la criptografía pública.

HKP sobre TLS se llama HKPS. El servidor hkps.pool.sks-keyservers.net se encarga del pool de servidores HKPS, los aglutina, dispone y “ordena” desde el punto de vista DNS para que se conozcan y coordinen. Para pertenecer al pool, los servidores deben estar validados y certificados por una CA propia que permite su comunicación cifrada. Esta CA la mantiene una sola persona de forma manual desde hace más de 10 años: Kristian Fiskerstrand.

A Todd Fleisher, que maneja uno de esos servidores, se le caducó ese certificado que le permitía comunicarse con el central y permanecer en el pool y por tanto, coordinado con el resto de servidores. Buscó a Kristian “desesperadamente” durante un mes. El tiempo corría en su contra. No daba señales de vida ni por correo ni por redes sociales.

Finalmente, le caducó el certificado y tuvo que sacar uno en Let’s Encrypt sólo para seguir cifrando las comunicaciones a sabiendas de que el pool hkps.pool.sks-keyservers.net no se fiaría de él, pero al menos le permitía seguir operando sin sincronizarse. Al poco, Kristian respondió: sin muchas explicaciones, había estado en otros asuntos en el último mes. Renovó el certificado. Si hubiera tardado algo más, habrían caducado el resto de servidores y el pool los hubiera ignorado.

¿Por qué ha pasado?

Porque un punto crítico centralizado (que permite el uso descentralizado de OpenPGP) está en manos de una sola persona que voluntariamente lo mantiene. Algo de otra década (que ni siquiera es la pasada) propenso a errores, fallos y dependiente de buenas voluntades. Romántico pero poco práctico.

Nos encanta el software libre, pero no olvidemos que también requiere financiación para que no sólo una persona, sino un equipo, pueda dedicarle el tiempo correspondiente. Porque hablamos de un sistema de cifrado libre y gratuito, cuyo abuelo fue el estandarte del cypherpunk de los noventa y por el que peleó Phil Zimmerman. Recordemos que hasta el año 2000 estaba muy limitada la exportación de criptografía fuera de Estados Unidos.

Éste no es el único problema de OpenPGP. Thunderbird, un clásico que ha pasado por todo tipo de problemas (Mozilla quiso deshacerse de él un tiempo para centrar sus esfuerzos en Firefox) dio buenas noticias. En octubre de 2019 Mozilla anunció que quería añadir soporte nativo OpenPGP a su cliente de correo Thunderbird. Esto implicaba prescindir de su extensión Enigmail, la reina para la gestión de S/MIME y OpenPGP en el correo.

Este hecho sacaba a la luz algunas realidades del mundo del software que, en el ámbito del código libre y abierto, sorprenden quizá más por las expectativas generadas. Enigmail funciona casi de milagro. Esto quiere decir que la interfaz de Enigmail usa llamadas a líneas de comando y recoge el resultado que redibuja en Thunderbird, con todos los problemas que puede conllevar. Desde luego no es la situación ideal, pero así se ha hecho durante muchísimos años y no ha surgido nada mejor. Enigmail es un proyecto de unas pocas personas en su tiempo libre que vive de donaciones. Lo han mantenido durante más de 15 años y, cuando saben que van a tener que matarlo, incluso se ofrecen a ayudar al equipo de desarrollo de Thunderbird a conseguir la integración.

Aun así, Thunderbird ha tenido que enfrentarse a problemas de licencias para incorporar cifrado en su cliente de forma nativa, pero había una condición: si el esfuerzo hacía que Mozilla perdiera foco en Firefox, no merecería la pena. Pero parece que ya casi está integrado. Podemos ver este mensaje en las últimas versiones de Thunderbird:

Esto básicamente significa que no han podido compatibilizar ambos sistemas durante un tiempo, ni Enigmail ni el nuevo sistema integrado van bien en las últimas versiones. No les ha dado tiempo. Así que toca elegir una versión desactualizada de Thunderbird si se quiere utilizar OpenPGP con Enigmail durante un periodo.

¿Qué más va a pasar?

Un sistema crítico no puede sostenerse gracias a buenas voluntades. Hace falta masa crítica de uso (más allá de la promoción), inversión (y no sólo donaciones), colaboraciones (más allá de las buenas palabras), infraestructuras y personas. Sobre todo personas. No se puede depender de, literalmente, un técnico para una parte crítica del sistema porque pone en juego toda su funcionalidad. El software libre no puede estar buscando a Kristian desesperadamente.