Fallos de TLS y criptografía: cuando el cifrado no protege
Guía en castellano sobre fallos de TLS y criptografía: validación de certificados, algoritmos débiles, claves mal gestionadas y comparaciones inseguras.
Qué es
El cifrado solo protege si se usa bien. Los fallos de esta categoría no suelen estar en los algoritmos, que están muy estudiados, sino en cómo se integran: un certificado que no se comprueba, una clave guardada donde no debe o una comparación que filtra información.
El resultado habitual es que alguien en medio de la comunicación puede leerla o modificarla, o que se pueden falsificar datos que deberían estar firmados.
Ejemplos frecuentes
- Validación de certificados rota: clientes (apps móviles, librerías, herramientas de línea de órdenes) que aceptan cualquier certificado, no comprueban el nombre del servidor o reutilizan conexiones sin volver a validarlas.
- Algoritmos o modos débiles: MD5 o SHA-1 para firmas, cifrado sin autenticación (como AES-CBC sin MAC) o protocolos antiguos.
- Claves mal gestionadas: claves en el código fuente, en la app móvil o compartidas entre entornos.
- Aleatoriedad débil: tokens o claves generados con funciones no criptográficas.
- Comparaciones no constantes: comprobar firmas o tokens byte a byte y parar en el primer error, lo que permite adivinarlos midiendo tiempos.
- Firmas que no se verifican: tokens JWT que aceptan el algoritmo
noneo en los que se puede cambiar el tipo de firma.
Cómo se busca
- En apps y clientes, intercepta el tráfico con un certificado no confiable. Si la conexión funciona, no se valida el certificado.
- Revisa el código o el binario en busca de claves, algoritmos y generadores de números aleatorios.
- Manipula tokens firmados: cambia el algoritmo, quita la firma o modifica el contenido.
- Compara el comportamiento con certificados caducados, de otro dominio o autofirmados.
Cómo se evita
- Usar la validación de certificados por defecto de la plataforma y no desactivarla "para probar".
- Algoritmos actuales con cifrado autenticado (AES-GCM, ChaCha20-Poly1305).
- Claves en un gestor de secretos, distintas por entorno y rotadas.
- Generadores criptográficos para todo lo que deba ser impredecible y comparaciones en tiempo constante.
- Librerías de alto nivel en lugar de combinar primitivas a mano.
Al reportarlo
Describe la posición que necesita el atacante (misma red, acceso al dispositivo, etc.) y qué consigue. En estos fallos el contexto cambia mucho la severidad.
Casos reales de TLS y criptografía
Ver los 7 →Monero: las pruebas de gasto (SpendProofV1) no comprobaban que el daemon devolviera la transacción pedida
get_spend_proof y check_spend_proof en wallet2.cpp no comparaban el hash de la transacción recibida del daemon con el txid solicitado, así que un daemon malicioso podía hacer válida una prueba de gasto para un txid ajeno.
4 min
curl ignoraba la verificación de la clave del host SSH al usar --proto-default sftp con URL sin esquema (CVE-2026-12064)
Con --proto-default sftp o scp y una URL sin esquema, curl descartaba en silencio --hostpubsha256, --hostpubmd5 y --knownhosts, y enviaba la contraseña a cualquier servidor SSH que respondiera.
5 min
Monero: check_reserve_proof sumaba importes RingCT sin comprobar el compromiso de la salida
La verificación de pruebas de reservas del monedero de Monero descifraba el importe de cada salida RingCT y lo sumaba sin compararlo con su compromiso de Pedersen, lo que permitía aparentar más fondos de los reales.
5 min
AWS Bedrock AgentCore: el usuario del sandbox podía instalar una CA propia en el almacén de confianza del sistema vía sudo
Una regla sudo sin contraseña sobre deploy-certificates.sh, que leía certificados de un directorio escribible en /tmp, permitía al usuario del Code Interpreter de Bedrock AgentCore meter una CA propia en el almacén de confianza y falsificar certificados TLS.
4 min
curl (CVE-2026-11564): un handle reutilizado sigue confiando en el almacén de CA del sistema tras fijar una CA propia
En builds de libcurl con CA nativa, un easy handle que ya hizo una transferencia con la confianza por defecto mantenía activo el almacén del sistema aunque después se configurase una CA propia con CURLOPT_CAINFO.
5 min
curl con wolfSSL: la caché de CAs reinstala el almacén de confianza y anula el callback SSL_CTX (CVE-2026-82208)
Con el backend wolfSSL y la caché de CAs activa, curl volvía a instalar el almacén de certificados cacheado después de que CURLOPT_SSL_CTX_FUNCTION lo sustituyera, aceptando certificados que la aplicación quería rechazar.
4 min