¿Por qué los protocolos TLS antiguos no son seguros para su organización?

Publicado: septiembre de 2021. Actualizado: agosto de 2026. Revisado por el equipo de asesoría de PKI de Encryption Consulting.

Netscape presentó el primer borrador público de SSL en 1995, y SSL 3.0 le siguió un año después tras detectarse fallos iniciales. El IETF renombró el protocolo como TLS en 1999 (RFC 2246), y posteriormente publicó TLS 1.1 en 2006 (RFC 4346), TLS 1.2 en 2008 (RFC 5246) y TLS 1.3 en 2018 (RFC 8446). Este historial de versiones es importante por una razón: todas las versiones anteriores a TLS 1.2 están oficialmente obsoletas, y dos de ellas, TLS 1.0 y SSL 3.0, han sido objeto de ataques documentados públicamente. Esta guía explica por qué estas versiones son inseguras, las vulnerabilidades específicas que justifican esta conclusión, cómo elegir el protocolo y el conjunto de cifrado adecuados para el futuro, y cómo migrar sin afectar a los clientes heredados que desconocía tener instalados.

¿Por qué TLS 1.0 y TLS 1.1 no son seguros?

TLS 1.0 y TLS 1.1 no son seguros porque ambas versiones dependen de SHA-1 para la integridad del protocolo de enlace y la autenticación de mensajes, ambas permiten conjuntos de cifrado en modo CBC con debilidades conocidas de oráculo de relleno, y ambas fueron formalmente desaprobadas por la IETF. El RFC 8996, Deprecating TLS 1.0 and TLS 1.1 , publicado en marzo de 2021, establece claramente que estas versiones "carecen de soporte para los algoritmos y mecanismos criptográficos actuales y recomendados", y deja obsoletos el RFC 5469 (los conjuntos de cifrado DES e IDEA) y el RFC 7507 (el conjunto de cifrado de señalización de reserva TLS), al tiempo que actualiza más de 80 otros RFC que anteriormente habían hecho referencia a TLS 1.0 o 1.1 como una versión mínima aceptable.

Tres debilidades concretas impulsan esa depreciación:

• Intercambios de claves dependientes de SHA-1. Ambas versiones autentican el protocolo de enlace mediante SHA-1 o una concatenación MD5/SHA-1, lo que permite ataques de degradación que requieren aproximadamente 2^77 operaciones, una carga de trabajo que ya no se considera computacionalmente inviable contra un atacante con recursos suficientes.
• Sin soporte para AEAD. Ni TLS 1.0 ni TLS 1.1 admiten cifrado autenticado con datos asociados (AEAD), los conjuntos AES-GCM y ChaCha20-Poly1305 introducidos en TLS 1.2 que eliminan toda una clase de errores de relleno y sincronización MAC.
• Vectores de inicialización inseguros. TLS 1.0 reutiliza el último bloque de texto cifrado de un registro como vector de inicialización para el siguiente, un diseño de IV predecible que TLS 1.1 corrigió parcialmente, pero que dejó a ambas versiones expuestas al ataque de división de registros que se describe en la siguiente sección.

SSL 2.0 y SSL 3.0 son aún peores: SSL 2.0 se retiró hace décadas debido a fallos de diseño fundamentales, y SSL 3.0 es la versión del protocolo que el ataque POODLE logró vulnerar por completo. Ninguna organización debería permitir SSL 2.0, SSL 3.0, TLS 1.0 o TLS 1.1 en ningún sistema de producción. TLS 1.2 es el estándar mínimo de cumplimiento actual, y TLS 1.3 debería ser el estándar predeterminado siempre que su base de clientes lo admita.

Servicios de cifrado personalizados

Evaluamos, elaboramos estrategias e implementamos soluciones y estrategias de cifrado.

Más Información

¿Qué vulnerabilidades específicas afectan a las versiones antiguas de TLS?

BEAST y POODLE son los dos ataques conocidos y demostrados públicamente que convirtieron la afirmación de que "TLS 1.0 es antiguo" en "TLS 1.0 es vulnerable", y ambos apuntan a la misma debilidad subyacente: el comportamiento predecible en los cifrados de bloques en modo CBC.

