Hacker News Reader

Comment by blackhaz | Hacker News Reader

I can save about 30% of traffic by optimizing content via HTTP. Can't do that with HTTPS without MITM or similar questionable practices breaking the purpose of HTTPS. While you're sitting on a 100+ Mbps DSL, somebody in the middle of Africa is struggling on an ISDN-like link.

View on HN

Optimise for the most common case. I imagine there are far more people in the US with broadband connections being put at risk of MITM attacks than people in Kenya with very slow internet trying to look at the US governments website.

I am not against HTTPS per se. Use it for sensitive content.

How do you get around the risk of MITM attacks? It's a sensitive site, given the level of authority it carries for the average user.

If you live in a country where you can't trust your ISP then there is a very real MITM risk.

What exactly are these techniques that work in plain HTTP but not in HTTPS? It seems like the difference between the two does not pertain to the actual content at all, but I am more curious than knowledgeable in this case.

Intermediate nodes can cache http traffic, but not https.

Also intermediate nodes could compress or shrink images or do similar types of things.

> Also intermediate nodes could compress or shrink images or do similar types of things.

And we come back a full circle. Even if the image is not sensitive, I'm glad I can force https to workaround my ISP being "helpful" and shrinking images.

As far as I'm concerned, that third parties can change the content of a response mid-air is exactly the reason that you should use HTTPS. If you rely on handing unencrypted data over the internet to a third party provider, you have to accept that other parties may also modify the requests and their responses.

You may think that it isn't a big deal because you aren't serving sensitive information, but if your users are dropping in from a random hotspot or are in one of the countries where ISPs seem to be able to do whatever the hell they want, there are tons of possible intrusions, ranging from inserting ads or replacing the entire response with a gentle reminder to pay your internet bill, to inserting outright malicious software.

It's like leaving your front door unlocked just for the convenience of being able to walk inside without unlocking it.

Supporting caching doesn't necessarily mean intermediates can modify the requests/responses mid-air. You can still hash and sign content, and servers can cache these responses.

Nonetheless, that approach seems to be a way of the past. HTTPS is essentially expected now, so CDNs are required to achieve similar performance - Great news for CDNs ;)

Reply on news.ycombinator.com