Encryption is not a panacea. As more websites use HTTPS, more corporate networks are installing content filters that passively filter HTTPS content.
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?
Interesting, I actually hadn't considered the possibility of an employer issuing fake certificates to peek at its employees' encrypted sessions.
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.
If they're proxying HTTP traffic usually they'll block SSH and other protocols. To work around this use an HTTPS/SSH multiplexer[1][2][3] or a simple reverse proxy to accept HTTP[S] connections and connect them to an SSH server on the backend. For the ssh client use a ProxyCommand tunneling app[4][5][6] to turn an HTTP[S] proxy request into a two-way socket, and you have an SSH connection over HTTP proxies.
This won't work with our games. We verify that the certificate was created by our CA and reject anything else. Someone would have to patch the game to bypass that. It also won't work on mobile phones that people use themselves.
How? Is this some JavaScript magic i'm unaware of? Because the actual connection from the proxy to your site uses your site's valid certificates; only the client to the proxy uses a "self-signed" one. Are you using client certificates?
We're more in the area of things that actually are not websites than websites. The websocket stuff I added as an experiment and if people want to use our stuff to make HTML5 applications without a proxy server in between. If it's indeed between browser and website someone could MITM it of course if that person can also give you a fake security certificate into your browser.
But on the large scale that will never happen. Maybe in corporate networks but I doubt that this will become widespread.
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.
I would be surprised if this passed muster in US courts, that an IT dept could present fraudulent information to an individual in order to access private data, vs just blocking that traffic.
From what I've heard, US employees have very little legal right to privacy while at work, even if doing things or visiting e-mail accounts of a personal nature. Regardless of whether the practice would survive a legal battle, it is already widespread.
Unless I'm mistaken, a cursory examination of the certificate supplied to your browser should show that it is one of those "mitm" root certs and not the certificate for the website you are browsing. That should make it simple to at least know your encrypted traffic is being hijacked.
A cursory examination of the certificate will appear to be exactly the same as the "real" one, with the exception of lengthy obscure keys and numbers that nobody would identify unless they compared them to the original side by side.
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.
Well yes, if you've got the same server and cert. Often the SSL frontend of big websites serve multiple certs so you'd have to have all of them to compare against.
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).
I noticed a company I worked at had installed their own root cert on the machine they gave me. I disabled it, but didn't get any warnings about invalid certificates, so I assume they weren't using it to snoop HTTPS traffic.
Unless there's a way to detect whether a cert is installed somehow?
What you are proposing is generally illegal in the U.S. Companies are allowed to snoop on non-encrypted web traffic, because there is no expectation of privacy, but different standards and rules apply to encrypted sites, i.e., including banks.
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?