Hacker News Reader

Comment by superkuh | Hacker News Reader

It's security theater in the contex of HTTPS only on websites that aren't performing financial transactions. The idea that someone might figure out a way to do a TLS downgrade attack and force someone over to the HTTP site is not justification for HTTPS only in those cases.

I love TLS. I think it's the least worst system we have. But HTTPS only outside of it's proper context does a lot of harm and it's pointless. HTTP and HTTPS are two great tastes that go great together.

View on HN

HTTPS-only is valuable for three reasons. Firstly it prevents MITM attacks that inject Javascript (or other) payloads into web pages which can be used e.g. for DDoS attacks. We saw this with the Great Firewall being used to attack Github for hosting material that was censored in China by hijacking an analytics script that was being served over HTTP[1].

Secondly, it makes passive surveillance and data gathering much harder. You can still track which sites a user connects to, but you can't see which pages they access or the contents of those pages. You can still actively intercept those connections via MitM but that requires users to manually install an MitM certificate on their system so they should be aware when it's occurring.

Thirdly, it makes it harder to intentionally block or break HTTPS altogether at the network level to force users to fall back to unencrypted HTTP. (TLS downgrade attacks are different from and much more difficult than, for example, just blocking all traffic on port 443.) If there's no unencrypted fallback, then users will complain loudly when they can't access sites.

If your main concern is old computers the solution is to use a proxy that strips the encryption.

[1] https://www.bankinfosecurity.com/github-hit-by-its-largest-d...

"If your main concern is old computers the solution is to use a proxy that strips the encryption."

Why not also use the proxy to add encryption when it is missing. Then "HTTPS-only" is not necessary. The decision of which scheme to use, http:// or https://, rests with the user, not the server.

Encrypting data after it has transited untrustworthy networks (which could have surveilled or modified it before it gets to you) is about as useful as closing the barn door after the horse has already escaped. The encryption (and authentication) needs to happen at the origin to get any security benefit.

I think you misunderstood. A localhost-bound forward proxy on the client side encrypts the traffic. For example, haproxy can be used for this purpose. It detects the presence/absence of SSL on connection and if absent it adds encryption before the traffic enters the network. Sorry I should have been more specific as "proxy" is a loaded term.

I must still not understand what you mean. Where is the encryption being added? Could you draw me an ASCII network diagram (showing the server, the browser, and the intermediate network hops) with an indication?

"Where is the encryption being added?"

It is being added by the proxy server listening on the loopback which connects to the remote website.

Browser connects to forward proxy on port 80, forward proxy (compiled with SSL library) connects to target IP on port 443.

This is how one can, e.g, use clients that are not SSL-enabled to access websites, etc. that require SSL.

For example, if forward proxy is listening on 127.0.0.1:80, we can make an encrypted connection to example.com using original *hobbit netcat which does not support SSL.

   echo -e 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n" |nc -vvn 127.0.0.1 80

It is probably more popular to use stunnel for this purpose instead of a forward proxy.

OK, now I understand what you meant about "a forward proxy on the client side" (as that's exactly what I mean by "use a proxy to strip the encryption"). But I still don't understand why that allows you to not have to use HTTPS-only on the originating server to get the benefits of HTTPS-only?

Because I the user am running a forward proxy to encrypt all outgoing HTTP requests, I do not have to rely on "HTTPS-only" on the server side. I enforce "HTTP-everywhere" on the client side. That's the theory anyway.

To be honest there are still some sites that do not, and will probably never, offer HTTPS and I have to account for those with the proxy setup. For these websites I might assign them a different local IP that does not add encryption.

In running this setup there are some times where I find that for one reason or another "HTTPS-only" on the server side has failed to catch every instance where http:// should be https://. I use many different clients, the least of which is the modern browser which may have some whizbang features to try to enforce "HTTPS-everywhere". The clients I use more are simpler, less complex and do not have such features. Instead of relying on the modern browser, I rely on an extensive proxy configuration to make sure everything gets encrypted (when appropriate).

Reply on news.ycombinator.com