¿Por qué no confiamos en un certificado SSL que expiró recientemente?

Cuando un certificado caduca, su estado de revocación ya no se publica. Es decir, el certificado podría haber sido revocado hace mucho tiempo, pero ya no se incluirá en la CRL. La fecha de vencimiento del certificado es la fecha límite para la inclusión de la CRL. Esa es la razón oficial por la que los certificados caducan: para mantener el tamaño de CRL acotado.

(El motivo no oficial es hacer que los titulares de certificados paguen una tarifa anual).

Por lo tanto, no puede confiar en un certificado caducado porque no puede verificar su estado de revocación . Puede que haya sido revocado hace meses, y usted no lo sabría.

Una buena pregunta. La respuesta más simple es que tener una fecha de vencimiento garantiza que usted tenga una "auditoría" de vez en cuando. Si no hubiera una fecha de vencimiento y alguien dejara de usar un certificado (y protegiera la clave privada), nadie lo sabría nunca. Sin embargo, al tener una fecha de vencimiento, se asegura de que el usuario regrese a la compañía que le vendió el certificado SSL y le pague mucho más dinero. Me refiero a que tiene una auditoría y se vuelve a validar como la persona o el servicio que afirma. be (trataré de dejar las quejas sobre el modelo de seguridad de Internet actual fuera de esta pregunta).

El problema se convierte en: Si va a tener un período de gracia en el que ignora los certificados caducados, ¿cuánto dura? ¿Un día? ¿Una semana? ¿Un mes? En algún momento, simplemente tiene que dejar de confiar en el certificado; Si llega a ese punto un día después de la expiración, aún puede preguntarse: "¿Qué pudo haber pasado entre hoy y ayer?" Y caes en un bucle.

Esencialmente, tienes razón: la gente no deja de proteger mágicamente sus claves privadas tan pronto como llega la fecha de vencimiento (o puede que hayan dejado de protegerlas hace mucho tiempo y nadie sabe porque no las revocaron y aún no han expirado). La fecha de caducidad no dice nada sobre la seguridad del certificado, pero si no tiene un corte, nunca sabrá que se puede olvidar un certificado, mientras que con uno, al menos, sabe mucho. .

Si hubiera un período de gracia universal de cinco días, nadie notaría la caducidad de los certificados hasta cinco días después, lo que le dejaría un efecto neto idéntico para rechazar un certificado caducado de inmediato. Es el hecho de que las conexiones SSL dejan de funcionar lo que crea presión.

Sospecho que sería más productivo para las aplicaciones de cliente SSL advertir en voz alta sobre la caducidad de un certificado inminente, de modo que los usuarios de esas aplicaciones puedan presionar a sus proveedores de servicios con anticipación.

Estoy de acuerdo en que el sistema actual es subóptimo.

Un mejor sistema de certificados podría tener un período de estado "amarillo" para los certificados que están a punto de caducar (el "verde" es un certificado válido y el "rojo" un certificado caducado), que expira dentro de 1 mes. Cada certificado de N años expiraría después de N años + 1 mes, aunque lo ideal sería que se actualizaran dentro del período de N años. Sin embargo, durante el último mes, todas las aplicaciones que utilizan un certificado deben presentar una leve indicación de advertencia al usuario. Para la navegación web, puede hacer algo como colorear la URL en amarillo en lugar de en verde, con un mensaje de desplazamiento / clic al efecto:

  

El certificado de este sitio web caducará el 25 de marzo de 2013 y el propietario del dominio deberá actualizarlo antes de que caduque. El certificado sigue siendo perfectamente válido y debería ser completamente confiable en esta fecha, pero las aplicaciones que se basan en este certificado dejarán de funcionar el 25 de marzo de 2013 si el certificado no está actualizado para entonces.

¿Sería esto perfecto? Probablemente no, ya que algunas aplicaciones no pueden pasar estos mensajes al usuario y aún se alcanzará la fecha de vencimiento. Además, tiene que haber un acuerdo codificado en una norma sobre la fecha de vencimiento de los certificados para que se actualicen (¿un día? ¿Una semana? ¿Dos semanas? ¿Un mes?). Pero definitivamente parece ser una mejora.

(Concedido, estoy de acuerdo en que Microsoft realmente abandonó el juego cuando dejaron que caduque su certificado de Azure, es un signo de incompetencia para una plataforma que intenta admitir aplicaciones empresariales).

La respuesta es tan simple como el negocio: "La factura no se paga"

