Confiando en SSL y la cadena de confianza

La cadena no se verifica "por sí misma". Un sistema determinado (por ejemplo, un navegador web) considerará el certificado de un servidor como válido porque podría construir una cadena válida (con todas las correcciones de firmas y nombres coincidentes y todas las reglas de X.509 ) que termina con el certificado para validar (el certificado del servidor), y que comienza con una CA raíz que el cliente ya tiene .

Las firmas no crean confianza, transportan confían. Todavía tiene que empezar en alguna parte. Cada cliente (ya sea en el navegador o en el propio sistema operativo) viene con una lista de "CA confiables": estas son las claves públicas y los nombres de algunas entidades que se consideran "confiables" (usted no las eligió usted mismo; Microsoft hizo eso para ti, pero, de todos modos, siempre que utilices el software de Microsoft, estás confiando en Microsoft para que no te juegue juegos desagradables). La CA raíz es "confiable" si confía en ellos para no emitir certificados con información falsa: cuando una CA emite (firma) un certificado para alguna entidad E , se supone que debe asegurarse de que la clave pública que la CA pone ese certificado, junto con el nombre de E , es realmente propiedad de E . De manera similar, cuando una CA raíz delega su poder en otra CA (entonces llamada CA intermedia o sub CA ), se asegura (a través de auditorías y contratos vinculantes) que la CA secundaria es de hecho confiable, ya que aplicará las mismas reglas.

Ese es el concepto de una Infraestructura de clave pública : como cliente, usted sabe a priori un puñado de claves públicas de propiedad de CA confiables, y usted confía implícitamente en todo lo que estos CA firman. Los certificados asumen una estructura similar a un árbol, con la CA raíz como, bueno, la raíz del árbol (de ahí el nombre) y los certificados de entidad final (servidores SSL) como hojas. Una cadena de certificados es realmente una ruta desde la raíz a una hoja dada.

Si una CA raíz o intermedia no es confiable, por ejemplo, porque fue pirateada y emitió un certificado falso (una asociación incorrecta entre el nombre y la clave pública), la recuperación implica cortar la rama incorrecta, un proceso conocido como revocación . En la práctica, esto no ocurre a menudo para las grandes CA comerciales (las que son de confianza por defecto en Windows o Firefox); decir una vez al año. P.ej. ese ocurrió hace unos días, y tanto la revocación como la El parche de Microsoft a prueba de fallas bloquea cualquier intento de uso del certificado fraudulento. En la práctica, los atacantes normales (por ejemplo, para fines de phishing) no se molestan en obtener certificados "válidos" para sus servidores falsos.

No lo llamaría confianza ciega, pero sí, confía en la confiabilidad del certificado raíz y de todas las autoridades intermedias en función de la implementación y la configuración.

El certificado de un sitio web se verifica con una CA. Para asegurarse de que esta CA sea la CA real en la que desea confiar, puede verificar su propio certificado con otra CA por encima de ella en la jerarquía ... esto se repite hasta que llegue a lo que se llama un certificado raíz. Este certificado es validado por su software que tiene una lista de certificados raíz en los que confía. Esto puede ser gestionado por el sistema operativo o por la propia aplicación.

Por lo tanto, finalmente, toda su seguridad depende de esta ruta desde el certificado raíz hasta el final.

Los vectores de ataque incluyen:

Un atacante se las arregla para instalar un certificado de raíz malicioso en tu PC si se acabó el juego.

Un atacante logra engañar a una CA o explotar una vulnerabilidad y ser dueño de una CA

Hay muchas fallas con la PKI actual, y la cadena de confianza es una de ellas, pero no la única y no en todos los casos.

• Cada navegador / sistema operativo viene con muchas CA y la confianza está habilitada de forma predeterminada. Entonces, una vez que obtenga el navegador, confíe implícitamente en todas estas CA para su comunicación. Debe deshabilitar explícitamente la configuración de confianza si desea controlar en quién confía.
• Cada CA puede crear cualquier certificado que desee, por ejemplo, pueden crear un certificado para google.com incluso si ya existe dicho certificado de otra CA. Y el navegador aceptará estos certificados, a menos que use la fijación de certificados o técnicas similares.
• Cada CA puede crear un número ilimitado de sub-CAs.
• Cada sub-CA tiene los mismos derechos ilimitados que su CA principal, por ejemplo. puede crear cualquier certificado, incluyendo sub-sub-CAs. Estas sub-sub-CA nuevamente tienen los mismos derechos, etc. Esto significa que debe comprometer solo uno de los miles CAs / sub-CAs / sub-sub-sub-CAs, etc. para obtener el certificado que desee.
• Actualmente, no hay ningún control sobre qué CA / sub-CA emitió qué certificados o sub-CA, por lo que es tentador vender dichos sub-CA ilimitados al gobierno y otras instituciones, que pueden usarlos para obtener información de forma transparente. -medios ataques.

Por lo tanto, la cadena de confianza es parte del problema, porque no puede limitar las habilidades de una CA sub. Si la sub-CA es controlada por una parte diferente, entonces la CA principal también aumenta el riesgo de compromiso.

Pero, las sub-AC también se pueden usar para un mejor control de riesgos. Si el propietario de una CA raíz crea una cantidad controlada de sub-CA de corta duración de la CA-raíz de larga duración y utiliza estas sub-CA para firmar, puede bloquear la clave secreta de la CA raíz en un lugar muy seguro hasta que las sub-CA de corta duración necesiten ser renovadas, por lo que solo las sub-CA de menor valor podrían verse comprometidas. Y, puede revocar el certificado para una sub-CA (al menos en teoría), pero para revocar la raíz-CA deberá actualizar todos los navegadores / SO.