¿Podría una CA raíz comprometida hacerse pasar por algún certificado SSL?

Question

¿Podría una CA raíz comprometida hacerse pasar por algún certificado SSL?

#1 de Steffen Ullrich (8 votos)
#2 de Herringbone Cat (3 votos)

2

Mi pregunta es sobre los ataques MITM contra https y cómo se mostrarían al usuario final.

Suponga que una CA raíz de confianza se vio comprometida / obligada a producir certificados SSL fraudulentos. ¿Qué podrían lograr dichos certificados, específicamente sobre los ataques de tipo MITM?

Por ejemplo, tome Facebook, si voy allí consigo (1) un candado, (2) un certificado firmado por DigiCert, y (3) puedo verificar que la Huella digital SHA coincida con algún valor 81: AB: etc.

Mi suposición es que si DigiCert fuera la CA comprometida, entonces un certificado falso que coincide con 1, 2 y amp; 3 podrían ser producidos, ¿es correcto? ¿Hay algo más en el modelo de seguridad SSL que haga que un certificado falso se distinga del certificado SSL real que realmente se emitió a Facebook? ¿O cualquier otra cosa que permita la detección de ataques de tipo MITM basados en este certificado?

Mi segunda suposición es que si una CA distinta a DigiCert fuera la CA comprometida, entonces podría producirse un certificado falso, pero no diría "DigiCert" en él, y no coincidiría en términos de clave SHA ? ¿Es correcto o sería posible (puramente desde un punto de vista técnico) que una CA raíz cree un certificado que se haga pasar por otra CA raíz? Si es así, ¿habría alguna otra manera de detectar que una conexión fue cifrada con este certificado falso? ¿Podría otra CA crear un certificado que aparentemente tenga la misma clave SHA?

Esta pregunta está inspirada en la próxima "carta de espionaje" de Gran Bretaña, que está programada para dar a las autoridades muchos poderes para espiar las comunicaciones digitales. El punto es qué tan útiles pueden ser tales poderes frente al cifrado, ya que se ha hablado un poco del uso de "cajas negras" para realizar una inspección profunda de paquetes para recopilar información que los proveedores (por ejemplo, Facebook) podrían no compartir con el Gobierno de Su Majestad. Mi conjetura fue que tales técnicas no son posibles (¡ciertamente no con el DPI, eso espero!) Pero las posibilidades de los certificados falsos y los ataques MITM no están realmente claras para mí. Supongo que no se intentará si solo por razones políticas, suponiendo que los clientes expertos en tecnología puedan detectar certificados falsos.

encryption tls man-in-the-middle

pregunta daveonhols 02.07.2015 - 23:02

fuente

2 respuestas

Lea otras preguntas en las etiquetas encryption tls man-in-the-middle

PGP Encryption - ¿Cuál es la necesidad de cifrar usando una clave aleatoria una vez? [duplicar] ¿Por qué Gmail solicitaría la última contraseña que recuerdo? [cerrado]

score 8 · Answer 1

Tales compromisos ya sucedieron y DigiNotar es solo un ejemplo. En efecto, el atacante podría hacerse pasar por casi todos los certificados de esta manera, ya que para la mayoría de los certificados no importa quién lo firmó, sino solo que fue firmado por una CA en la que confía el navegador.

Hay pocas excepciones que son más seguras:

Chrome y Firefox (y IE con EMET?) tienen la huella digital de la clave pública para algunos sitios muy importantes codificados ( anclado ) en el navegador / SO. En este caso, se detectará el certificado falso, como se hizo En el caso de DigiNotar.
Con HPKP los sitios pueden ofrecer sus claves para fijar en el navegador en el primer uso, incluso si el navegador no fue enviado con estas teclas previamente fijadas.
Los certificados de validación extendida (EV) solo pueden ser emitidos por una CA seleccionada, que están codificados en el navegador.

Por supuesto, uno podría, en teoría, detectar dichos certificados emitidos erróneamente comparando la huella digital. Existen extensiones como Patrulla de Certificación que notifican al usuario si el certificado de una visita previa Se ha cambiado el sitio, pero aún depende de cada usuario decidir si el cambio fue correcto o si se trataría de un ataque. Extensiones como Perspectivas intentan simplificar este proceso comparando el certificado con los certificados vistos por otros usuarios . Pero ninguna de estas instalaciones se envía actualmente con los navegadores.

Tenga en cuenta que esta recreación de certificados a menudo se realiza legalmente en cortafuegos de intercepción SSL, que necesitan acceder al contenido descifrado para detectar ataques. Pero en este caso, la nueva CA raíz se agrega explícitamente al navegador como de confianza. Para estas CA, que no se incluyen con el sistema operativo / navegador, HPKP y la fijación previa de pining generalmente son ignoradas por el navegador.

score 3 · Answer 2

El compromiso de una CA raíz no significa que todos los certificados firmados por esa raíz confiable estén comprometidos. Más bien, significa que se pueden hacer certificados fraudulentos para ataques de intermediarios y firmarlos para que parezcan confiables en un navegador.

Cuando envía su Solicitud de firma de certificado (CSR) a una Autoridad de certificación (CA), en realidad están firmando su clave pública. Esto indica que han validado su propiedad del dominio, junto con cualquier otro protocolo que CA requiera, para probar su identidad. Dado que no envía su clave privada, esto no les permite que su carta blanca pueda descifrar su tráfico, ya que su clave privada permanece privada.

Es muy difícil comprometer una CA raíz. Para que los navegadores puedan confiar en ellos, existen requisitos estrictos de seguridad. Esto incluye la "ceremonia de la llave" que convierte la firma de cualquier cosa con la tecla raíz en una operación muy complicada y legal. Esta es la razón por la que la mayoría de los signos de CA con un intermedio, en lugar de directamente desde la raíz.

Si alguien dijera el compromiso de la clave de firma intermedia de DigiCert, podría emitir todos los certificados que desee. Sin embargo, todavía no controlarían el DNS para esos dominios. Sin embargo, podrían, por ejemplo, piratear el DNS en un enrutador corporativo o doméstico y realizar un ataque de intermediario para, digamos, Facebook, sin que el navegador muestre una advertencia. El ataque usaría su sitio web pirateado por DNS para ser un proxy de Facebook donde podrían interceptar el tráfico.

Esto se hace a gran escala mediante firewalls corporativos con intercepción SSL (reemplazan los certificados SSL con los propios, en los que confían todas las estaciones de trabajo, y luego los vuelven a cifrar con el certificado correcto y los envían hacia afuera). También lo hacen países como China, que requieren que su CA sea confiable para todas las computadoras y que realicen ataques de intermediarios SSL de esta forma.

Un certificado recién generado no coincidiría con la huella digital SHA de la clave anterior. Cualquier pequeña diferencia en un archivo o cadena con hash con SHA diferiría mucho de otra versión debido a lo que se denomina "efecto de avalancha" en hash. Sin embargo, esto no importa para la confianza del navegador: la gente reemplaza los certificados todo el tiempo y los navegadores no comprueban si el hash permanece constante. En su lugar, utilizan CRL (Lista de revocación de certificados) o el más moderno OCSP (Protocolo de estado de certificado en línea) para consultar a la AC y ver si un certificado ha sido revocado o comprometido. Esta es la segunda capa de defensa contra una cadena de certificados comprometida.

Sin embargo, fuera de OCSP / CRL, solo la vigilancia del usuario puede detectar una cadena de certificados potencialmente comprometida. Por eso creo que se ha tardado mucho en implementar un reemplazo para el modelo de cadena de confianza de CA, por ejemplo, DNSSEC.