4 ms·
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
by MrRadar 6y ago
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-ddos-attack-a-8058 https://www.bankinfosecurity.com/github-hit-by-its-largest-d...
- apple_innocent 6y ago"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:// http:// or https:// https://, rests with the user, not the server.
- MrRadar 6y agoEncrypting 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.
- apple_innocent 6y agoI 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.
- MrRadar 6y agoI 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?
- apple_innocent 6y ago"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.
- MrRadar 6y agoOK, 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?
- apple_innocent 6y ago