For anyone unnerved by this, you can still get around it by routing your traffic via SOCKS proxy to an external host, but of course this assumes that 1) your employer isn't blocking SSH, 2) you have the authority to install PuTTY and Firefox (not sure if Chrome has SOCKS proxy support) and 3) you have an external server to proxy through (if you have a Linux machine somewhere, you're probably already configured to allow this). And make sure you route your DNS through SOCKS as well.
[1] http://www.rutschle.net/tech/sslh.shtml [2] http://www.pond-weed.com/multiplex/ [3] https://github.com/stealth/sshttp [4] http://zwitterion.org/software/ssh-https-tunnel/ssh-https-tu... [5] http://proxytunnel.sourceforge.net/ [6] http://www.agroman.net/corkscrew/
But on the large scale that will never happen. Maybe in corporate networks but I doubt that this will become widespread.
Maybe not ubiquitous, but multiple governments already use fake certificates to spy on secure connections, and it is incredibly common in corporate environments.
The proxy vendor MAY provide its own issuer description in lieu of faking the original, but it by no means has to. Fake certs can look just as authentic as real ones if your browser trusts the root cert that signed them.
If you want to verify a certificate is signed by a "real" trusted CA, use a program that traces the chain of trust against a list of CAs that ship with browsers. I have such a tool here: https://github.com/psypete/public-bin/blob/public-bin/src/ne...
Plugins like Convergence will verify who signed a cert for you, assuming the notaries aren't blocked by your corp proxy (and currently blocking any of them will kill the whole chain of trust, so it's not as useful as it seems).
In any case, your HTTP client having the right software and right root certs is the only way to know what is valid and what isn't. You could compare the fingerprint from your 3G phone's browser (or the issuers in the chain's fingerprints) to the cert from your PC's browser. Unless the phone is managed by your company too, in which case they can install the fake root cert there as well...
What's also kind of funny is it's easier to spoof a cert on a mobile phone than a PC. Phones can be updated over-the-air by the mobile provider while your PC has to give some kind of admin rights to your ISP. Since mobile devices are "the future of computing" this makes who controls the mobile device a scary proposition, especially in countries with oppressive regimes (or countries that like to shove internet legislation down your throat without asking).
Unless there's a way to detect whether a cert is installed somehow?
Also, since bank websites and email are the most frequently accessed encrypted sites, a company would be exposing itself to ruinous liability if a data breach led to the release of private employee information, i.e., bank records. No company would take on that sort of liability, and you can bet that any competent legal counsel would make the company aware of this before they implemented something like this.
Yes. I just said corporate networks are spying on HTTPS connections.
It's really simple to implement. Get some kind of web proxy that has support (Websense is pretty popular, amazingly) and generate a root cert on the box. Then use a group policy on your AD server to distribute the root cert to all the client systems. Now Websense can decode the HTTPS traffic by issuing its own fake certs to clients and handle the "real" HTTPS handshake on the frontend proxy side.
Result? Your websockets are still going to get fucked with by proxies. Can we please stop building fake protocols on top of real protocols now?