Ataque de intermediario en el escenario SSL

Question

Estoy tratando de entender cómo afectaría un ataque de intermediario a mi servidor web.

Tengo un certificado autofirmado. ¿Este certificado se puede falsificar mediante el ataque de intermediario, lo que significa que todo lo que envíe desde el navegador será interceptado y modificado?

Si la solicitud se modifica, el servidor web no la descifrará ya que el certificado en el servidor es diferente. ¿Es esto correcto?

La solicitud enviada desde el navegador puede ser interceptada y redirigida, pero los datos de mi servidor no se verán afectados, ¿es correcto?

Estoy empezando a entender la teoría detrás de los certificados, pero sería fantástico si alguien pudiera proporcionar un ejemplo del mundo real del ataque de intermediario y ver qué problemas causó.

Gracias

Answer 1

Como dije en mi respuesta anterior atu pregunta, los ataques de intermediario (si tienen éxito) pueden poseer todos los datos que se pasan de un lado a otro por un canal cifrado.

Los certificados, tanto los autofirmados como los emitidos desde una raíz confiable, pueden ser falsificados, así que no se deje llevar por una falsa sensación de seguridad si emite uno a sus usuarios desde una raíz confiable. El único problema que tengo que superar con uno emitido por una raíz confiable eshacer que su usuario acepte el mío cuando he envenenado su computadora con arp. Si piensa en la mayoría de los usuarios finales, ¿qué tan fácil sería?

¿Puedes ver los problemas ahora?

Una vez que el usuario final acepta MI certificado, soy dueño de la conexión a partir de ese momento y todos los datos pasan a través de mi máquina.

Answer 2

Básicamente, lo que sucede es que usted mismo ha firmado su certificado, por lo que no tiene forma de demostrar que es válido. Por lo tanto, cifra el tráfico muy bien, pero no puedes demostrar que es tuyo. Si un pirata informático puede interponerse entre su sitio y la computadora del usuario e interceptar el tráfico, podrá descifrarlo y leer lo que está sucediendo. (También puede hacer esto registrando un nombre de dominio similar al suyo y esperando un error tipográfico o enviando un correo electrónico que los dirija a su sitio y no al suyo)

User ****** Hacker **** Your website

La razón por la que puede hacer esto es que también puede presentar un certificado autofirmado. Entonces el usuario está realmente en comunicación con el hacker y no con usted. El usuario no puede notar la diferencia. De hecho, si quiere, el pirata informático puede volver a cifrar el tráfico y enviarlo de regreso a su sitio e iniciar su propio flujo de comunicación con su sitio utilizando las credenciales de los usuarios. O simplemente observe el tráfico despejado mientras avanza y avanza.

Answer 3

No es que pueda modificar el tráfico. Es que el protocolo de enlace SSL comienza sin cifrar y el servidor envía un certificado SSL para que el cliente lo utilice a partir de ese momento. Si el atacante está allí desde el principio, puede reemplazar este certificado inicial con el suyo propio y luego usar el que envió el servidor para cifrar/descifrar el tráfico hacia/desde el servidor, usando su propio certificado para enviárselo.
Si el certificado está firmado por una autoridad certificadora, es un poco más difícil reemplazarlo por uno falso que también esté firmado por una CA. Sin embargo, el atacante puede reemplazar fácilmente este certificado por uno autofirmado, de ahí la advertencia.

Answer 4

Hay dos puntos a considerar al verificar un certificado:

• verificar que ha sido emitido por una entidad de su confianza, y
• verificando que coincida con la identidad del servidor con el que estás intentando contactar.

Certificados emitidos por CA

ElInfraestructura de clave pública utilizando certificado X.509. especificacióndefine la estructura a implementar para esto. Es un modelo jerárquico en el que se obtiene un árbol, cuya raíz son las autoridades de certificación (CA) y sus hojas son los certificados de la entidad final (en particular, los certificados de servidor).

Los certificados de CA raíz tienden a estar autofirmados. Varios de ellos están incluidos de forma predeterminada en su sistema operativo o navegador. Esa es la parte del "acto de fe", en la que usted confía en que su proveedor de sistema operativo/navegador haya examinado las CA para hacer su trabajo correctamente. Algunas de las grandes CA comerciales son Verisign, Thawte, ...

