¿Cómo los sitios web evitan la falsificación de certificados?

Question

¿Cómo los sitios web evitan la falsificación de certificados?

#1 de Polynomial (4 votos)

1

Recientemente he desarrollado interés en la piratería inalámbrica, y he visto en muchos casos en videos y cosas que las personas (o, más correctamente, eran) capaces de realizar algún tipo de ataque MitM utilizando el método del malvado gemelo contra sitios web grandes como FB , GMail.

Hay muchas herramientas que automatizan la creación de AP falsos e incluyen herramientas adicionales como SSLStrip y SSLSplit para intentar eludir TLS / SSL y HSTS.

Mientras sepa que HSTS funciona, el cliente debe haber visitado el mismo sitio web al menos una vez. Pero, esto no es un gran problema ahora, ya que HSTS está precargando desde los navegadores, y todos los sitios web famosos ya están incluidos allí, por lo que incluso si el cliente ingresa al sitio web por primera vez, todavía ejecutará el HSTS. Por otro lado, creo que estos sitios web también utilizan la fijación de certificados (un concepto que no conozco muy bien), que, si bien sé, significa que, en lugar de usar la cadena de confianza de certificados, especifican directamente en qué certificado buscar, y si el certificado es diferente, finalice la conexión.

Por otro lado, creo que las herramientas que intentan eludir estas tecnologías utilizan la idea de que las personas no escriben www.facebook.com, sino que solo escriben facebook.com, de modo que las herramientas puedan redirigir la solicitud. por ejemplo, wwww.facebook.com, para lo cual es posible falsificar un certificado. Pero, creo que esto ya no es cierto. Pero, ¿qué impide que el ataque pueda falsificar el certificado de algún subdominio sin sentido del sitio web oficial, la identificación del certificado o HSTS, o ambos? También, ¿cómo funcionan juntos HSTS y la fijación de certificados?

certificates certificate-pinning man-in-the-middle hsts

pregunta typos 30.05.2016 - 22:16

fuente

1 respuesta

Lea otras preguntas en las etiquetas certificates certificate-pinning man-in-the-middle hsts

¿Puede funcionar el hombre en el medio con el certificado firmado por una CA conocida y la suplantación de DNS? ¿Puede un atacante extrapolar códigos futuros basándose en códigos pasados y sus marcas de tiempo de un dispositivo TOTP?

score 4 · Accepted Answer

El comportamiento de HSTS es variable dependiendo de si se aplica la directiva includeSubdomains . En el caso de HSTS sin includeSubDomains , un usuario que visita www.facebook.com no los protegería si accidentalmente fuera a ww.facebook.com sin un prefijo HTTPS explícito. Sin embargo, cuando se aplica la directiva includeSubDomains , visitar cualquier subdominio (o el dominio raíz) hace que la regla HSTS se aplique en todos los subdominios. Esto también se puede aplicar como parte de la precarga.

El anclaje es una medida separada y se puede lograr de varias maneras. Los dos principales son los pines precargados en el navegador (por ejemplo, la fijación de Chrome) y Fijación de clave pública HTTP (HPKP) . Otra forma menos común de lograr la fijación es mediante una herramienta como Microsoft EMET que agrega reglas de fijación adicionales al sistema. El objetivo de la fijación es almacenar algún identificador para el certificado (o su certificado de firma asociado) de modo que un certificado falso de una autoridad de certificación comprometida (o laxa) no pueda usarse para comprometer las comunicaciones.

En el caso de las reglas de anclaje precargadas, la clave pública del certificado de firma raíz o el certificado de firma intermedia de la CA se almacena en el navegador y la cadena se verifica cuando se presenta un certificado para un dominio coincidente. Es extremadamente raro ver los certificados de hoja (es decir, el certificado específico real para el dominio, en lugar de un certificado intermedio o raíz) en las reglas de anclaje debido a la dificultad de mantener esta lista cuando existe un equilibrio de carga dinámico.

En el caso de HPKP, esta función funciona de manera muy similar a la de HSTS. Cuando un usuario visita el sitio, se devuelve un encabezado que contiene una lista de hashes de claves públicas para certificados válidos (ya sea firmando certificados o los certificados en sí mismos). Cuando el usuario vuelve a visitar el sitio en una fecha posterior, el navegador ha guardado en caché esta regla HPKP y puede usarla para verificar que el certificado recién presentado sigue siendo válido y no se ha falsificado ni mediante autofirma o por medio de una comprometida) CA. Esta característica también tiene la directiva includeSubdomains , que se puede aplicar al encabezado HPKP para indicar que todos los subdominios deben considerarse parte de esa regla. Una característica adicional de HPKP sobre el anclaje en el navegador es que se debe incluir una clave de firma de "copia de seguridad" debe como parte de la regla de HPKP, para que se pueda utilizar para actualizar la regla de HPKP si los certificados originales expira.

Con estas dos características implementadas y la directiva includeSubdomains aplicada a ambas, se mitigan los siguientes métodos de ataque:

Los atacantes que falsifican registros DNS para apuntar a su IP no pueden proporcionar un certificado autofirmado o cualquier certificado con errores; los navegadores no permitirán un clic cuando la regla HSTS está en su lugar, y la regla HPKP obliga al certificado a coincidir con las reglas de firma dadas.
Un atacante que comprometa una CA, o que opera su propia CA de confianza general (por ejemplo, estados nacionales) no puede suplantar el certificado original con el suyo, ya que HPKP obliga a usar una lista de CA confiables.
Los usuarios que intentan visitar directamente http:// son redirigidos por su cliente a https:// automáticamente; el navegador no se comunicará a través de HTTP simple con el servidor.
Los atacantes que falsifican registros DNS a un nombre canónico falso dentro del mismo dominio raíz no pueden falsificar el certificado para este subdominio alternativo; la directiva includeSubdomains en cada encabezado hace que todos los subdominios estén protegidos.