Teku y Besu corrigen la confianza en certificados de Ethereum

Teku y Besu, los dos clientes de Ethereum escritos en Java, han publicado versiones de mantenimiento que tocan una pieza poco vistosa del nodo: de dónde saca el programa la lista de autoridades de certificación en las que confía. Las notas de Teku 26.10.3 y Besu 26.10.2, en los repositorios de cada proyecto, recogen el arreglo de la confianza en certificados para las imágenes Docker. Quien arranca el cliente desde el binario distribuido se queda fuera de ese arreglo: el almacén de certificados que acaba usando su nodo no lo trae el cliente, lo trae el Java que hay instalado en la máquina, y ese hay que revisarlo por separado. Lo contó CryptoSlate el 28 de octubre. El cambio no llega a las reglas con las que el nodo valida bloques; se queda en las conexiones cifradas que abre hacia fuera.

Dos clientes en Java para las dos mitades del nodo

Besu y Teku cubren mitades distintas del mismo trabajo. Besu es el cliente de ejecución: guarda el estado, ejecuta las transacciones y responde a las llamadas RPC que le hacen los monederos y las aplicaciones. Teku es el cliente de consenso: sigue la cadena de balizas, cumple los deberes del validador y le indica a Besu cuál es la cadena buena. Un nodo completo de Ethereum necesita los dos, comunicados entre sí por una conexión autenticada; esa arquitectura de dos piezas es la que sostiene la cadena de bloques que todos los demás consultan. Que ambos compartan lenguaje explica por qué comparten también este asunto: los dos se apoyan en la Máquina Virtual de Java para hablar TLS.

El Java de la máquina, el punto ciego de los binarios

En Java, la lista de autoridades de certificación la guarda el entorno de ejecución, en el fichero cacerts que acompaña a cada instalación. Una imagen Docker lleva su propio Java dentro, así que el proyecto puede corregir ahí lo que haga falta y al operador le basta con bajarse la imagen nueva. Con un binario la cadena se rompe. El binario usa el Java que el administrador instaló por su cuenta —el del repositorio de Ubuntu, el de Homebrew, el de Adoptium— con los parches que ese paquete tenga ese día. De ahí la asimetría que describe CryptoSlate: misma versión del cliente, dos comportamientos distintos según cómo se haya arrancado.

Lo que depende de esa confianza son las conexiones salientes del nodo: el extremo HTTPS de un servicio de claves remoto, un punto de métricas, cualquier dirección que el operador haya configurado y que el cliente tenga que verificar antes de hablar. Un almacén desfasado no abre la puerta a nadie por sí solo, pero deja al nodo juzgando certificados con una lista que ya no es la que el proyecto da por buena. Para un validador, eso se traduce en firmas que pueden no salir a tiempo si la conexión con el firmador se cae.

Quién tiene que mover algo y quién no

El aviso va para una minoría muy concreta: quien sostiene un nodo o un validador de Ethereum en su propia máquina, en casa o en un servidor alquilado. A quien guarda ETH en un monedero o en un exchange no le pide nada; la custodia de las claves no entra en este arreglo, porque aquí no se ha tocado ninguna firma ni ningún formato de monedero. La lectura técnica es la de siempre con los clientes en Java, y conviene tenerla apuntada: actualizar el cliente y actualizar el entorno que lo ejecuta son dos tareas, y la primera no hace la segunda.

Las referencias son Teku 26.10.3 y Besu 26.10.2. Por debajo de esas dos versiones —o con ellas instaladas, pero sobre un Java propio sin revisar— el nodo sigue con el comportamiento anterior.

Fuentes

• Teku 26.10.3 — fuente primaria (github.com), enlazada por CryptoSlate
• Besu 26.10.2 — fuente primaria (github.com), enlazada por CryptoSlate
• Ethereum client security fixes leave binary users with a separate Java check — CryptoSlate, 28/10/2026

Este artículo no es una recomendación de inversión. Las criptomonedas son un activo volátil y sin cobertura de garantía de depósitos: puedes perder todo el dinero invertido.

¿Quieres ver antes nuestras noticias en Google? Añade Jukipto como fuente preferida.