Luego, una CA puede firmar otros certificados. Puede verificar un certificado que nunca antes haya visto comprobando si ha sido firmado por una CA en la que confía. También puede haber CA intermedias. Por ejemplo, el certificado de https://www.google.com/ha sido firmado por "Thawte SGC CA", que a su vez ha sido firmado por "VeriSign, Inc./Autoridad de certificación primaria pública de clase 3" (Estoy acortando los nombres aquí para simplificar). El trabajo de la CA es verificar (por medios externos a la PKI) que la persona/institución a la que emite el certificado es el propietario legítimo de ese nombre de host (por ejemplo, www.google.comLa forma en que varía esta verificación fuera de banda, para certificados que no son EV, esto a menudo se realiza simplemente enviando un correo electrónico a la dirección que registró el nombre de dominio (disponible en el).quién esdirectorio).

Una vez hecho esto, supongamos que no sabe si confiar https://www.google.com/, el cliente verifica este certificado con los anclajes de confianza que tiene (las CA, a menudo importadas previamente por los proveedores de sistemas operativos/navegadores). Si se conecta a www.google.com, el navegador obtiene el certificado y luego puede calcular la cadena hasta el emisor principal (hay una entrada de emisor en cada certificado), hasta que encuentra uno en el que confía (en este caso, el de Verisign). Hasta ahora todo bien, el certificado es confiable. El segundo paso consiste en comprobar que efectivamente este certificado es para esta máquina. Para HTTPS, esto se hace verificando que el nombre de host esté en la extensión del nombre alternativo del sujeto del certificado o, como alternativa, que esté en la entrada "Nombre común" (CN) en el nombre distinguido del sujeto. Esto se explica enRFC 2818 (identidad del servidor).

Aquí los posibles intentos de ataque son los siguientes:

• Los atacantes falsifican un certificado (para ese nombre de host o no), con su propia CA. Dado que su navegador no reconoce su CA, el certificado no se verificará. Incluso si falsificaran el nombre del emisor, no podrían falsificar la firma (porque usted verifica usando la clave pública usando los certificados de CA en los que ya confía). Uno de los mayores problemas aquí fue la solidez de la firma: los ataques de colisión se han demostrado utilizando el algoritmo de resumen MD5, por lo que las CA ahora usan SHA-1, que se considera más robusto. Si considera que RSAwithSHA1 o DSAwithSHA1 son lo suficientemente robustos, no debería tener ningún problema allí.
• Los atacantes obtienen un certificado legítimo de una CA conocida, pero para un nombre de host diferente (ya que una CA no debería emitirlo a otra persona). Digamos que obtienen www.example.com. Estás intentando conectarte www.google.com, ellos redirigen el tráfico a su casilla, que mostrará un certificado que será verificable por una CA en la que confíes, pero para www.example.com. Aquí es donde la verificación del nombre de host es importante. Su navegador le advertirá que no está conectado al host que deseaba.

Este sistema está diseñado para garantizar que, si un MITM redirige el tráfico a su máquina, el cliente no aceptará la conexión. Por supuesto, esto sólo es válido si el usuario no ignora las advertencias mostradas por el navegador.

Certificados autofirmados

Es el mismo principio, excepto que usted es la CA y este certificado autofirmado también puede ser directamente el certificado del servidor. Si crea su propio certificado autofirmado y lo coloca en su máquina, también puede importarlo en su navegador como una autoridad confiable, en cuyo caso sigue el mismo procedimiento descrito anteriormente.

Algunos navegadores, como Firefox, te permitirán agregar excepciones permanentes a estas reglas. Si sabe, por algún otro medio (por ejemplo, el administrador le entregó el certificado en persona), cuál es el certificado para la máquina a la que desea conectarse, puede optar por confiar en ellos explícitamente, incluso si no han sido firmados por una CA en la que confía o si el nombre no coincide. Eso sí, para ello sí que es necesario saber a priori y de forma explícita cuál debe ser este certificado en concreto.

Si en cualquiera de los casos, el usuario elige ignorar las advertencias y acepta ser redirigido a una conexión con un certificado que no es de confianza, entonces el MITM (con ese certificado que no es de confianza) puede ver/redireccionar/alterar el tráfico.