Un escaneo muestra que su servidor todavía admite SSLv3/TLS 1.0 y RC4. ¿Qué hace?
Respuesta breve
SSLv3, TLS 1.0 y RC4 están rotos u obsoletos y permiten ataques de downgrade y descifrado, así que desactívelos y exija TLS 1.2 o 1.3 con suites de cifrado fuertes y con forward secrecy, aceptando la rara pérdida de clientes muy antiguos. Dejarlos activos por compatibilidad mantiene la debilidad explotable. Añadir un segundo certificado o pasar a uno autofirmado no elimina los protocolos débiles, y el autofirmado daña la confianza sin arreglar la criptografía.
Un escaneo que marca SSLv3, TLS 1.0 y RC4 está reportando criptografía que la industria retiró hace años. No son debilidades teóricas — tienen ataques con nombre propio y prácticos — así que la decisión correcta es desactivar los protocolos y cifrados obsoletos y exigir TLS moderno.
Por qué están rotos
- SSLv3 queda fatalmente comprometido por POODLE, que permite a un atacante de red descifrar bytes de una sesión cifrada.
- TLS 1.0 arrastra debilidades estructurales (p. ej., BEAST) y está obsoleto según PCI DSS y los principales navegadores.
- RC4 presenta sesgos que hacen factible recuperar texto plano y está prohibido por la RFC 7465.
El peligro más profundo es el ataque de downgrade: aunque un cliente moderno pueda hablar TLS 1.3, un atacante activo puede reducir la negociación a la opción más débil que ambas partes aún ofrezcan. Mientras su servidor anuncie RC4 o SSLv3, permanece explotable — la mera disponibilidad es el riesgo.
La solución correcta
Configure el servidor para exigir TLS 1.2 como mínimo (preferiblemente 1.3) y ofrecer solo suites de cifrado fuertes y con forward secrecy (intercambio de claves ECDHE, AES-GCM o ChaCha20-Poly1305). La forward secrecy garantiza que comprometer más tarde la clave a largo plazo del servidor no pueda descifrar sesiones capturadas previamente. Valide el resultado con un nuevo escaneo. El compromiso — perder un puñado de clientes muy antiguos — es casi siempre aceptable y mucho más barato que una brecha.
Por qué las demás respuestas son incorrectas
- «Dejarlo activado por compatibilidad» preserva justo la debilidad a la que un atacante hace downgrade; la comodidad de unos pocos clientes heredados expone a todos.
- Añadir un segundo certificado atiende a la identidad/cobertura SAN, no a la negociación de protocolo y cifrado — las opciones débiles siguen en el menú.
- Cambiar a un certificado autofirmado es activamente peor: rompe la cadena de confianza (avisos del navegador, MITM más fácil) mientras deja SSLv3/TLS 1.0/RC4 plenamente activos. Confunde la confianza en el certificado con la robustez del protocolo.
El entrevistador comprueba que arregla la criptografía negociada, entiende el riesgo de downgrade y no confunde un cambio de certificado con el endurecimiento del protocolo.
Posibles preguntas de seguimiento
- ¿Qué ataques apuntan específicamente a SSLv3 y RC4, y cómo fuerza su uso un ataque de downgrade?
- ¿Qué le aporta la forward secrecy, y qué suites de cifrado la proporcionan?
- ¿Cómo desplegaría esto sin romper un pequeño conjunto de clientes heredados que no puede actualizar?