¿Por qué no exigimos que los sitios web tengan varios certificados independientes?

  

¿por qué no exigimos que los sitios web sean validados por, por ejemplo, 3 certificados   de CA independientes?

Aquí hay algunas razones:

1. Coste . Comprar certificados ya es un poco caro *; no se agradecería triplicar ese gasto, y obligar a los compradores a adentrarse más en el grupo de posibles CA, donde normalmente comienzan en el extremo barato.

2. Complejidad . Actualmente, si un certificado expira, el sitio está fuera de línea o degradado hasta que TI pueda moverse y repararlo. Sucede sorprendentemente a menudo, dado que las fechas de vencimiento son conocidas y pueden ser planificadas. Su propuesta triplicaría el número de certificados que deben instalarse correctamente, que deben reemplazarse antes de su vencimiento, que necesitan cadenas de certificados correctas ... ¡Algunas de estas cosas son lo suficientemente difíciles hoy en día con solo un CA!

3. Compatibilidad . Los protocolos TLS no especifican un método de operación en el que se deben validar varios certificados, por lo que tendrá que actualizar o reemplazar el protocolo que se está utilizando, lo que llevará años. No hay forma de especificar al cliente que este servidor en particular requiere validación de múltiples certificados, por lo que los ataques de baja calificación son triviales: nuevamente, deberá crear un método y luego esperar años para que el soporte se filtre.

4. Fijación de certificados . Su idea dice "Supongamos que el modelo de CA está roto, y como solución, aumentamos nuestra dependencia del modelo de CA". Si una CA puede verse comprometida, ¿por qué no dos (suponiendo que una mayoría de 2/3 gana en su modelo)? En ese momento, comenzará a decir: "Bueno, obviamente queremos confiar en Entrust más que en la Republik consolidada de Tadpolistan", momento en el que llegó a Fijación de certificados , que ya es una cosa.

5. ¿WoT else? La otra conclusión natural a la que llegarás, cuando decidas que algunas AC son más confiables que otras, es que debería haber un método para incorporar la reputación. Esto se llama la Web de confianza, y es un modelo que compite con la confianza centralizada de las AC hoy. Una implementación del método WoT es el Perspectives Project , que es un enfoque interesante para el mismo problema que describe (y que funciona como complemento de y, en compatibilidad con, el modelo de CA existente).

* Antes de que alguien salte y diga "¡Comience!" o "Vamos a cifrar", recuerde que las empresas impulsan el modelo de CA hoy. Pagan cantidades significativas de dinero, y algunos de ellos compran miles de certificados anualmente. El impacto del costo debe ser considerado contra todos los jugadores. (E incluso en el extremo inferior, si desea un certificado gratuito, ahora tendría que encontrar 3 proveedores gratuitos de buena reputación, cuando encontrar uno ya era un desafío).

RTLS no admite certificados múltiples de hoja para una sola sesión ni X509 admite múltiples emisores para un solo certificado. Esto significa que habrá cambios necesarios en el protocolo. Pero simplemente ignoremos el esfuerzo por realizar dichos cambios y veamos cuánta más seguridad tenemos con su propuesta. Veamos cómo puede emitirse un certificado defectuoso, en qué situaciones le ayuda su propuesta y cómo se compara con las propuestas existentes.

Cómo el atacante puede obtener un certificado

Se puede emitir un certificado erróneo si el atacante CA está comprometido , es decir, tiene errores, está pirateado o si la CA emplea personas poco confiables. En este caso, su propuesta ayudaría porque espera que no todas las CA múltiples tengan estos problemas al mismo tiempo. Por supuesto, esto no es tan simple, porque es mejor que se asegure de que las diferentes CA estén controladas por diferentes entidades y ejecute un código diferente, es decir, que un solo hack no sea realmente un hack de múltiples CA.

Pero un atacante también puede obtener un certificado al comprometer el proceso de validación del dominio . Este proceso funciona de manera similar para todas las CA y, si el atacante obtiene acceso al correo del propietario del dominio o al servidor, podría obtener un certificado para el mismo servidor de varias CA. En este caso, su propuesta no ayudaría en absoluto. Pero, por supuesto, en este caso, el pirata informático solo tendría acceso a algunos certificados para dominios mal protegidos, mientras que en el caso de un compromiso de CA podría obtener muchos certificados incluso para dominios con buena seguridad.

¿Qué propuestas alternativas existen

Con certificado o fijación de clave pública ( HPKP ) a El propietario del dominio puede asegurarse de que el certificado utiliza una clave pública específica. Con el efecto HPKP, el atacante necesitaría acceder a la clave privada del certificado existente, es decir, piratear el servidor. Este protege los dominios con una buena seguridad contra el uso incorrecto de los certificados del atacante creado al comprometer a una CA. Lo bueno de HPKP es que es barato y fácil de implementar y que ya es compatible con los principales navegadores .

Transparencia del certificado es un registro público que se puede usar para averiguar si una CA emitió un certificado que no debería y si una CA sabe que emitió un certificado específico . Esto puede ser usado por el propietario del dominio para verificar si hay certificados falsos. Si bien no todas las CA tienen dichos registros, el número está creciendo porque los proveedores de navegadores exigen el soporte como requisito para ser una CA confiable. Por ahora, Chrome requiere que todos los certificados EV (barra verde) estén cubiertos por dicho registro y algunas otras CA también deben emitir dichos registros, ya que demostraron tener inseguridades en el pasado. Lo bueno es que los navegadores compatibles como Chrome saben qué CA debería tener un registro de este tipo y pueden verificarlo.

DANE hace posible que el propietario del dominio publique su propio certificado en El DNS sin la necesidad de CA. Por supuesto, esto tiene que estar protegido de alguna manera contra la falsificación de DNS, por lo que necesita DNSSec. DANE se puede usar con certificados autofirmados en lugar de usar una CA pública o con certificados firmados por la CA como protección adicional. Aunque actualmente no está implementado en los navegadores, varios proveedores ya lo utilizan para el correo y el soporte en esta área está creciendo.

Resumen

Si bien su propuesta sería útil para aumentar la seguridad, necesita cambios importantes en el protocolo TLS existente (entregar certificados múltiples) o en el modelo X509 (múltiples emisores para un solo certificado). Pero al menos es posible implementar varios certificados opcionales con la ayuda de las extensiones TLS, por lo que no necesitamos una nueva versión TLS para esto. Sin embargo, aumentará los datos transferidos en el apretón de manos completo (muchos certificados de hoja y certificados en cadena) lo que ralentiza el apretón de manos.

Las propuestas alternativas no necesitan tales cambios de nivel de protocolo, ya que funcionan fuera del protocolo TLS. Además, en el caso de HPKP y DANE, brindan más control sobre el certificado al propietario del dominio que su propuesta.

Pero al final, todas estas ideas podrían en teoría utilizarse juntas para aumentar la seguridad. Y aunque su propuesta aumentaría la seguridad, probablemente sea más perjudicial que los demás y causaría más costos, y es por eso que los otros son los preferidos por ahora.

Lo que usted proponga aumentaría la seguridad, pero a un costo administrativo y complejidad técnica mayores. Creo que los compromisos de CA son eventos demasiado raros para justificar esos costos. Además, si se va a poner en práctica un esquema similar, probablemente será más elaborado que la simple votación de 2 de cada 3. Por ejemplo, tener solo dos certificados, uno válido y otro caducado, debería ser suficiente para confirmar la identidad mientras se protege contra compromisos individuales de CA.