BoringSSL, por un TLS más seguro

En 2023, Fastly realizó grandes inversiones en seguridad TLS. Hoy explicaremos cómo dejamos atrás OpenSSL y, en un artículo próximo, repasaremos cómo implementamos Neverbleed</u> para aislar operaciones de claves privadas.

OpenSSL presenta un largo historial de vulnerabilidades graves</u>, incluido el famoso error Heartbleed</u>. Además del riesgo que entrañan estas vulnerabilidades, también acarrean un importante coste operativo por las pruebas y revisiones que hay que realizar y aplicar a toda prisa en cuanto se anuncia una nueva vulnerabilidad. Al sustituir OpenSSL por BoringSSL, queríamos ante todo reducir la frecuencia y el impacto de las CVE, así como mejorar la seguridad del sistema de terminación de TLS para nuestros clientes.

BoringSSL</u>, una bifurcación de OpenSSL creada y mantenida por Google, se considera más segura que OpenSSL por su naturaleza menos compleja. OpenSSL sigue siendo el comodín de las bibliotecas SSL y ha mejorado mucho con los años, pero tenemos la convicción de que BoringSSL ofrece una mejor protección para nuestros clientes.

El recorrido

Hace más o menos un año, empezamos a trabajar en la ambiciosa idea de sustituir OpenSSL en nuestro edge para todas las conexiones entrantes. Consideramos varias alternativas, pero volvimos a nuestro plan inicial de migrar a BoringSSL, que nos daba las siguientes ventajas:

• base de código más pequeña y moderna;

• API más segura;

• menos dificultades al tratarse de un producto derivado de OpenSSL y, en la mayoría de los casos, compatible con el código fuente;

• múltiples pruebas de exploración de vulnerabilidades mediante datos aleatorios;

• usado por grandes organizaciones y mantenido por Google;

• rendimiento parecido al de OpenSSL.

En resumen, el consenso era que BoringSSL ofrece una base de código más precisa, sin todo el código antiguo que incluye OpenSSL, lo cual redunda en una mayor seguridad.

Comparativa de líneas de código de OpenSSL y BoringSSL:

Como hemos mencionado anteriormente, nos parecía de capital importancia asegurarnos, durante nuestra evaluación, de que BoringSSL ofreciera el mismo nivel de rendimiento. Utilizamos distintas estrategias para comparar el rendimiento de las dos bibliotecas.

Antes de tan siquiera empezar el desarrollo, establecimos referencias de rendimiento, sobre todo en el terreno de las operaciones criptográficas.

El siguiente gráfico compara el intercambio de claves (operación u operaciones de Diffie-Hellman de curva elíptica) en distintas bibliotecas de TLS:

Acto seguido, en cuanto tuvimos el archivo binario de BoringSSL listo para las pruebas, empezamos a efectuar pruebas «de control», es decir, desplegamos el nuevo código a varios servidores de producción. Así, pudimos comparar el rendimiento con patrones de tráfico real, que son difíciles de simular. Para terminar, realizamos pruebas «de sobrecarga», que introducen más tráfico real en ciertos servidores de Fastly, incluido el que estaba ejecutando el archivo binario de prueba y otros dos de control.

Nadie regala nada

Desde el principio, fue evidente que culminar el desarrollo iba a costar mucho esfuerzo. Tuvimos que aceptar que un cambio de tal calado en nuestra red también exigiría trabajo adicional de apoyo operativo y asistencia a los clientes, dado que la idea era llevar a cabo el cambio sin afectar a estos últimos.

También éramos conscientes de lo que nos perdíamos al migrar. 

• Nada de versiones: al contrario que con OpenSSL, los que llevan el mantenimiento de BoringSSL no sacan nuevas versiones periódicamente, por lo que con BoringSSL tenemos que llevar un control constante para estar al día de cambios ascendentes y determinar su relevancia.

• Secuencias de comandos de configuración y herramientas 

• Grapado de OCSP;

