¿"Web de confianza" para certificados SSL autofirmados?

  

... Pero en realidad, un certificado autofirmado no es significativamente menos seguro que un certificado firmado por una CA, en el sentido de que su tráfico se cifra y se envía al servidor web y se descifra allí. Solo significa que nadie "de confianza" verificó la identidad del servidor web en cuestión.

Este solo es una parte muy importante. Si no verificas que el par con el que hablas es el par esperado, podría ser otra persona. P.ej. Si Alice quiere hablar con Bob y no comprueba, en realidad está hablando con Bob, que podría hablar con Mallory que dice ser Bob. Mallory podría luego transmitir los mensajes a Bob y la conexión aún parecería encriptada, pero se cifraría de Alice a Mallory y nuevamente de Mallory a Bob. Mallory tendría acceso al texto sin formato del mensaje y también podría modificarlo.

En teoría, puedes crear tu propia red de confianza con certificados autofirmados. Pero, no creo que muchos de los usuarios actuales de https entiendan el concepto y sus implicaciones, por ejemplo. cómo aplicar la confianza a otra parte, cómo no confiar solo en un extraño, cómo la confianza se debilita cuanto más larga es la cadena de confianza y cuánta confianza necesitan al acceder a un sitio (que puede ser diferente de un sitio a otro).

Lo que significa que, al final, es posible que obtengas una red de confianza que es demasiado compleja para que la mayoría de las personas la entiendan y, por lo tanto, no confíen en ella. O puede obtener una red de confianza con algunos jugadores bien conocidos y, por lo tanto, confiables, que ofrezcan verificarlo y luego agregarlo a la red por algo de dinero, que es más o menos lo que tiene hoy.

Aunque a nadie le gusta una autoridad central, tener tal cosa simplifica enormemente aplicar la confianza en la vida real. Es decir. la mayoría de las personas no ponen su dinero en un banco pequeño a menos que se sepa que están respaldados por un banco o un seguro más grande, etc.

DANE podría ser una mejor manera de ir. Todavía requiere una red de confianza central, pero no crea una nueva solo para SSL, sino que reutiliza la existente creada para DNSSec. Esto podría ser más barato y más fácil de entender, y por lo tanto, más confiable.

Se ha intentado ocasionalmente "Web of Trust" en formatos X.509. Por ejemplo, Thawte lo intentó pero se rindió.

Para una Web of Trust para "trabajar", necesita dos cosas:

• Las "partes que confían" (en el caso de HTTPS, esto significa que los navegadores web) deben implementar el protocolo de verificación que verifica las relaciones de WoT.
• Suficientemente muchos participantes deben unirse al sistema. Un WoT proporciona verificaciones que valen ese nombre solo a través de la acumulación de rutas. No es suficiente que el gráfico WoT esté simplemente conectado; La fortaleza de WoT se basa en la capacidad de cualquier verificador para encontrar muchas rutas entre sí y el certificado que se debe verificar.

Thawte resolvió el primer punto poniéndose a sí mismo como intermediario (por lo que, desde el punto de vista de los navegadores, era solo una simple cadena de certificados), pero no pudo superar el segundo punto.

Este es un problema crítico, y también se aplica a PGP: el sistema es muy difícil de arrancar. Durante la fase de implementación, el WoT no ofrece ningún tipo de garantía decente, por lo que hay pocos incentivos para que las personas realmente se unan a él. Cualquiera de los clientes se configura en una configuración de "confianza por defecto" donde confían en un certificado basado en una sola ruta; en cuyo caso se pueden esperar algunos ataques exitosos, que dañarán gravemente la reputación del sistema, desalentando a las personas a usarla. O los clientes tienen una configuración más estricta, y el WoT no se podrá utilizar hasta que participe un gran subconjunto de propietarios de servidores; y no tienen ninguna razón para hacerlo, especialmente si eso significa que sus certificados autofirmados, mientras tanto, activan advertencias de miedo.

Tenga en cuenta que si bien el certificado HTTPS con autofirma proporciona una protección sólida contra los atacantes pasivos (los datos realmente se cifran), es débil contra activo atacantes (que intentan ejecutar servidores falsos, por ejemplo, para un ataque Man-in-the-Middle ). Sucede que la mayoría de los atacantes que pueden ser pasivos también pueden activarse: para un atacante solitario y barato, los escenarios de ataques realistas para escuchas ilegales implican establecer un punto de acceso WiFi abierto (por ejemplo, en un restaurante) o algunos DNS envenenamiento . Ambos contextos también permiten ataques activos, sin trabajo adicional para el atacante.

Por lo tanto, HTTPS con certificados autofirmados no es, de hecho, mucho mejor que HTTP simple. solía ser mucho mejor, en épocas anteriores, cuando el contexto del atacante / objetivo era el de una sala de trabajo en alguna universidad, con estudiantes tratando de espiarse unos a otros: en estos momentos (en la década de 1990) ), los "atacantes" eran en su mayoría pasivos, y el cifrado los derrotó (ese contexto explica los protocolos de autenticación como el "resumen HTTP", lo que tiene sentido, desde un punto de vista de seguridad, solo contra atacantes pasivos).

Esto me recuerda a los anillos web que solían ser populares. Si puede crear un sistema basado en la reputación, puede iniciar su propia CA.

Lo que pasa es que incluso hoy en día las CA no revisan mucho. Puede tener un sitio web malicioso con un certificado firmado por CA. Entonces, no parece inverosímil. Podría crear un sistema de CA basado en la reputación del sitio web. Por ejemplo, sería una buena manera tener un sistema de autorización de certificados de dos niveles basado en la confianza / reputación del sitio web. Puede requerir un aviso o una opción para informar el sitio durante la fase 1, que sería un período de inicio. Después de que el sitio web adquiera una reputación lo suficientemente alta y realice el pago según una mayoría confiable de organizaciones / personas autorizadas, puede firmar su certificado con el segundo nivel, lo que indica que el sitio web ha demostrado ser confiable. Si aún necesita el ícono / ventana del informe en la página, de una manera visible, puede crear una CA más segura, descentralizada, basada en la reputación y la confianza. Es una buena idea. Yo participaria