• BEAST (Exploit de navegador contra SSL/TLS), CVE-2011-3389. Los investigadores Thai Duong y Juliano Rizzo publicaron en 2011 una prueba de concepto funcional contra los cifrados en modo CBC de TLS 1.0. TLS 1.0 utilizaba el último bloque de texto cifrado del registro anterior como vector de inicialización para el siguiente, un valor predecible que permitía a un atacante que pudiera inyectar texto plano elegido (por ejemplo, mediante JavaScript malicioso en un navegador) recuperar las cookies de sesión cifradas byte a byte a través de un ataque de límite elegido por bloques. La vulnerabilidad subyacente se conocía desde 2002 y se corrigió en la especificación de TLS 1.1 en 2006, pero BEAST demostró que era explotable en la práctica, no solo en teoría.
• POODLE (Relleno de oráculo en cifrado heredado degradado), CVE-2014-3566. Los investigadores de Google Bodo Moller, Thai Duong y Krzysztof Kotowicz revelaron POODLE en octubre de 2014. El ataque explota el relleno en modo CBC de SSL 3.0, que no está cubierto por el código de autenticación de mensajes del registro, por lo que un atacante intermediario que pueda forzar una degradación del protocolo a SSL 3.0 (muchos clientes en ese momento reintentaban silenciosamente un handshake TLS fallido sobre SSL 3.0) puede descifrar un byte de un bloque objetivo por cada 256 solicitudes aproximadamente, suficiente para recuperar cookies de sesión y otros datos confidenciales a través de conexiones repetidas.

Más allá de estos dos ataques mencionados, las implementaciones antiguas de TLS suelen permitir conjuntos de cifrado débiles: RC4 (vulnerable por el sesgo estadístico del flujo de claves y formalmente prohibido por la RFC 7465), 3DES (vulnerable al ataque de cumpleaños Sweet32, CVE-2016-2183, debido a su tamaño de bloque de 64 bits) y cifrados de grado de exportación debilitados deliberadamente para cumplir con los controles de exportación de la década de 1990. Cualquiera de estos cifrados negociados en un handshake, independientemente de la versión del protocolo que los transporta, compromete la conexión. Para obtener un análisis completo de los componentes de los conjuntos de cifrado y cuáles habilitar, consulte nuestra guía complementaria, Introducción a los conjuntos de cifrado.

¿Cómo elegir el protocolo TLS y el conjunto de cifrado adecuados?

Seleccione TLS 1.3 como predeterminado y TLS 1.2 como mínimo de compatibilidad, y restrinja los conjuntos de cifrado a opciones exclusivas de AEAD; nunca vuelva a habilitar TLS 1.0 ni TLS 1.1 para dar cabida a un único cliente antiguo. La decisión se reduce a tres preguntas: qué requiere realmente su cliente más antiguo, qué exige su marco de cumplimiento como mínimo y si su infraestructura de certificados y balanceadores de carga pueden finalizar TLS 1.3 sin una actualización de firmware o software.

• Entornos exclusivamente modernos (API internas, tráfico de servicio a servicio, navegadores actuales): solo TLS 1.3, utilizando sus tres conjuntos AEAD definidos, TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 y TLS_CHACHA20_POLY1305_SHA256.
• Servicios de atención al público con una base de clientes más amplia: TLS 1.2 y TLS 1.3 conjuntamente, con TLS 1.2 restringido al intercambio de claves ECDHE emparejado con AES-GCM o ChaCha20-Poly1305, nunca con conjuntos estáticos RSA o en modo CBC.
• Una excepción heredada documentada (un cliente empresarial específico o un dispositivo integrado que realmente no se puede actualizar): aísle ese tráfico detrás de un punto final dedicado y supervisado con la degradación mínima necesaria, en lugar de reabrir los protocolos antiguos para cada cliente.

La norma NIST SP 800-52 Rev. 2, Directrices para implementaciones de TLS , es la principal referencia con la que las organizaciones federales y reguladas deben validar cualquier configuración, y exige explícitamente TLS 1.2 como mínimo, siendo preferible TLS 1.3.

¿Cuál es el modelo de amenazas para TLS heredado?

