I know of a company proxy setup that illustrates how the man-in-the-middle attack could work if the browser trusts a dodgy CA.
When using a proxy your web browser makes a connection to the proxy server which then connects to the destination web site on your behalf. When using HTTP the proxy may send back previously cached data, but for HTTPS the traffic is encrypted end-to-end between the client and the server so the proxy just passively passes the encrypted data back and forth, or allows a direct connection. At least that is what is supposed to happen with HTTPS.
In this particular setup the browsers were all configured to trust a new internal CA. Then the proxy was changed to replace every destination SSL server certificate with a new server certificate with the same details signed by the internal CA. As far as the browser is concerned the server certificate is valid: the CN field matches the server hostname and the certificate is signed by a trusted CA.
This change allows the proxy to snoop on all HTTPS traffic without most users being aware. The justification in this case was to be able to scan for malware, and there were assurances that known webmail and banking sites would be excluded from this process.
Something similar could be done by any trusted CA that is able to intercept and modify traffic between the client browser and the destination server.
Another way to achieve this without changing client browsers would be to create a rogue CA certificate like Alexander Sotirov's team did by exploiting MD5 collisions.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds