No puedes autenticarte como el servidor
El problema no es que el servidor "haga un escándalo", no lo hará. Puede engañar fácilmente al servidor para que piense que usted es el usuario. El usuario no se está autenticando con un certificado SSL. El problema es que no puedes engañar al usuario o más específicamente al navegador del usuario. Recuerde que para un ataque MITM el atacante necesita establecer conexiones con ambas entidades (por lo tanto, en el medio).
Cliente < --------- > MITM Attacker < ---------- > Servidor
Con http es trivial. Usted se sienta en el medio y pretende ser el servidor para el cliente y pretende ser el cliente para el servidor. El problema con https no es el enlace entre usted y el servidor (en lo que respecta al servidor, usted es el cliente). El problema está en el enlace entre usted y el usuario.
Cuando el usuario navega a enlace el navegador esperará:
- Que se devuelve un certificado SSL
- Que el certificado SSL tiene example.com en el nombre de host
- Que el certificado SSL está firmado (o indirectamente) por un certificado raíz en su almacén de claves de confianza.
Si bloquea al cliente para que no obtenga el certificado ssl de example.com, el navegador le dará un error al usuario (tiempo de espera de http)
Si envía al usuario un certificado válido (firmado por una CA) para otro nombre de host, el navegador le dará un error (nombre de host incorrecto)
Si envías al usuario un certificado para example.com que creas y no está firmado, el navegador le dará un error al usuario (cert no es de confianza).
Si le envía al usuario un certificado para example.com que usted firma con otro certificado de CA que controla, el navegador le dará un error (no es de confianza) porque no confía en su certificado de CA.
Tira SSL (redireccionando al usuario a http)
La forma en que SSL Strip funciona es redirigiendo al usuario de https a http. El usuario navega a enlace y usted intercepta que se envía un redireccionamiento al usuario a enlace y aún así establecer una conexión segura entre usted y el servidor.
Cliente < --- HTTP --- > Atacante MITM < ---- HTTPS --- > Servidor
Comprende que estás potencialmente comprometiendo al usuario con otros atacantes reales. Si el usuario se está conectando, por ejemplo, el wifi de la empresa, cualquier persona a través del wifi podría robar información confidencial porque ha eliminado el ssl.
Sin embargo, el usuario puede notar que está en http y no en https ( por qué el sitio web de mi banco no muestra una barra verde ). Lamentablemente, esto no es tan común que la mayoría de los usuarios simplemente asuman ciegamente que están seguros, por lo que HSTS fue desarrollado para proteger a los usuarios de este tipo de ataque. Si el navegador es compatible con HSTS, el sitio usa HSTS y el usuario ha estado en el sitio antes (o HSTS fue precargado por el navegador), el usuario recibirá un error / advertencia cuando redireccione a http.
La computadora del usuario "Infect" con un certificado raíz "confiable" que usted controla
La única forma de evitar HSTS (especialmente con la precarga) es crear un certificado de CA para el que tenga la clave privada y la instalación en el navegador / os de la víctima. Luego, cuando haga MITM al usuario, puede crear un certificado para example.com, fírmelo con su certificado CA de MITM. El navegador validará el certificado de example.com que creó, verificará la firma que será válida y procederá de un certificado en el que confíe (en el almacén de claves raíz de confianza). Esto requerirá acceso administrativo en la máquina del usuario.
Incluso esto no funcionará si se ha utilizado la fijación de clave en el navegador para tomar nota del certificado "real" de example.com.