El modelo de amenaza realista para TLS heredado es un atacante intermediario o en ruta, generalmente en una red compartida como Wi-Fi pública o un enrutador intermedio comprometido, que fuerza una degradación del protocolo o cifrado y luego explota una vulnerabilidad conocida del modo CBC para recuperar las cookies de sesión o las credenciales. Este no es un riesgo exclusivo de un estado nación. Tanto BEAST como POODLE tuvieron código de explotación público y funcional poco después de su divulgación, y los ataques de degradación se dirigen específicamente al hecho de que muchos clientes históricamente reintentaban un handshake fallido a través de un protocolo más antiguo y débil en lugar de cerrar la conexión.

• ¿Quién se está aprovechando de esto? un atacante situado entre el cliente y el servidor (un punto de acceso Wi-Fi malicioso, un enrutador comprometido o un proxy de tipo portal cautivo), no un atacante remoto sin posición en la red.
• ¿Qué está en riesgo? Las cookies de sesión, los tokens de autenticación y cualquier dato transmitido en el canal cifrado se recuperan mediante los mismos mecanismos de oráculo de relleno o texto plano elegido que demostraron BEAST y POODLE.
• Por qué persiste: Las organizaciones que aún admiten TLS 1.0/1.1 "por compatibilidad" mantienen abierta la opción de degradación para todos los clientes, no solo para aquellos con sistemas heredados que supuestamente la necesitan.

Las configuraciones TLS obsoletas también crean una falsa sensación de seguridad: la conexión sigue mostrando un candado y sigue cifrando el tráfico, por lo que el fallo permanece oculto hasta que un atacante con la posición de red adecuada está presente.

¿Cómo se migra desde versiones antiguas de TLS?

Para migrar desde versiones antiguas de TLS, primero realice un inventario de cada punto final, pruebe la desactivación en un período controlado, supervise los problemas derivados de versiones anteriores antes de la migración final y desactive por completo los protocolos antiguos en lugar de dejarlos habilitados como respaldo. Siga estos pasos en orden:

1. Inventariar todos los puntos finales TLS. Descubra todos los servidores, balanceadores de carga, puertas de enlace API y dispositivos integrados que finalizan TLS. Un dispositivo que nadie recuerda es la causa más común de un incidente de migración, no los sistemas que ya están en el calendario de cambios.
2. Identifique qué protocolo y conjunto de cifrado negocia actualmente cada punto final. Utilice una herramienta de escaneo TLS o los registros de acceso del servidor para ver qué negocian realmente los clientes hoy en día, y no solo lo que el archivo de configuración indica que está habilitado.
3. Identificar qué clientes reales aún dependen de TLS 1.0/1.1. Compare los registros con su base de usuarios o flota de dispositivos. Este paso determina si realmente se requiere una excepción heredada o si la suposición de que "alguien todavía la necesita" está desactualizada.
4. Implemente el cambio en un entorno de prueba o de prueba gradual. Desactive primero TLS 1.0/1.1 y los conjuntos de cifrado débiles en un subconjunto del tráfico o en un entorno que no sea de producción, y supervise las tasas de error antes de afectar al tráfico de producción de forma generalizada.
5. Implementar con supervisión, no en silencio. Supervise de cerca las tasas de fallos en el protocolo de enlace y los tickets de soporte durante el período de transición; un pico indica que se trata de un cliente heredado legítimo que no se detectó en el paso 3.
6. Desactive por completo los protocolos y conjuntos de cifrado antiguos. No deje TLS 1.0/1.1 configurado como un mecanismo de reserva deshabilitado pero presente; elimine la configuración por completo para que una futura configuración incorrecta no pueda volver a habilitarlo silenciosamente.
7. Realizar una nueva verificación periódicamente. La configuración predeterminada del navegador, las bibliotecas de cliente y los requisitos de cumplimiento cambian con el tiempo; vuelva a analizar su configuración TLS al menos una vez al año, no solo durante la migración inicial.

¿Cuáles son las ventajas y desventajas en cuanto a rendimiento e interoperabilidad?

La migración a TLS 1.2/1.3 mejora tanto la seguridad como el rendimiento para la gran mayoría de los clientes, pero un pequeño grupo de dispositivos realmente antiguos no podrá conectarse, y ese es el verdadero inconveniente que hay que tener en cuenta en lugar de intentar evitarlo.

