¿Son los certificados autofirmados realmente más seguros que los certificados firmados por CA ahora?

Hay un punto sutil aquí. En la situación prevista, hay una (o varias) CA deshonestas que pueden emitir certificados falsos para man-in- los ataques del medio . La vulnerabilidad aquí no tiene que ver con un servidor que usa un certificado (genuino) de esa CA deshonesta; se trata del cliente potencialmente que acepta un certificado de esa CA. Para protegerse (como cliente) contra la CA deshonesta, debe desconfiar de esa CA (es decir, eliminarla de su almacén de certificados de "raíces confiables"). Esto simplemente implica que los servidores con los que aún desea hablar deberían usar alguna otra CA distinta para sus certificados.

En una corporación, producir certificados autofirmados y enviarlos a todos los clientes realmente es un caso especial de mantener su propia PKI : la corporación produce una o varias raíces, que deben instalarse en todos los clientes. Esto es factible; algunas corporaciones hacen precisamente eso. Pero para MitM, como se explica aquí, no se gana nada hasta que la tienda de "raíces confiables" de todos los clientes se elimine de todas las demás CA potencialmente malvadas.

Desafortunadamente, no necesariamente puedes hacer eso . Si su sistema operativo es Windows, entonces hay muchas firmas utilizadas para varios componentes, en particular para las actualizaciones de Microsoft. Usted hace desea instalar correcciones de seguridad, ¿no es así? Puede salirse con la suya con la eliminación de la mayoría de las CA raíz de sus "raíces confiables", pero no todas, de lo contrario se romperán muchas cosas en su sistema operativo.

El problema conceptual es que algunos sistemas operativos (en particular Windows) utilizan un mecanismo centralizado para la validación de certificados, en el que hay un un almacén de confianza que se considera apropiado para todo lo que se ocupa de la validación de certificados en el máquina (en detalles, hay un "almacén de confianza de la máquina local", común a todos los usuarios, y un almacén de confianza adicional por usuario, pero un usuario no puede "excluirse" del almacén de confianza de la máquina local común). Es posible que tenga más suerte con otros sistemas operativos como Linux, que tradicionalmente no usan certificados X.509 para sus necesidades internas, sino claves OpenPGP, con un sistema de confianza mucho más descentralizado.

Sin embargo, el navegador web Firefox utiliza su propia implementación de SSL y almacén de confianza, separados de La del sistema operativo base. Además, Firefox admite profiles , lo que significa que un usuario puede tener varias "personas" con Firefox, cada una con su propia configuración, incluido el conjunto de raíces de confianza. Por lo tanto, una corporación que teme por la confidencialidad de sus datos podría hacer lo siguiente: podría instruir a sus empleados, cuando se ocupan de los servidores corporativos, a usar siempre Firefox, con un perfil específico que contenga solo la raíz propia de la corporación (o un conjunto de autoayuda). certificados firmados) como "raíces de confianza".

No está claro si a dichos empleados les gustaría, pero es factible.

Recuerde, sin embargo, que un poderoso atacante es poderoso. Si ese atacante puede controlar la "CA oficial", entonces podría impulsar una actualización falsa, supuestamente firmada por Microsoft, que instala una puerta trasera en cada sistema. O simplemente podrían pedirle a Microsoft que plante ellos mismos la puerta trasera. En cualquier caso, no tienes muchas opciones: por construcción, debes confiar en el sistema operativo y el hardware para no jugarte a ti en juegos de foul.

Los complementos del navegador como Certificate Patrol para Firefox pueden advertirle de los cambios desde última o primera vez que visitó; pero descubrirá que muchas soluciones legítimas de equilibrio de carga y topología de red se han basado en este defecto de confianza de SSL intercambiable, por lo que terminará con un montón de avisos y advertencias mientras navega por Internet.

Usted tiene razón al afirmar que los certificados autofirmados o las CA raíz privadas son más seguros que las CA raíz públicas de confianza previa; siempre que tenga motivos para confiar en la cadena de certificados privados y un canal seguro para recibirla. Esto es: Solo confíe en certificados autofirmados en los que tenga motivos para confiar. Deberá eliminar todas las demás CA raíz pre-confiables.

Tal vez tenga dos instancias de navegador de marca diferente en la computadora. Una para la comunicación segura utilizando solo un pequeño conjunto de CA raíz vetadas; y otra instancia del navegador de vainilla para la comunicación insegura.

