¿Por qué permitimos que los certificados SSL sean reemplazados antes de su fecha de caducidad, sin la revocación de otros?

El primer problema que puedo ver es cómo encontrar el primer certificado. Si ha visitado el sitio anteriormente, supongo que podría hacerlo, pero para cualquier persona que no tenga certificados de todos los sitios que ha visitado, necesitaríamos algo de infraestructura para poder buscar todos los certificados que se resuelven. un CN particular.

Además, un sistema de este tipo podría agregar otro punto de falla, ya que tal servicio podría ser atacado (o la misma lista de revocaciones podría ser atacada), lo que resultaría en una falla para poder autenticar un certificado.

Tampoco estoy seguro de que sea una gran amenaza para la seguridad. Según tengo entendido, la lista de revocaciones se utiliza principalmente para evitar que un certificado filtrado se use en un sitio fraudulento, no para evitar que un certificado fraudulento se use en cualquier lugar. Y, de hecho, con un sistema de este tipo, podría ser posible que el certificado deshonesto elimine la confianza del certificado real original, lo que podría ser aún más perjudicial.

Sí, el problema de los registradores deshonestos es un problema difícil de resolver y si tiene una tienda local del certificado en el archivo, entonces puede valer la pena mostrar una advertencia si se reemplaza antes del vencimiento, pero no estoy Seguro que queremos que se utilice la revocación por más que la pérdida de control de la clave privada o la emisión inicial no válida (que en realidad es otra forma de pérdida de control de la clave privada).

Hay varias situaciones normales que implicarían la existencia de varios certificados simultáneamente válidos para un servidor SSL dado:

• El servidor tiene varios front-end, cada uno con su propia clave privada y certificado, aunque todos los certificados contienen el nombre del servidor. Tener una clave privada por sistema es una buena idea porque evita mover las claves privadas y rara vez es una buena idea moverlas.

• La clave privada se perdió, pero no se comprometió ni fue robada; p.ej. La máquina fue destruida en un incendio. Se debe emitir un nuevo certificado para la nueva clave del servidor, pero no tiene sentido revocar el certificado antiguo (ver más abajo).

• Un certificado de servidor caducará pronto; Se emite uno nuevo. Habrá una superposición durante la cual ambos certificados son válidos, de modo que la transición se pueda promulgar sin ningún tiempo de inactividad.

Conceptualmente , el modelo X.509 es una de las afirmaciones positivas de propiedades Un certificado X.509 dice "esta clave es propiedad de esa entidad". No hay nada en X.509 que diga "esa entidad solo tiene x certificados activos"; Esto no es parte de las propiedades que X.509 trata de mantener, y en realidad sería imposible de cumplir, porque nada me impediría crear mi propia CA y emitir certificados para otras personas. Quiero decir, si encuentro un certificado emitido por alguna CA, entonces puedo extraer el contenido del certificado y colocarlo en un nuevo certificado que puedo firmar. Por lo tanto, puedo hacer arbitrariamente miles de certificados nuevos para cualquier servidor que desee, y eso ni siquiera es "incorrecto" porque no estoy escribiendo ninguna afirmación falsa en ninguno de estos certificados.

En consecuencia, las CRL no están diseñadas para ser una forma de publicar información sobre cualquier lista de "certificados activos". Un certificado se revoca no porque ya no sea utilizado por el propietario , sino porque los verificadores ya no deben aceptarlo , que es una cosa muy diferente. No revoca un certificado cuando se destruye la clave privada; lo revoca cuando sospecha que la clave privada está en las manos equivocadas.

Que X.509 podría no ser el modelo exacto correcto para los servidores HTTPS en la Web global es un punto válido. Esa es la esencia de Convergencia : reemplazar el modelo X.509 (con afirmaciones positivas provenientes de autoridades confiables) por otro modelo en el que los servidores tienen algún contexto estado y, en particular, no cambiar certificados cada cinco minutos. Con X.509, un servidor SSL dado podría perfectamente tener un millón de certificados válidos al mismo tiempo, y utilizar uno elegido aleatoriamente para cada conexión; La validación de X.509 es totalmente suya. Pero "los servidores HTTPS normales no hacen eso" y Convergence trata de quitarle a la seguridad la idea de "servidores normales".

Propongo un contra-escenario:

¿Qué sucede si no estoy satisfecho con mi CA actual, CA-1 y me mudo a CA-2 y les hago emitir un nuevo certificado para mi sitio? Si ya no soy cliente de CA-1 y se niegan a agregar mi certificado original a la CRL, los navegadores en su escenario rechazarán mi nuevo certificado (y válido).

Además, puede haber casos en los que utilice certificados en varios servidores o balanceadores de carga. Su mecanismo requeriría que actualice todos esos dispositivos simultáneamente (junto con la CRL).

Lo que está proponiendo es agregar una detección de anomalía muy rudimentaria en los navegadores que tomaría buenas decisiones en el 96% de los casos, pero no siempre.

La CRL es para certificados que sabemos (o que sospechamos) que se han comprometido, no para ningún certificado con el que hayamos terminado pero que aún creemos que es seguro. El problema real en su escenario es que hay una CA deshonesta, no que los navegadores acepten dos certificados diferentes para el mismo dominio al mismo tiempo. Los navegadores deben dejar de confiar en la CA incorrecta.