• Ganancia de rendimiento: TLS 1.3 reduce el protocolo de enlace a un solo viaje de ida y vuelta (frente a dos en TLS 1.2) y admite la reanudación de sesión 0-RTT, lo que reduce notablemente la latencia de conexión, especialmente en redes móviles de alta latencia.
• Coste de interoperabilidad: Los dispositivos intermedios empresariales, algunos sistemas operativos móviles antiguos y los dispositivos IoT o industriales heredados solo pueden negociar protocolos TLS 1.0/1.1 o CBC. Estos clientes fallarán abruptamente una vez que se deshabiliten los protocolos antiguos, en lugar de degradarse gradualmente.
• Reducción de la superficie de ataque: Cada protocolo o conjunto de cifrado heredado que se mantenga habilitado es una vía de degradación más que un atacante puede forzar, y cada biblioteca que lo admita es una base de código más que necesita parchearse contra futuras vulnerabilidades.

La respuesta práctica no es "nunca romper nada", sino "romper la población más pequeña y claramente identificada en el plazo más corto aceptable", utilizando los pasos de inventario y monitoreo mencionados anteriormente para que esa población sea pequeña y conocida, en lugar de una sorpresa.

¿Qué dependencias de gestión de claves afectan a una migración TLS?

La migración al protocolo TLS depende de una infraestructura de certificados y claves que es fácil pasar por alto hasta que bloquea la transición: el tipo de clave del certificado, la disponibilidad del módulo de seguridad de hardware (HSM) y el calendario de validez acelerada de los certificados limitan cómo y cuándo se puede migrar.

• El tipo de clave del certificado debe coincidir con los conjuntos de cifrado que desea habilitar. Los conjuntos de cifrado ECDSA requieren un certificado ECDSA, y los conjuntos de cifrado RSA requieren un certificado RSA; un servidor que emite solo un tipo de certificado bloquea silenciosamente el acceso a los clientes que necesitan el otro.
• Emisión de certificados de disponibilidad de HSM y ceremonia de clave. Si su autoridad de certificación firma desde un HSM, una ceremonia de clave estancada o un HSM no disponible bloquea la renovación o reemisión de la cual depende una migración con la misma eficacia que una fecha de vencimiento olvidada.
• La vigencia de los certificados se está reduciendo, lo que aumenta la importancia del seguimiento manual. Según el cronograma SC-081v3 del CA/Browser Forum, la validez máxima de los certificados TLS públicos se reduce de 398 días a 200 días a partir del 15 de marzo de 2026, a 100 días a partir del 15 de marzo de 2027 y a 47 días a partir del 15 de marzo de 2029. Un plan de migración que suponga la rotación anual de certificados no será válido según este cronograma; la detección y renovación automatizadas se convierten en un requisito previo, no en una mejora opcional.
• La integridad de la cadena es tan importante como la versión del protocolo. Un servidor que instala solo su certificado hoja sin el certificado CA intermedio fallará en los handshakes por razones no relacionadas con la versión del protocolo, y ese fallo es fácil de diagnosticar erróneamente como un problema de migración en lugar de un problema de cadena. Nuestra guía complementaria sobre Diagnóstico de fallos en el protocolo de enlace SSL cubre exactamente cómo diferenciar los dos con openssl s_client.

¿Cómo son las implementaciones de migración TLS en el mundo real?

En los proyectos de descontinuación de TLS 1.0/1.1, se repiten tres patrones de implementación, cada uno con una restricción diferente que determina el cronograma:

• Aplicaciones web de acceso público y redes de distribución de contenido (CDN) Por lo general, el proceso es más rápido, ya que la mayoría de las CDN y los navegadores modernos rechazan por defecto TLS 1.0/1.1. El trabajo principal de implementación consiste en confirmar que los servidores de origen detrás de la CDN estén igualmente reforzados, ya que una CDN puede enmascarar una configuración de origen débil.
• Aplicaciones empresariales internas y API El proceso es más lento porque el software intermedio heredado, los balanceadores de carga antiguos y los clientes desarrollados internamente a menudo se programaban utilizando la biblioteca TLS que venía con el servidor de aplicaciones antiguo, e identificar cada dependencia interna lleva más tiempo que el paso de inventario externo.
• Entornos de pago y punto de venta (POI) Operar bajo un plazo de cumplimiento explícito: PCI DSS exige la migración a una versión segura de TLS desde el 30 de junio de 2018, con una excepción limitada y verificable para terminales de punto de venta que no sean susceptibles a las vulnerabilidades conocidas de SSL/TLS tempranas. Estos entornos deben tratar la migración como un proyecto de cumplimiento con un registro de auditoría, no como un cambio de infraestructura improvisado.

