There sometimes may be an excuse in the extra roundtrips required to set up a TLS connection. For a public blog that doesn't accept submitting any information (like comments), for example, plain HTTP may be fine.
I wish that were true, but honestly, plaintext isn't fine for anything at all in 2015, whether authenticated, important, public or otherwise, whether the network is the internet or a LAN.
HTTP sites have had attack scripts injected into them by nation-states, used to DDoS others on a massive scale - and that capability, and the desire to use it, is unfortunately proliferating rapidly.
Unless you want to be part of that problem, you're going to have to go HTTPS on everything - cat videos included - no matter how important or unimportant you think it is. I really wouldn't be surprised if tcp/80 goes the way of tcp/23.
On a brighter note - the speed difference is negligible with modern cryptography, and as others have mentioned, TLS 1.3 is developing handshakes with less TCP round trips. It's possible that a future protocol (taking into account what's been learned by Google's QUIC experiment) may deliver faster handshakes over UDP if possible to avoid the TCP handshake overhead - there's energetic research in that area at the moment.
Fair enough. TLS 1.3 might introduce a zero-RTT handshake (with some security trade-offs), but that's obviously going to take quite some time to get rolled out.
> For a public blog that doesn't accept submitting any information
TLS is not about accepting information, it's about ensuring that the connection's encrypted and authenticated.
It is still important to prevent unauthorized third parties from watching which articles you're reading. And it's still important that you know that you're reading a blog you expect to read, not a modified version served by someone else (although CA system isn't completely sufficient for this, at least it thwarts less-powerful adversaries from spoofing).
I'm having some difficulty thinking of a scenario where, given the choice, I'd trade off authentication for speed. The information would have to be of so little value that it doesn't matter if the remote party gets what I send or if I get what the remote party sends.
You're assuming that the probability of interception is 100% In reality, the probability of interception is miniscule, but the probability of speed is 100%.
The probability of interception is massively higher than miniscule, see the recent wide scale hijacking of Chinese traffic to DDOS Github or ISPs inserting ads and tracking into responses.
These types of attacks have been hypothetical for a long time, but we're starting to see real world impacts of not using https, and they aren't trivial.
The Greek government inserting ads into that site is very low on my list of concerns, but the additional 200-400ms on the first page load is much higher up.
Am I correct in understanding your point as "there can be no conceivable case where two fewer TCP roundtrips would be worth the speed gain over the decreased security"?
Unless someone care about a single extra round-trip timing, e.g. extra 10-300ms with 300 being quite a stretch? I'm sure it doesn't matter if a blog page opens in 40ms or 55ms - a reader won't tell the difference.
