[ashray]

What I don't get is why the industry has decided to force encryption with HTTP/2? The spec does not require TLS however almost every single major browser only supports HTTP/2 with TLS.

Is this a push to make the internet more secure by design or is there some other reason behind this?

What's the speed difference between HTTP/2 and HTTP/1.1 without TLS? I'm sure this is hard to test because of lack of client support.

It is not always trivial to move large legacy projects to secure connections (especially because any resource, even an image, being loaded from an insecure endpoint results in a warning) so the result is now:

- Support TLS first

- Then implement HTTP/2

Consumers will not be able to take advantage of the better HTTP/2 performance without big changes to websites to first support TLS on the server end. Why?

[mholt]

> What I don't get is why the industry has decided to force encryption with HTTP/2?

For reliability and success of the protocol. "Reasons for choosing TLS-only include respect for user's privacy and early measurements showing that the new protocols have a higher success rate when done with TLS. This is because of the widespread assumption that anything that goes over port 80 is HTTP 1.1, which makes some middle-boxes interfere with or destroy traffic when any other protocols are used on that port." (Source: http://http2-explained.haxx.se/content/en/part5.html)

Believe me, TLS is very much necessary in practice here.

[halomru]

>This is because of the widespread assumption that anything that goes over port 80 is HTTP 1.1, which makes some middle-boxes interfere with or destroy traffic when any other protocols are used on that port.

I'm not convinced that's a real problem once traffic leaves your servers/CDN. In practice I have seen lots of protocols use port 80, since 80 is the port that's most likely to be unrestricted on even the strictest corporate firewalls.

[noselasd]

It's a real problem. There are plenty of middle boxes around either at ISPs/cell operators or in residential gateways/modems that interfers on port 80.

[danudey]

We make mobile games for iOS and Android, and we've mostly switched to HTTPS because of people injecting garbage (ads, mostly) into our content.

[srj]

The HTTP/2 protocol negotiation happens with ALPN, which is a part of TLS. It's possible to simply not negotiate or find another means, but in practice there are many proxies on the Internet that assume all port 80 traffic is HTTP/1.1 and will break an HTTP/2 connection.

[halomru]

That's simply to give web developers another incentive to use TLS. There is no real technical reason beyond that.

>any resource, even an image, being loaded from an insecure endpoint results in a warning

By nessesity, unsecured resources undermine TLS's integrity guarantees. An unsecured image on my bank's website would mean that anyone who MitMs my connection can swap that image to show a message that appears to be from my bank.

The internet is no longer the trustworthy place it was in the eighties. HTTP2 is one attempt to make developers catch up with ye that.

[ashray]

I agree with you 100%. What I don't get is the tradeoff that happens in this case for sites that do not necessarily need to be secure by design (what about a news site that has no login/etc or a blog?). Should all information on the web be encrypted by default?

Should all those sites not benefit from the speed improvements that HTTP/2 offers? It seems unusual to couple HTTP/2 with TLS, again, it's not the spec that does this but the vendors who are doing this.

The bigwigs of the industry will throw tons of developer resources at converting everything to TLS (haven't they already for the most part?) and then deploying HTTP/2. They already throw tons of money at being the fastest out there.

I find it interesting (worrying?) that while a spec does not specifically enforce a requirement, large browser vendors have enforced it and created an imperative for pretty much everyone to comply if they want the benefits of the new protocol.

[danudey]

There are a surprising number of ISPs that will happily inject content into users' data streams - we've had to go HTTPS with our apps to prevent this on several occasions.

Who's to say it won't be ads next? Who's to say they won't be serving exploits to clients? One lazy ISP trying to make a quick buck could serve untrustworthy ads to millions of people and have it show up on other sites, making it difficult initially to determine the source of the exploit, and preventing browsers' 'untrustworthy site' warnings from protecting users.

The same thing happened years ago with RBLs, where ISPs would return fake DNS results for sites which didn't exist, breaking RBL lookups completely and severely hampering spam detection for any users using those DNS servers. Worse yet, some of them prevent you from accessing other DNS servers directly, making it impossible to avoid their breakage.

If there's one thing we've learned in the last ten years it's that we can't trust ISPs to stay in their roles as providers of connectivity and services; they all see the potential for more money and never seem to grasp the downsides until it's too late.

[mikeash]

Should J Random Hacker be able to alter your news feed to feed you fake information?

I think one reason they insist on TLS is because the need for privacy and integrity is a lot bigger than most people realize, and historically server folks have not reliably made the right choice.

[ashray]

No, of course not. What would be the economic incentive towards carrying out a sufficiently complex MITM attack on a blog or a newsfeed?

In my experience the times that I've had users complain about "injected" information or weird ads, it's usually come from malware that resides ON their system. There's no MITM required for this. The injection happens client side through a browser plugin or some other resource that gets loaded up along with the page. TLS wouldn't fix this in any way as far as I am aware.

[halomru]

>What would be the economic incentive towards carrying out a sufficiently complex MITM attack on a blog or a newsfeed?

Injecting ads is a relatively harmless but hugely profitable application we are already seeing.

On the more serious side, changing news feeds has huge potential for governments. It's the perfect propaganda tool, and with advances in machine learning the cost of doing this on a gigantic scale shrinks every day.

[mholt]

> What would be the economic incentive towards carrying out a sufficiently complex MITM attack on a blog or a newsfeed?

Gee, I don't know, imagine plastering your brand all over the NYT homepage or libelously accusing your political opponent of some heinous crime or behavior or injecting your malicious script onto millions of visitors' machines.

> There's no MITM required for this.

Um, local scripts injecting ads are still MITM by definition.

> TLS wouldn't fix this in any way as far as I am aware.

Yes it would. That's why pesky "antivirus" software MITMs TLS connections on your local computer.

[ashray]

The context of this discussion is smaller publishers/bloggers/etc. If you see the grandparent post it's clear that industry leaders will not find it technically challenging to get on board with both TLS and HTTP/2. The question I asked about economic incentive is not in the context of the NYT homepage but thank you for the unnecessary snark.

A local script injecting an ad is not the same kind of MITM attack and is no way mitigated by enabling TLS.

The discussion here is not about whether encryption is bad. My aim was to ask about whether no encryption = no HTTP/2 for you and why this is the case. I understand that the technical reason at the protocol level is because of obsolete proxies often sitting on port 80 and also the protocol negotiation that needs to take place.

[ctz]

> What would be the economic incentive towards carrying out a sufficiently complex MITM attack on a blog or a newsfeed?

We've already seen large scale MITM be used for political reasons: to DDOS github off the internet in retaliation hosting anti-censorship technologies.

[niftich]

It's an integrity issue for sites that you trust. Some people's personal trust model is such that they trust no one and nothing published on the web sways their opinion; if that's indeed true then no amount of MitM content injection is going to influence them one way or the other -- but neither is truthful content. For these people, everything on the web is 'entertainment', and none of it is 'staying informed'.

For people who do use the web to stay informed, reputation, ie. trust, matters. I might think that CNN publishes clickbait alonside real news, but I trust that CNN won't put blantaly false breaking news warnings above the fold about made-up events. Or, if I don't trust a single source in isolation, I trust that if several news outlets are posting breaking news warnings about the same event at the same time, that event must be real. How else would you find out?

In this day and age, refusing HTTPS means that the site author has done a cost-benefit analysis and decided that their content is not important enough to be verifiably originating from them, and that their reputation is not valuable enough to be protected from malicious tampering. In that case, why host a self-hosted website at all?

[cmdrfred]

>What would be the economic incentive towards carrying out a sufficiently complex MITM attack on a blog or a newsfeed?

This is what you can do with a single fake tweet: http://business.time.com/2013/04/24/how-does-one-fake-tweet-...

[mholt]

> what about a news site that has no login/etc or a blog?

HTTPS. It's not just about privacy. You want people changing the content of your articles and injecting ads or malicious scripts for your visitors? As the owner of the site, you have a responsibility to protect them and protect yourself from liabilities.

Are you using the transport layer? Then you need Transport Layer Security.

> Should all those sites not benefit from the speed improvements that HTTP/2 offers?

So, nope. Not until they can guarantee integrity and authentication.

[witty_username]

> Should all information on the web be encrypted by default? Yes. There is little cost to doing so.

[ecnahc515]

While you're points are valid, you're wrong about there being no technical reason. There is a valid technical reason, and that is, if http2 didn't require TLS, and ran on port 80, in practice it would get MITMed by software expecting plain http 1.1 and result in a broken mess. Requiring TLS is a technical decision that allows you to avoid that issue.

[jamra]

I can't speak on behalf of the internet, but I believe that since HTTP/2 is faster than HTTP/1, a decision was made to force TLS for the sake of privacy.

I remember watching a video of some Go developers writing an HTTP/2 client and one of them mentioned that there was an agreement to never accept non encrypted connections.

[haimez]

Because the protocol is now significantly more complex that HTTP 1.X and intermediate network services (proxies, etc) would not play well with a unencrypted stream. TLS guarantees that the intermediaries are either fully terminating the client connection and proxying to the server in whatever protocol it supports, or not manipulating the stream at all because it's unable to know the contents therein.

[mtgx]

> Is this a push to make the internet more secure by design

Yes? I thought that was obvious. Google is even giving higher ranking to HTTPS sites now and even showing HTTPS versions of the site by default on Google, I believe.

If I'm not mistaken Apple is also pretty much forcing all app developers to use encrypted TLS connections for their apps (although there may be some exceptions).

[feld]

The requirement for HTTPS everywhere is growing on me, especially after recent papers indicating that traffic is altered even on backbone provider networks.

[mtgx]

Without it we'd certainly see much more aggressive ad injection from wireless carriers.

[kpcyrd]

> It is not always trivial to move large legacy projects to secure connections

Actually, it is:

https://www.w3.org/TR/upgrade-insecure-requests/