¿Cuáles son las implicaciones de seguridad de un certificado SSL caducado? Por ejemplo, si un certificado SSL de una CA de confianza ha caducado, ¿el canal de comunicación seguirá siendo seguro?
¿Cuáles son las implicaciones de seguridad de un certificado SSL caducado? Por ejemplo, si un certificado SSL de una CA de confianza ha caducado, ¿el canal de comunicación seguirá siendo seguro?
La comunicación aún está encriptada, pero el mecanismo de confianza se ve socavado. Pero generalmente el factor más importante es que los usuarios recibirán feos mensajes de advertencia sobre la seguridad de su sitio. La mayoría no hará juicios informados sobre la integridad de la conexión, simplemente irán a comprar cosas a otra parte.
Sobre una base teórica, un certificado caducado es un certificado que ya no debe utilizarse. Esto se hace explícito en el el perfil de Internet X.509 en el algoritmo de validación de certificados (sección 6.1.3, elemento a. 2). En la práctica, esto tiene dos consecuencias:
El propietario de la clave (el servidor) debe mantener su clave privada, bueno, privada. Cualquiera que obtenga una copia de la clave privada puede hacerse pasar por el servidor. Mantener algunos datos privados no es totalmente inmediato; p.ej. Tienes que pensar en cómo haces tus copias de seguridad. Una vez que el certificado ha caducado, el servidor simplemente puede dejar de preocuparse por la privacidad de la clave, ya que la clave pública correspondiente no se utilizará más. Si usted (como cliente de SSL) decide aceptar un certificado de servidor caducado, corre el riesgo de usar una clave pública para la cual la clave privada correspondiente simplemente ha sido abandonada y recogida por un malvado.
Hay una cosa conocida como revocación . Cuando una CA revoca un certificado, dice: "sí, esa es mi firma en ese certificado, pero actuemos como si nunca hubiera firmado eso". Una situación típica de revocación es cuando la clave privada fue comprometida. La CA publica constantemente el estado de revocación de los certificados que ha emitido a través de CRL (listas de certificados revocados) y OCSP (un protocolo de verificación de estado de revocación dedicado). Se supone que un cliente SSL debe obtener información sobre el estado de revocación del certificado del servidor antes de aceptarlo (en un contexto Web / HTTPS, la mayoría de los clientes no se molestan). El punto clave es que una vez que el certificado ha caducado, la CA deja de realizar un seguimiento de su estado de revocación (esto evita que la CRL crezca indefinidamente). Por lo tanto, un cliente que acepta un certificado caducado corre el riesgo de que, sin saberlo, utilice un certificado que ha sido revocado durante su vigencia.
Como Peter Gutmann lo dice , el fin de la fecha de validez en un certificado "denota el momento en el que tiene que pagar a su CA una tarifa de renovación para que se vuelva a emitir el certificado". El modelo comercial de CA comercial se basa inherentemente en que los clientes cumplan con el fin de la fecha de validez. Este también explica por qué los navegadores web están interesados en mostrar advertencias de miedo cuando un certificado ha caducado.
En un sentido práctico, me gustaría ver la fecha de caducidad. Si la fecha ha caducado hace unos pocos días, yo, personalmente, confiaría en ella.
Sin embargo, los certificados que hayan transcurrido años desde la fecha de vencimiento podrían haber sido comprometidos y no deberían ser confiables. (De hecho, si aparece un sitio que usas con frecuencia, aparece un certificado que ha caducado durante bastante tiempo, por lo que es una bandera roja).
IE: si el certificado expiró ayer, la conexión no es menos segura de lo que era ayer. No se vuelve automáticamente inseguro una vez que ha pasado la fecha de caducidad.
Sin embargo, tienes que dibujar la línea en algún lugar ... y para eso es la fecha de vencimiento.
Un pensamiento más sobre la expiración de un certificado es abordar la cuestión del algoritmo de clave asimétrica en sí. ¿Es posible determinar la clave privada desde una clave pública? Bueno, la respuesta es improbable en lugar de imposible. En general, se supone que llevaría un millón de años para que una computadora encuentre la clave privada desde una clave pública. Pero qué pasa si corres un millón de computadoras por un año. Podría terminar con la clave privada y ahora, cuando piense en usar esa clave privada, sería muy frustrante darse cuenta de que el usuario ha renovado el certificado. (Eso NO significa que haya pagado dinero para retener el certificado anterior, pero significa que ya se ha implementado un nuevo certificado con una nueva clave pública y que el millón de computadoras tendrían que comenzar su trabajo desde cero)
Por cierto, ¿qué pasa si uso todas estas computadoras para seguir generando públicos & los pares de claves privadas y almacenar los dos en una tabla de dos columnas en una base de datos. ¿Hay alguna posibilidad de leer la clave privada directamente de la clave pública que se ingresa?
Lea otras preguntas en las etiquetas public-key-infrastructure tls certificates certificate-authority