¿Qué versión de TLS debería utilizar?

La tabla que aparece a continuación relaciona cada versión de TLS/SSL de uso histórico común con su estado actual, sus vulnerabilidades conocidas y la recomendación para su uso en producción.

Versión	Estado	Vulnerabilidades conocidas	Recomendación
SSL 2.0	Obsoleto (retirado hace mucho tiempo)	Fallos fundamentales en el diseño del protocolo; falta de protección de la integridad significativa.	Nunca lo permitas bajo ninguna circunstancia.
SSL 3.0		CANICHE (CVE-2014-3566), oráculo de relleno de CBC	Nunca lo permitas bajo ninguna circunstancia.
TLS 1.0	Formalmente descontinuado (RFC 8996, marzo de 2021)	BEAST (CVE-2011-3389), protocolo de enlace dependiente de SHA-1, sin soporte AEAD.	Deshabilitar; PCI DSS lo prohíbe desde junio de 2018.
TLS 1.1	Formalmente descontinuado (RFC 8996, marzo de 2021)	Intercambio de claves dependiente de SHA-1, sin soporte para AEAD.	Deshabilitar; ningún marco de cumplimiento lo acepta como mínimo.
TLS 1.2	Actual, ampliamente respaldado	Ninguna inherente al protocolo cuando se configura con conjuntos de cifrado AEAD únicamente.	Compatibilidad mínima aceptable; restringir el intercambio de claves ECDHE con AES-GCM o ChaCha20-Poly1305.
TLS 1.3	Valor predeterminado actual y recomendado	No se conocen problemas; elimina por completo los cifrados en modo CBC y el intercambio de claves RSA estático.	Valor predeterminado para todas las nuevas implementaciones y dondequiera que la base de clientes lo admita.

Limitaciones

• Esta guía abarca los riesgos a nivel de protocolo y de conjunto de cifrado en TLS 1.0/1.1; no cubre las vulnerabilidades de la capa de aplicación en una implementación específica de la biblioteca TLS, que requieren su propio seguimiento de parches independientemente de la versión del protocolo.
• Deshabilitar los protocolos antiguos reduce el riesgo, pero no elimina todas las vulnerabilidades relacionadas con TLS; un punto final TLS 1.3 configurado correctamente sigue dependiendo de un certificado válido e intacto y de una clave privada que no haya sido expuesta.
• Los requisitos de cumplimiento varían según el marco normativo y la jurisdicción; valide cualquier cambio de protocolo o cifrado con respecto a sus obligaciones específicas de PCI DSS, HIPAA o FIPS 140-3 antes de su implementación, ya que las excepciones (como la excepción limitada para terminales POI según PCI DSS) son condicionales, no automáticas.
• Los plazos de migración dependen en gran medida de la cantidad de infraestructura heredada que haya acumulado una organización; los pasos anteriores describen la secuencia correcta, no una duración fija.

¿Qué recomendaría Encryption Consulting?

Trataríamos un punto final TLS 1.0/1.1 persistente como un problema de visibilidad de certificados y configuración, no solo como un cambio de configuración. En nuestros proyectos, las organizaciones que aún utilizan versiones antiguas de TLS casi nunca lo pretendieron; simplemente carecen de un inventario único y actualizado de todos los certificados y puntos finales TLS en su entorno, por lo que una configuración heredada sobrevive sin ser detectada durante años. CertSecure Manager descubre automáticamente todos los certificados y la configuración de protocolo/cifrado que los respalda en todo su entorno, marca cualquier elemento que aún negocie TLS 1.0/1.1 o conjuntos de cifrado débiles, y automatiza la renovación para que la ventana de validez del certificado, cada vez más reducida (que se reducirá a 47 días para 2029), no se convierta en su propia fuente de interrupción. Para las organizaciones que reconstruyen o refuerzan la infraestructura de la autoridad de certificación que emite esos certificados en primer lugar, nuestro equipo de Servicios PKI diseña la jerarquía de CA, las prácticas de administración de claves y la infraestructura de firma respaldada por HSM que mantienen la emisión de certificados disponible durante una migración en lugar de convertirse en su propio cuello de botella. Comience con el paso de inventario en esta guía; Si se detectan protocolos antiguos o conjuntos de cifrado débiles en algún lugar, esa es la señal para centralizar la visibilidad de la configuración de certificados y TLS en un solo programa, en lugar de parchear los puntos finales uno por uno.