Inicialmente, se suponía que el cifrado asimétrico (pares de clave pública / privada) implicaba alguna forma de confianza más directa, como la popularidad de las partes físicas firmantes de claves en los años noventa. Un enfoque factible exacto no se había desarrollado completamente antes de que Internet explotara a mediados de los años 90.

Como estas redes físicas de confianza se consideraban inviables para el comercio electrónico a través de distancias nacionales o internacionales, aceptamos la creación de compañías que actúen como CA raíz "confiables" para el resto de la comunidad empresarial; presumiblemente pueden ser demandados si firmaron certificados que no habían verificado. Si bien esta es una solución (en su mayoría adecuada) para citizen<->business trust para fines de comercio electrónico; no hace nada por la protección contra entidades con los recursos y poderes legales para interceptar y forzar a las autoridades de certificación comercial.

Parafraseando: la mejor mentira que la NSA * dijo alguna vez fue que su espionaje no existe o no funciona.

La retención de datos lleva esto a un nivel completamente nuevo.

Personalmente, desde que leí La luz de otros días , he absorbido subliminalmente la idea de que nada es verdaderamente privado. . Todo se reduce a cuán interesados están los Poderes que Son en ti, qué hay a su disposición y si existe una democracia saludable para mantenerlos bajo control.

_{* o [inserte la agencia de espías favorita aquí]}

Todos los demás aquí tienen razón, pero aquí hay una respuesta directa y simple a tu pregunta.

Si puede comunicarse con el propietario del servidor fuera de banda la primera vez que acepta un certificado autofirmado y verificar que se trata de su certificado, y solo reconocer ese certificado para futuras conexiones a su servidor, entonces En teoría, una configuración de este tipo podría ser más segura que un certificado tradicional firmado por CA. El escenario de transporte de la unidad USB funcionaría como comunicación fuera de banda aquí, siempre que pueda estar seguro de que la unidad USB no se ha comprometido de alguna manera.

En tal caso, puede hacer esto si su certificado está firmado por la AC o autofirmado, y si ese certificado siempre está "fijado" por su navegador (o en su mente, por lo que debe verificar que es la misma firma para cada visita), puede estar relativamente seguro de que no hay MitM en marcha. Sin embargo, esto implica tener que hablar directamente con y confiar en todos y cada uno de los operadores de servidores, y esto a menudo no es posible.

Este escenario también requeriría un canal de revocación fuera de banda, también, en el caso de que una entidad hostil irrumpa en su servidor y robe su clave privada. Y si dice "bueno, ¿qué pasa si el operador del servidor no tiene conocimiento del compromiso de la clave privada?" entonces no se puede hacer mucho; este es un problema que SSL / TLS no puede evitar en general.

Es más seguro usar un certificado anclado que simplemente confiar en CA sigining. Esto es independiente de si el certificado es autofirmado o firmado por una CA.

Sin embargo, debe asegurarse de la distribución de los pinnng :-)

En el caso de que esté distribuyendo un "navegador seguro" en un CD, puede instalar un acceso directo con una línea de comando como el «Twitter Like A Boss» de enlace

(cuidado: las versiones actuales de Chrome no son compatibles con la propiedad public_key_hashes en HSTS, que se usa en esa línea de comandos para fijar el certificado)

Tener solo un certificado autofirmado no lo hace más seguro. Una vez que se haya comprometido, debe informar personalmente a todos sus clientes que la conexión ya no es segura y que ya no deberían confiar en ella, implementar el nuevo certificado y debe mantener los dedos cruzados para que todos sus clientes sean notificados a tiempo.

Si desea ir por este camino, debe crear su propia CA con su propio certificado raíz privado (generado en una máquina que nunca se ha conectado a Internet). Debe mantener la llave solo en una memoria USB y ponerla en una bóveda y solo sacarla si necesita emitir un nuevo certificado (solicitud) (nuevamente, solo hágalo en una computadora que nunca haya visto Internet). . Tener una CA le brinda la posibilidad de crear nuevos certificados a medida que los necesite. Luego, configure un servidor OCSP para que sus clientes puedan verificar bajo demanda (si es el software de su cliente, debe aplicar la comprobación de OCSP antes de cualquier conexión) si se han revocado los certificados.

Cuando todo está configurado y funcionando, debes esperar que nada salga mal (tus servidores son hackeados). Pero es mucho trabajo, y mantenerlo seguro probablemente no sea barato.