Hacker News Reader

Comment by sillysaurus3 | Hacker News Reader

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.)

View on HN

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.

However, the proxy could drop packets obviously.

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.

Yes, the proxy has full control of the connection, they're essentially a MITM with all that implies.

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).

Of course, a untrusted proxy can do a mitm attack, getting access to all of your data. Even a trusted one! There are some famous cases as nokia https://gaurangkp.wordpress.com/2013/01/09/nokia-https-mitm/ or opera mini http://manurevah.com/blah/en/blog/Opera-Mini-MITM-attack

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.

Yup you are right.

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.

I believe locally-installed certs can override cert pinning (to allow corporate DLP boxes to work, and such).

Reply on news.ycombinator.com