LibreSSL, borrón y cuenta (casi) nueva para mejorar la seguridad de OpenSSL

LibreSSL, borrón y cuenta (casi) nueva para mejorar la seguridad de OpenSSL
16 comentarios Facebook Twitter Flipboard E-mail

Un fenómeno habitual en el mundo de la seguridad, especialmente en el software libre, es el del descubrimiento en cascada de vulnerabilidades. Pasó hace un tiempo con Rails (un _framework_ de desarrollo web) y ha pasado ahora con OpenSSL. Se descubre una vulnerabilidad grave que llevaban meses o incluso años ocultas, lo que llama la atención de investigadores que exploran más a fondo ese software y acaban descubriendo vulnerabilidades adicionales.

Después del descubrimiento de Heartbleed, los desarrolladores de OpenBSD, un sistema operativo tipo Unix, empezaron a explorar el código de OpenSSL. Lo normal suele ser que se descubran más vulnerabilidades y se reporten. En este caso no ha sido así: han visto fallos tan flagrantes y un código tan malo que han decidido directamente hacer un _fork_: LibreSSL.

A diferencia de otros _forks_ de proyectos libres, LibreSSL no nace por problemas de licencias, como MariaSQL, ni porque el proyecto original cambie de dueños (véase el caso de OpenOffice y LibreOffice). La razón de ser este _fork_ es la pérdida de confianza en OpenSSL y en sus desarrolladores.

Lo cierto es que LibreSSL no es estrictamente nuevo. Los desarrolladores de OpenBSD, muy centrados en la seguridad de sus productos, llevan unos días en una _carrera_ para revisar - más bien purgar - el código de OpenSSL, quitando partes superfluas, adoptando buenas prácticas de programación y en general mejorándolo para hacerlo más fácil de mantener y más seguro. El blog OpenSSLRampage ha estado recopilando algunos de los cambios realizados: no hace falta saber programar para ver cómo valoran al código y a los otros desarrolladores de OpenSSL.

¿Cuestión de conocimientos o también de dinero?

LibreSSL

Así es la página de LibreSSL. Usan Comic Sans como protección anti-hipsters.

A la hora de valorar un _fork_ nos fijamos en varias cosas. La primera es si hay una razón para dividir esfuerzos en lugar de unirse en un mismo proyecto: viendo el historial de ambos desarrolladores, sí parece mejor que sea OpenBSD quien tome directamente las riendas en lugar de quedarse a un lado como colaborador.

Lo segundo en lo que nos fijamos es en sí el _fork_ sobrevivirá. La respuesta a esta pregunta es obvia. OpenBSD es un sistema enfocado a la seguridad y por lo tanto tiene mucho interés en tener una librería SSL segura (o al menos una en la que puedan confiar): no va a dejar LibreSSL de lado así como así.

Una cuestión más importante es si conseguirá mantenerse al día en cuanto a seguridad y funcionalidades. De momento el foco está en lo primero: durante las primeras etapas, LibreSSL perderá características y, lo más importante, portabilidad. Sólo estará desarrollado para OpenBSD, el soporte para otros sistemas como Linux, OS X o Windows llegará más tarde (si llega).

Sin embargo, aquí entra en juego algo más que los conocimientos, algo central en todos los proyectos de esta envergadura: el dinero.Ya lo hemos dicho alguna vez: el software libre no es gratis. No se puede mantener un software tan complejo como OpenSSL sin pagar a los desarrolladores por su tiempo (aunque sólo sea el mínimo para su subsistencia), y por supuesto olvidémonos de realizar auditorías de seguridad. La fundación OpenSSL recibe de media 2000 dólares en donaciones al año, una cifra irrisoria. Para incrementar los ingresos, los desarrolladores realizan trabajos de consultoría relacionada con OpenSSL, y aunque esas tareas aportan dinero no sirven necesariamente para mejorar la librería.

No parece tan claro que OpenBSD tenga el músculo financiero suficiente como para mantener sin problemas LibreSSL. Para que os hagáis una idea, a principios de año estuvieron pidiendo donaciones para pagar la factura de sus servidores (que, todo sea dicho, no es precisamente barata). Puede que tras este anuncio el flujo de donaciones aumente o que más empresas patrocinen el desarrollo, pero de momento las perspectivas no son buenas.

Al final, la lección más importante de Heartbleed no es ni si la librería es mala o buena, ni si hace falta un _fork_ o no. La lección que deberíamos extraer es que hay que tomar conciencia de las herramientas que usamos. Hay muchísimas empresas que funcionan en gran parte gracias a software libre como OpenSSL y que después no contribuyen de vuelta a la comunidad (ya sea económicamente, corrigiendo errores o creando más software libre). El software libre no es un regalo totalmente altruista: si es posible, debería "pagarse" de alguna forma a la comunidad por él. Esperemos que Heartbleed sea capaz de abrir un debate sobre este problema y que todos (especialmente las empresas) tratemos de corregirlo.

Comentarios cerrados
Inicio