• Compatibilidad con ciertos cifrados no seguros, como los modos de CBC

Problemas con la reanudación de la sesión

En pleno proceso (o en lo que creíamos que era «pleno proceso»), dimos con la primera dificultad: las sesiones de OpenSSL y BoringSSL no son compatibles. Las sesiones provenientes de una instancia de H2O con BoringSSL no podían usarse en H2O con OpenSSL, y viceversa, lo cual impedía la reanudación de sesiones de caché o tickets en distintas bibliotecas.

La arquitectura de Fastly, que incluye un equilibrador de carga, facilita que las conexiones provenientes de un mismo cliente terminen alcanzando distintos servidores de destino, por lo que se podrían producir múltiples intentos de reanudación entre bibliotecas si se desplegase un cambio en miles de servidores.

Puesto que los intentos de reanudación entre bibliotecas solo se darían durante la fase de despliegue, el problema se pudo evitar simplemente segmentando las cachés de sesión TLS y manejando la pérdida momentánea (parcial) de reanudaciones del protocolo de enlace de TLS.

Problemas de cifrado

Otro aspecto que hace a BoringSSL más seguro es que se ha eliminado la compatibilidad con ciertos conjuntos de cifrado más antiguos, como los cifrados no seguros de CBC, que quedaron atrás discretamente con la migración. Pese a que hay muy pocos clientes que utilicen estos cifrados, incluso un ínfimo porcentaje de tráfico puede hacerse notar dada la escala de muchos de los clientes de Fastly. Durante las pruebas descubrimos un cifrado en concreto que se usaba lo suficiente como para bloquear nuestra migración. Ante esta situación, implementamos una funcionalidad de correspondencia simulada de cifrado que contase «como si se estuviese usando BoringSSL» para evaluar la pérdida efectiva de compatibilidad con versiones anteriores.

Los encargados del mantenimiento de BoringSSL detectaron el problema y volvieron a introducir un solo cifrado CBC no seguro, «ECDHE-RSA-AES128-SHA256». Una vez que los datos se recopilaron, analizaron y sometieron a nuevas pruebas, pudimos seguir con el proceso.

Como mostramos a continuación, al reincorporar ese cifrado CBC no seguro, el recuento de cifrados incompatibles queda prácticamente a cero y, en cualquier caso, es probable que esa cifra esté inflada por bots y exploradores sondeando nuestras configuraciones de TLS.

OCSP

Hay muchos clientes que han dejado de usar el protocolo de estado de certificados online (OCSP) para comprobar la existencia de certificados revocados. En Chrome, Google utiliza CRLSets</u>, de modo que se retiró la función de verificación del OCSP de BoringSSL. No obstante, sigue habiendo muchos clientes que realizan la comprobación del OCSP y, por defecto, se trata de una llamada de red que bloquea y, por tanto, perjudica el rendimiento. El grapado del OCSP es una mejora que permite a un servidor presentar la respuesta del OCSP en el protocolo de enlace y eliminar la llamada de red adicional. Como somos Fastly, nos parecía inaceptable perder un ápice de rendimiento, de modo que añadimos a BoringSSL esa función perdida.

Conclusión

Desde un principio, tuvimos la idea (que funcionó francamente bien) de convertir de forma preventiva funcionalidades que requerían funciones de API específicas de OpenSSL, con el objetivo de que fueran el máximo de agnósticas en cuanto a bibliotecas de TLS. 

Esperábamos un coste de mantenimiento adicional, pero ahora afrontamos también la tarea de analizar todos los cambios recientes de BoringSSL en sentido ascendente para evaluar si necesitamos y deberíamos realizar actualizaciones. Estaremos pendientes para evitar la discreta pérdida de retrocompatibilidad que hemos visto, por ejemplo, con los cifrados CBC mencionados anteriormente.

A pesar de que BoringSSL plantea nuevos retos, en general estamos satisfechos con nuestra decisión de invertir en una mejor seguridad de TLS.