Si no le preocupa que se le solicite al usuario, intercepta la mayoría de las conexiones HTTPS mediante proxy. En lugar de permitir que el usuario se conecte directamente al sitio que ha solicitado, lo conecta a un intermediario que controla y luego lo usa para conectarse al sitio que solicitó. De esta manera, la sesión HTTPS del cliente finaliza en su buzón, con su certificado SSL del que posee la clave privada y, por lo tanto, descifra el tráfico del lado del cliente y, dado que es su proxy, el que realiza la conexión al servidor en el que se encuentra. realmente quería hablar, su proxy ahora es el cliente para esa conexión SSL, y también tiene acceso completo al tráfico desde ese lado.
Esto indicará al usuario porque, por supuesto, su certificado SSL, el de su servidor al que se conectan los usuarios, no será un certificado válido para los sitios a los que realmente intentan acceder, por lo que las aplicaciones de los clientes (o deberían al menos) ver esto como un ataque y advertir a los usuarios que no confíen en la conexión. Como mencionó P4cK3tHunt3R, puede evitar la advertencia instalando su certificado como una raíz confiable en los dispositivos cliente, en cuyo caso ya no podrán discernir (en general) que el certificado no es de hecho válido y confiable para el sitio. están tratando de conectarse.
Además de los servidores proxy, existen otras formas de degradar las conexiones como un MitM activo, como SSLStrip, que funcionará en algunos casos y no en otros.
En algunos casos, el proxy funciona incluso mejor que lo anunciado, particularmente con aplicaciones móviles, que son notorias por ignorar las advertencias de los certificados y aceptar felizmente certificados no confiables sin molestarse en informar al usuario de que nada está mal. En otros casos, no funcionará en absoluto, debido a prácticas como la fijación de certificados donde un navegador u otra aplicación solo confía en certificados específicos , y se negará a aceptar su certificado, incluso si de lo contrario sería válido y de confianza.