TLS in HTTP/2
daniel.haxx.se
daniel.haxx.se
I'm hoping it will stay this way. Defaults are important, so it's the platforms' responsibility to support and enforce the "safer" options.
> The fact that it didn’t get in the spec as mandatory was because quite simply there was never a consensus that it was a good idea for the protocol. A large enough part of the working group’s participants spoke up against the notion of mandatory TLS for HTTP/2. TLS was not mandatory before so the starting point was without mandatory TLS and we didn’t manage to get to another stand-point.
Which is interesting, because I remember quite clearly the "Snowden discussion" at the IETF, and there were consensus for an "encrypt everything Internet".
> There is a claimed “need” to inspect or intercept HTTP traffic for various reasons. Prisons, schools, anti-virus, IPR-protection, local law requirements, whatever are mentioned.
Right. So IETF made it non-mandatory so law enforcement can get their "master keys" in a way. Also this "anti-virus" kind of protection, is basically what Superfish was. I'd rather that kind of behavior was stopped.
IETF would better start actually becoming useful and come up with ways to replace the CA system over the next few years, instead of taking protocols from others and ruining them as they standardize them. Otherwise we should rethink a new model for standardization if IETF is as useless/malicious as it is right now.
I think this is still the official IETF position. RFC 7258 "Pervasive Monitoring Is an Attack" is published as Best Current Practice and has not been retracted.
At the very last stage, the IETF appeared to be hijacked by very large telcos (e.g. ATT, Verizon, Ericsson, Comcast) to remove the mandatory requirement for TLS
As an outsider, this look likes a careful co-ordinated attack on the IETF standards process by a small number of "serial IETF professionals" who are paid by the big carriers to be inside the organisation and ensure that standards do the bidding of corporate masters. (some hyperbole there)
Waiting until the last phase restricted discussion, and used the existing momentum to complete HTTP2 standard while removing one of the fundamental reasons for HTTP2 to exist.
It is a very sad day that consumer rights have been compromised by big money. And as the Lenovo Superfish debacle showed, likely it will backfire in the long run.
Here is the consortium: http://www.atis.org/openweballiance/about.asp
Here is an summary I wrote about this topic: http://etherealmind.com/response-open-web-alliance-lobbies-i...
http://arstechnica.com/security/2014/01/nsa-employee-will-co...
> I'm hoping it will stay this way.
There's a good reason it will probably stay that way: middleboxes. I wouldn't be surprised if plaintext HTTP/2 is a can of compatibility worms due to broken or misbehaving transparent proxies.
HTTP/2 over TLS bypasses these middleboxes. And even in the case where the broken middleboxes MITM the connection, their TLS handshake won't offer HTTP/2, so it'll fallback to HTTP/1. In case newer middleboxes do offer HTTP/2, they will have been tested against MSIE's HTTP/2 implementation, reducing the chance of compatibility problems.
If you are not logged in or sending sensitive information you don't need TLS but could still benefit from HTTP/2.
No, just to domains.
Generally the devices just generate a self-signed certificate and you have to click through the warning.
I don't have any problems with the campaigns to make the public internet HTTPS-only. However, for software inside an intranet, or software that just wants to expose an interface on http://127.0.0.1:*someport* non-SSL is the better default.
If people want to protect their intranet that's great, but it means that they have to go through the work of buying a cert, since only they know the hostname it will be exposed as. That's a poor initial-install experience.
Nowadays, I'm a firm believer in "encrypt all the things", but that's because I'm a geek and can deal with the PITA. There needs to be either an encryption mechanism that's completely separate from authentication, or the use case of LAN encryption for regular people needs to be addressed in some other way.
On a manged corporate intranet, Active Directory can push out a new CA and your computer trust whatever certs the local IT department wants to cook up, but it breaks down with a BYOD office or SOHO lan.
I manage a few intranet websites, this encryption requirement basically kills any interest I had in experimenting with HTTP/2 which was already miniscule. I'm not seeing the use case for HTTP/2 unless you're already all-https or in the Top N websites and want to slim down bandwidth use.
[For the record, YouTube seems to use HTTPS by default for video content, so this is already the case for some large percentage of the types of large resources typically accessed from shared networks.]
Checksumming and cryptographic signing of responses as an alternative to full-blown encryption might be useful as well (since response signatures could still be cached).
Plus, running a squid proxy on 100 users isn't nearly as effective as it once was; pages contain far more dynamically generated content than they used to. Think about a Facebook News Feed or Twitter Stream.
I get that browsers demand tls as there's no sane ui/ux to show that the link is secure because of vpn etc to the user. Not so for other clients.
AFAIK, Google is the only network actively working on having HTTPS-supported ads. The value of the ads drops significantly as the auction pressure from all the HTTP ads is gone, meaning any sites that rely on ad revenue can not afford to use TLS.
But I would love to know where I'm wrong about this.
HTTP/1.0 is basically dead and has been for years, because it lacks Host: and so cannot be used for vhosts.
It's still possible to use a 1.0 client today if you don't want to handle other client-side requirements of 1.1 like chunked transfer-encoding. Likewise, embedded devices can speak 1.0 only without any problem.
The only big thing chunked-encoding gives you is the ability to do a keep-alive connection when the server doesn't know the Content-Length in advance. (Technically it also added "trailers" for sending headers after the reply body, but that's little-used)
There are probably a lot more active HTTP/1.0 clients than you think. Just slap a `Host: foo.com` and `Connection: close` header onto the request and your HTTP/1.0 client can talk to just about any HTTP/1.1 server.