> extra piece of code that does things like send all data entered in forms to your server
Assuming you're injecting JS, the site isn't SSL meaning all that data is available to the proxy anyway (its part of their operation). The botnet angle is much more interesting than the loss of privacy one.
What happens if the user tries to visit a site with https, like gmail? Can the free proxy still be destructive? I assume yes, but I'm interested in hearing about the technical details.
Most of the web (you type the URL into the proxy's webpag) "HTTPS" proxies found by Google search only give results that the proxy has encrypted. However, through TCP proxies (through which HTTPS can be supported), the attacker can only do an SSL-strip attack.
Mainstream browsers do not readily support HTTPS connections to proxies. FF only very recently introduced this, Chrome needs you to specify the proxy URL on the command line.
Even when you do, the connection to the proxy being HTTPS has nothing to do with the "https://" you see in the browser.
Bottom line: do you see a green "https://...google.com/..." ? Then you are safe. SSL stripping will NOT go undetected, without compromising your computer in some way (fake root CA).
For more info, search the net for SSL strip tools and look at their features. E.g.: homograph domain names, rewriting https:// links to http://, or using self-signed CAs (will cause SSL warning). If you find a real, clean SSL strip, make sure to post it here to HN. Guaranteed you will make the front page ;)
Wait... If people can't use proxies to surf with HTTPS, then how does HTTPS provide any security when using Tor? Tor is basically a proxy, and the only reason Tor is safe is because of HTTPS-everywhere. I'm having trouble figuring out why HTTPS works on Tor but not for these kinds of proxies.
My understanding is that you should be able to set up a TLS session with a destination server while you're routing your traffic through a robot-in-the-middle. And the robot shouldn't be able to harm your content in any way, due to the encryption. (I originally said that a free proxy could still cause harm, but if HTTPS is involved, I'm pretty sure that's not true, otherwise Tor wouldn't work. It could drop the connection, but it shouldn't be able to modify anything.)
Tor is a TCP proxy. It doesn't matter to HTTPS; the TLS part is being done with the client through the TCP connection (which is actually routed through Tor but HTTPS doesn't care). And HTTPS through Tor is as secure as doing it through any other way.
_However_, many free online proxies, e.g. HideMyAss, will simply fetch the page and send it to the client encrypted using their key. In this case, the TLS part is being done with the proxy website, not the actual website being requested. (Basically original website sends encrypted data to the proxy; proxy decrypts it and then encrypts it with its own key; proxy sends to browser.)
(Tor, however, will simply send the raw TCP packets back to the client).
HTTPS tries to perform two goals:
encryption: all the data is encrypted which means that a malicious agent can not sniff the data
authentication: since the data is signed by the website's key it can't be modified by an attacker.
The way HTTPS works is so that it's impossible to sniff the data or modify the data without having the session key (that might not be the correct name; but I don't remember). The session key is stored on the client and server. Without access to either of these machines it's impossible to break HTTPS.
Right, of course. Thanks so much for clarifying the concepts in my head. It's difficult to keep track sometimes.
Would it be true to say that HTTPS-over-proxy provides zero security for the end user, since a proxy must be able to encrypt raw HTTP requests/results on behalf of the client? In other words, the proxy can be blatantly malicious against the user, and the client won't even be able to realize that. The only security would be against any third-party eavesdroppers (someone else besides the user, proxy, or final website).
I might be wrong about that too, but I'm trying to grok it.
No, correctly configured, HTTP proxies just forward the connection on, so you can verify the TLS on your end. That's the default you'll get from your browser.
However, you can configure a proxy to intercept and re encrypt things. But the client (your browser) must trust the certificate that's re encrypting, which won't happen unless the proxy's CA cert is installed on your system. This most often occurs in corporate environment, where they control the endpoints.
Of course, if you're not careful, the proxy can do sslstrip and such, tricking users into not using/checking https. But if you're careful and check for HTTPS, you're OK in theory (assuming TLS works, no vulns, etc).
They say it is just for caching purposes (if the html data is encrypted they cannot serve cached images and so), but who knows what they do with your data as credit cards, etc.
That's not true. HTTPS over insecure proxies is safe, as long as you aren't getting SSL certificate warnings (i.e. the broken lock icon, or a big red warning).
If a man in the middle proxy decrypted the content and re-encrypted it, it would be using a different public key than the one that belongs to the original website, and your browser would know immediately and warn you, probably also preventing you from even loading the page.
The proxy would have to be trusted on your computer as a Certificate Authority, at which point you've given the proxy the power to say "trust me, this public key really does belong to Google". Even then, in many browsers the certificates for common websites are pinned, so if you tried to go to gmail.com for example and a proxy was intercepting it, and was also trusted as a certificate authority, chrome would still prevent the page from loading.
Assuming you're injecting JS, the site isn't SSL meaning all that data is available to the proxy anyway (its part of their operation). The botnet angle is much more interesting than the loss of privacy one.