La autoridad de certificación reclama por un período de tiempo distinto que este certificado es válido. Pero esto no dice mucho sobre la confianza de la autoridad de certificación y los procesos por parte del propietario del certificado.

Tiene que ver con la percepción y las prácticas de seguridad adecuadas.

Cuando creas un certificado con, por ejemplo, un vencimiento de un año, básicamente estás diciendo "No podemos garantizar la integridad del certificado por más de un año, por lo que lanzaremos un nuevo certificado antes de esa fecha. . "

Por lo tanto, un sitio con un certificado caducado es una señal de que los administradores no cumplieron su promesa de renovación dentro del tiempo establecido, lo que sugiere malas prácticas de seguridad.

Es la misma razón por la que te das cuenta de que te perdiste una inspección del auto, incluso si parece que tu auto funciona bien o porque los productos tienen una fecha de caducidad.

Shelf-life puede ser una cosa interesante para algunos productos: el fabricante declara que garantiza que el producto será válido durante un tiempo determinado, pero no puede garantizar que las propiedades originales estarán presentes si consume el producto después de ese período.

Un certificado tiene lo mismo: tiene un período en el que el emisor declara que es válido. Durante ese tiempo el certificado debería estar bien. Y si no es así, habrá algún retiro al respecto: una lista de revocaciones por parte del emisor le dirá a todo el mundo "no confíe en ese certificado nuevamente, porque de alguna manera podría estar comprometido".

Después de la fecha de vencimiento, el emisor no seguirá el rastro de ese certificado: ha pasado la fecha en que fue bueno, por lo que cualquiera que aún confíe en él debe hacerlo solo en su opinión, no en el emisor (o cualquiera else).

Después de la fecha de caducidad, el certificado no es malo, está roto, huele mal ... simplemente ya no se garantiza que haya sido revocado. Y por qué no confiamos en un certificado SSL que expiró recientemente es porque queremos seguridad y usamos certificados para garantizar algo. Si no podemos estar seguros de si fue (o sería) revocado , no puede estar seguro de que se haya comprometido y no tenga ninguna seguridad al usarlo ...

Además de las cosas ya mencionadas (es una buena práctica cambiar estas claves de forma regular, las CA quieren cobrar, volver a auditar la identidad, etc.), también hay una razón técnica. Los navegadores le informan que no pueden verificar la validez del certificado.

Los certificados pueden ser revocados, es decir, marcados como no válidos, en caso de que sus claves se vean comprometidas, la CA advierte que no fueron procesadas, etc. Se garantiza que esta información de revocación se proporcionará durante el período de validez, pero no después. Esto permite mantener los tamaños de CRL (Lista de revocación de certificados) pequeños. Aunque los CRL rara vez se utilizan hoy en día en SSL basado en el navegador, esto también podría afectar otros medios para verificar la validez.

Por esta razón, hacer cumplir la fecha de validez tiene sentido técnico y no se hace simplemente porque "los certificados deben renovarse para garantizar las auditorías" y "las AC quieren recibir pagos".

La configuración de la fecha de vencimiento de los certificados se realiza por la misma razón por la que debe cambiar su contraseña de vez en cuando y tener una política para que los usuarios la cambien de vez en cuando. No siempre es necesario pero puede ser útil a veces.

Por ejemplo, su ex empleado que tiene su trabajo (interno) CA podría firmar su sitio web de phising y no detectaría ninguna diferencia entre su sitio y el sitio de su banco (incluido su navegador que dice que la conexión es segura). Tener una fecha de caducidad al menos en la CA interna te hace cambiarla de vez en cuando y evitar esto.

Aún puedes decir "No me importa" y establecer la fecha del certificado, por ejemplo, 2300 (si eres el dueño de CA). Por supuesto, las autoridades externas comerciales pueden querer que lo establezca en la fecha de caducidad de su licencia ;-).

Depende de lo que estés asegurando. Es relativamente seguro. Se trata de un día cero, el hombre en el ataque medio. Un atacante tendría que saber el certificado caducado, saber que usa ese certificado e insertarse entre usted y el servidor en el lapso de unos días. Si estás guardando secretos nucleares, es demasiado arriesgado confiar. Si envía el número de su tarjeta de crédito, estaría bien por algunos días o semanas (no es responsable de todos modos). Si tu blog sobre dictadores en Irán, mientras que en Irán, estás arriesgando tu vida, y puede que no valga la pena arriesgarse.