Not sure why this is being downvoted - maybe people read that as "Cloudflare" (which supports http2) instead of "Cloudfront" (which has yet to support http2).
Well to be fair, once you've read one medium article, the resources should all be cached for the next one you read. It's better than everybody posting on their own site with their own set of 2MB+ static resources.
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?
> 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.
>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.
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.
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.
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.
The requirement for HTTPS everywhere is growing on me, especially after recent papers indicating that traffic is altered even on backbone provider networks.
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.
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.
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.
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.
> 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.
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.
>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.
> 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.
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?
> 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.
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.
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.
> 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).
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.
So add 30 JavaScript files, a few dozen template files to be rendered by one or more of those JS files, a whole bunch of CSS files and at least 6 fonts. HTTP/2 is almost certainly going to perform even better under those circumstances.
Edit: oh and throw in a few videos, everything has a video or two nowadays.
I consider JS and even CSS part of the app... to me a lot of the text, images and videos are external content better on a second/dedicated resource (or CDN). Not to mention that properly supporting video can take a bit of work on its' own if you want to dynamically up/down-grade the stream.
quite a bit of mobile games and apps rely on tens and often hundreds of small resources, each of them needing in periodic caching and update, which makes loading hundreds of resources simultaneously both very realistic scenario and eliminating the need for home-brew caching and resource packs update mechanisms
This demo is not realistic at all, and is pretty contrived to play to the strengths of HTTP/2.
If your page loads stuff from 25 different domains, HTTP/2 barely helps at all.
Likewise if your page is loading MB-size image or script files.
Likewise if your server takes 2+ seconds to render the darn HTML in the first place.
But HTTP/2 is awesome when all the resources come from the same domain, because it eliminates the bottleneck of separate TCP/TLS connections.
This means you don't have to do stuff like bundling resources and sharding domains.
And indeed you shouldn't do this stuff if you're using HTTP/2.
HTTP/2's biggest problem is that nobody is changing their site to take advantage of its benefits.
How websites are built is directly influenced by limitations of HTTP. Browsers limit the number of simultaneous connections per hostname. HTTP 1.1 specifies 2 per hostname, but most browsers allow for 6, some more, some less[1]. So if you are server a bunch of assets at once, you want to spread it across multiple host names (usually edge servers of some sort), so you can get more total, simultaneous connections. HTTP/2 specifically allows for all assets to come from one host. HTTP/2 also has better negotiation on the number of connections allowed and their direction.
These changes will see widespread use once CDNs start to take advantage of it. If you are serving a big enough website to take advantage of HTTP/2, you are using edge servers.
Well HTTP/2 is awesome ... for web applications where you might not have to interact with third parties (ie Google's usecase and they build it in the first place IMHO).
When you have a web site this is a totally different story : beside your content and statics, you'll have maps from a CDN, widgets from third parties, ads ... and so on.
"changing their site to take advantage of its benefits" is just not realistic for normal website.
Given the bundling of JS and often CSS in modern web-apps via build tools, I've been a proponent of serving html/js/css from the same serve as a front-facing API host... this way almost everything comes from the same place. This works better still with HTTP/2. It's getting more and more like having a CDN in between your primary app and the user is of less benefit... having one for an image-store if you have a lot of images may be an okay idea. Images tend to be the bulk of a web page's weight for a lot of apps. Even SPAs.
I think where this will really start to shine is when browsers get js module support internally... combined with http/2 and some smarter server-side rendering, that could be a really nice place to be.
I know others have replied already, but I don't think anyone has outright said it - Yes. This is a realistic benchmark, but only if you remove the many years of "optimizations" we've been baking into web apps.
e.g. Remind me why I should be concatenating all my JS/CSS files into one again? and why exactly do I have 6 hostnames for that 1 static server?
200 resource fetches really isn't that many once you, and your framework authors, remove these and other HTTP/1 workarounds.
Kind of... HTTP/2's advantages depend on using push, and/or reducing prototcol negotiation latence and round-trip time... with HTTP/2, you don't have to negotiate a new/full TCP connection, which has overhead... also headers are compressed. The differences in compression and push become more pronounced with higher latencies and lower bandwidth.
At the very low bandwidth (2g/edge), the constraint goes the other way, where you don't gain much as the channel is pretty much flooded the entire time and the connection overhead offset is lower. ymmv.
All around, more traditional approaches can have a bigger impact... actually optimizing images, switching to svg where practical and reducing code, markup and stylesheets goes a long way. Reducing server response times is also pretty crucial. If your DBMS is taking 200ms to respond to most requests, your application is already going to be at least that slow... got multiple requests, worse still.
Effective caching strategies are how you overcome a lot of that. There are many pieces, and it's a matter of checking what your bottlenecks actually are, and minimizing your content transferred first.
Yes; Ilya Grigorik, in one of his talks, said that one of LTE’s biggest benefits is the much-lower latency for initial connections. I don’t remember which presentation, though.
56 comments
[ 4.0 ms ] story [ 114 ms ] thread2. I see ~1.5MB on the linked page, more than half of which are images used in the article, which are of course not simple text.
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?
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.
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.
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.
>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.
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.
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.
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.
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.
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.
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.
We've already seen large scale MITM be used for political reasons: to DDOS github off the internet in retaliation hosting anti-censorship technologies.
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?
This is what you can do with a single fake tweet: http://business.time.com/2013/04/24/how-does-one-fake-tweet-...
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.
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.
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).
Actually, it is:
https://www.w3.org/TR/upgrade-insecure-requests/
Edit: oh and throw in a few videos, everything has a video or two nowadays.
If your page loads stuff from 25 different domains, HTTP/2 barely helps at all. Likewise if your page is loading MB-size image or script files. Likewise if your server takes 2+ seconds to render the darn HTML in the first place.
But HTTP/2 is awesome when all the resources come from the same domain, because it eliminates the bottleneck of separate TCP/TLS connections. This means you don't have to do stuff like bundling resources and sharding domains. And indeed you shouldn't do this stuff if you're using HTTP/2.
HTTP/2's biggest problem is that nobody is changing their site to take advantage of its benefits.
These changes will see widespread use once CDNs start to take advantage of it. If you are serving a big enough website to take advantage of HTTP/2, you are using edge servers.
[1] http://www.browserscope.org/?category=network&v=top
When you have a web site this is a totally different story : beside your content and statics, you'll have maps from a CDN, widgets from third parties, ads ... and so on. "changing their site to take advantage of its benefits" is just not realistic for normal website.
See the "Stop Concatenating Files" part of this article : https://blog.cloudflare.com/http-2-for-web-developers/
I think where this will really start to shine is when browsers get js module support internally... combined with http/2 and some smarter server-side rendering, that could be a really nice place to be.
e.g. Remind me why I should be concatenating all my JS/CSS files into one again? and why exactly do I have 6 hostnames for that 1 static server?
200 resource fetches really isn't that many once you, and your framework authors, remove these and other HTTP/1 workarounds.
At the very low bandwidth (2g/edge), the constraint goes the other way, where you don't gain much as the channel is pretty much flooded the entire time and the connection overhead offset is lower. ymmv.
All around, more traditional approaches can have a bigger impact... actually optimizing images, switching to svg where practical and reducing code, markup and stylesheets goes a long way. Reducing server response times is also pretty crucial. If your DBMS is taking 200ms to respond to most requests, your application is already going to be at least that slow... got multiple requests, worse still.
Effective caching strategies are how you overcome a lot of that. There are many pieces, and it's a matter of checking what your bottlenecks actually are, and minimizing your content transferred first.
But seriously, as much as I like HTTP/2, it's not fully replacing 1.1 ever.