Resultados para “tls”
43 resultado(s)
curl con OpenSSL: la caché de CApath provoca un use-after-free que un servidor malicioso puede disparar
Desde curl 8.23.0, los certificados de CApath quedan en la caché del multi handle tras liberarse su contexto de OpenSSL. Un servidor con un certificado falso puede hacer que el cliente lea esa memoria liberada y se caiga.
7 min
curl con OpenSSL y Apple SecTrust acepta grapas OCSP falsificadas, caducadas o "unknown" pese a --cert-status
Cuando Apple SecTrust valida la cadena, curl deja de comprobar la grapa OCSP por su cuenta y SecTrust la evalúa en modo tolerante: una respuesta falsificada, caducada o "unknown" pasa --cert-status sin error.
5 min
curl reutiliza en HTTPS sesiones TLS creadas para FTPS, lo que permite sustituir una respuesta verificada
La caché de sesiones TLS de curl 8.12.0 a 8.23.0 no distingue el esquema de la URL. Un atacante en la red, con varias condiciones a favor, puede hacer pasar un fichero FTPS por una respuesta HTTPS válida sin romper la verificación del certificado.
7 min
curl con GnuTLS y Apple SecTrust acepta respuestas OCSP revocadas, falsificadas o caducadas con --cert-status
En compilaciones de curl con GnuTLS y Apple SecTrust, si GnuTLS rechaza una respuesta OCSP grapada, SecTrust acepta la cadena sin mirarla y --cert-status deja pasar una respuesta revocada, falsificada o caducada.
7 min
curl con Schannel conserva la identidad del certificado de cliente tras una redirección gracias a la reanudación de sesión TLS
En curl 8.23.0 con Schannel, la reanudación de sesión TLS mantenía la identidad mTLS del cliente al seguir una redirección a otro origen. El investigador lo presenta como un arreglo incompleto de CVE-2026-86415.
3 min
pyOpenSSL acepta la conexión TLS aunque el callback de SNI lance una excepción (fallo abierto)
Si la función que el servidor registra con set_tlsext_servername_callback lanza una excepción, pyOpenSSL devuelve «OK» a OpenSSL y el handshake sigue adelante, con lo que se saltan los controles hechos en ese punto.
4 min
CVE-2026-9546: fuga del Referer anterior en libcurl al reutilizar un easy handle
Poner CURLOPT_REFERER a NULL no limpiaba el estado interno del Referer en libcurl, así que la siguiente petición en el mismo easy handle podía reenviar el Referer anterior a otro servidor y provocar un use-after-free.
5 min
curl con wolfSSL acepta un pin de clave pública que el servidor no tiene por un certificado malformado
En curl 8.22.0 compilado con wolfSSL, un certificado con la longitud de "validity" manipulada hace que wolfSSL y curl lean claves públicas distintas del mismo DER, y curl acepta un pin de una clave que el servidor no posee.
4 min
curl ignoraba la verificación de clave de host SSH al seguir una redirección de HTTPS a SFTP o SCP
Si curl empezaba con una URL HTTPS y seguía una redirección a SFTP, no aplicaba --knownhosts ni --hostpubsha256: un servidor SSH suplantado podía recibir credenciales y servir contenido falso.
6 min
Node.js: dns.resolve* corta los nombres en el byte NUL y deja burlar validaciones de host (fix incompleto de CVE-2026-48930)
El parche de CVE-2026-48930 bloqueaba los bytes NUL en dns.lookup, pero no en dns.resolve*: Node consultaba "attacker.test" aunque el código hubiera validado "attacker.test\x00.trusted.corp".
4 min
curl reutilizaba una conexión FTP autenticada con certificado de cliente en transferencias sin TLS ni certificado
Una regresión en la reutilización de conexiones FTP de libcurl permitía que una transferencia sin TLS ni certificado usase una conexión ya autenticada con el certificado de cliente privilegiado de otro handle.
5 min
curl reutilizaba conexiones Schannel autenticadas con certificado de cliente tras una redirección a otro origen
El caché de conexiones de libcurl no comparaba auto_client_cert, así que una petición redirigida podía viajar por una conexión Schannel ya autenticada con certificado de cliente que no debía usar.
5 min