Conclusión

TLS 1.0 y TLS 1.1 no solo están desactualizados, sino que están formalmente desaconsejados según la RFC 8996 y presentan ataques conocidos y demostrados públicamente (BEAST y POODLE) contra los cifrados en modo CBC de los que dependen ambas versiones. Su uso actual proporciona una falsa sensación de seguridad: la conexión sigue mostrando un candado, pero sigue siendo vulnerable a un atacante con la posición adecuada en la red. Se recomienda migrar a TLS 1.2 como mínimo de compatibilidad y a TLS 1.3 como predeterminado, restringir los conjuntos de cifrado a opciones exclusivas de AEAD y tratar la migración como un proyecto de gestión de certificados y claves: primero, realizar un inventario, probar y monitorizar antes de la transición, y luego deshabilitar por completo los protocolos antiguos en lugar de dejarlos como una opción de respaldo silenciosa.

Preguntas frecuentes

¿Se sigue utilizando TLS 1.0 en algún lugar hoy en día? Rara vez, y solo donde no debería. Algunos dispositivos integrados antiguos, software intermedio empresarial heredado y sistemas sin actualizar aún negocian TLS 1.0, pero todos los navegadores y CDN principales lo rechazan por defecto, y el RFC 8996 lo declaró oficialmente obsoleto en marzo de 2021. Cualquier sistema de producción que aún lo acepte debe considerarse un hallazgo, no una opción de configuración.

¿Cuál es la diferencia real entre TLS 1.2 y TLS 1.3? TLS 1.3 elimina por completo los cifrados en modo CBC, el intercambio de claves RSA estático y las construcciones MAC que no son AEAD, por lo que cada protocolo de enlace TLS 1.3 es secreto hacia adelante y está protegido por AEAD por diseño. TLS 1.2 se puede configurar con la misma seguridad, pero solo si se restringe explícitamente al intercambio de claves ECDHE con AES-GCM o ChaCha20-Poly1305 y se desactivan las opciones más débiles que aún permite el protocolo.

¿Puedo mantener TLS 1.1 habilitado solo para un cliente antiguo? No. Habilitar TLS 1.1 en cualquier parte de un servidor reabre la posibilidad de una degradación para todos los clientes que se conecten a él, no solo para el que se pretendía admitir. Si existe un cliente antiguo que realmente no admite soporte, aíslelo detrás de un punto final dedicado y supervisado en lugar de debilitar el servicio principal.

¿Deshabilitar las versiones antiguas de TLS afecta el cumplimiento de PCI DSS? Deshabilitar TLS 1.0 y TLS 1.1 es un requisito de cumplimiento de PCI DSS, no un riesgo para el mismo. PCI DSS exige la migración a una versión segura de TLS desde el 30 de junio de 2018, con una excepción limitada y verificable para terminales de punto de venta (POI) que han demostrado ser inmunes a las vulnerabilidades conocidas de SSL/TLS antiguas.

¿Cuánto tiempo suele tardar una migración al protocolo TLS? Depende casi por completo de la exhaustividad del inventario de certificados y puntos finales. Las organizaciones con detección automatizada de certificados suelen poder planificar y completar una migración en semanas; las organizaciones que detectan los puntos finales manualmente o que encuentran dispositivos heredados que desconocían que utilizaban TLS, deben prever que la fase de inventario por sí sola llevará más tiempo que el cambio de protocolo en sí.

Referencias

• RFC 8996: Rechazo de TLS 1.0 y TLS 1.1, IETF
• RFC 8446: Protocolo de seguridad de la capa de transporte (TLS) versión 1.3, IETF
• CVE-2011-3389: Prueba de concepto de BEAST, y Cómo funciona el ataque BEAST, Invicti
• POODLE: Una vulnerabilidad de SSL 3.0 (CVE-2014-3566), Sombrero rojo
• Migración desde SSL y TLS antiguoConsejo de Normas de Seguridad PCI
• SP 800-52 Rev. 2, Directrices para implementaciones de TLS, NIST CSRC
• Propuesta SC-081v3: Introducir un calendario para la reducción de los períodos de validez y reutilización de datos.Foro CA/Navegador