Live data from Hacker News

TLS in HTTP/2

daniel.haxx.se

1–10 of 34 posts

Re: TLS in HTTP/2

#2
> Internet Explorer people have expressed that they intend to also support the new protocol without TLS, but when they shipped their first test version as part of the Windows 10 tech preview, that browser also only supported HTTP/2 over TLS. As of this writing, there has been no browser released to the public that speaks clear text HTTP/2. Most existing servers only speak HTTP/2 over TLS.

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.

Re: TLS in HTTP/2

#3

> Internet Explorer people have expressed that they intend to also support the new protocol without TLS, but when they shipped their first test version as part of the Windows 10 tech preview, that browser also only supported HTTP/2 over TLS. As of this writing, there has been no browser released to the public that speaks clear text HTTP/2. Most existing servers only speak HTTP/2 over TLS. I'm hoping it will stay this…

> Which is interesting, because I remember quite clearly the "Snowden discussion" at the IETF, and there were consensus for an "encrypt everything Internet".

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.

Re: TLS in HTTP/2

#4
post #3

> Internet Explorer people have expressed that they intend to also support the new protocol without TLS, but when they shipped their first test version as part of the Windows 10 tech preview, that browser also only supported HTTP/2 over TLS. As of this writing, there has been no browser released to the public that speaks clear text HTTP/2. Most existing servers only speak HTTP/2 over TLS. I'm hoping it will stay this…

> Which is interesting, because I remember quite clearly the "Snowden discussion" at the IETF, and there were consensus for an "encrypt everything Internet". 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.

Certain corporate companies formed a consortium to prevent encryption to ensure that monetisation of personal information would continue.

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...

Re: TLS in HTTP/2

#5
post #3

Earlier quoted context omitted.

> Which is interesting, because I remember quite clearly the "Snowden discussion" at the IETF, and there were consensus for an "encrypt everything Internet". 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.

Certain corporate companies formed a consortium to prevent encryption to ensure that monetisation of personal information would continue. 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…

Thankfully the browser and server vendors can do an end-run round this by simply not supporting http2 without encryption. Then no matter what the standard says ordinary users will be protected and it'll be one more reason for sites to move to https everywhere. The article discusses this in TLS mandatory in effect

Re: TLS in HTTP/2

#6
Even when only doing domain validations, CAs still usually ask for personal information. You would have to lie at least somewhat convincingly to obtain a certificate without providing personal details which feels fraudulent and could potentially put you at risk of having the certificate invalidated. I'm assuming let's encrypt will address this since it's going to be a fully automated(?) system.

Re: TLS in HTTP/2

#7
How could certificates ever work in embedded applications connected to consumer LANs that provide interfaces over HTTP? Aren't certificates tied to IP addresses, which wouldn't work with e.g. DHCP? Not to mention certificate expiration and updates…

Re: TLS in HTTP/2

#8
post #7

How could certificates ever work in embedded applications connected to consumer LANs that provide interfaces over HTTP? Aren't certificates tied to IP addresses, which wouldn't work with e.g. DHCP? Not to mention certificate expiration and updates…

Aren't certificates tied to IP addresses

No, just to domains.

Re: TLS in HTTP/2

#9
post #7

How could certificates ever work in embedded applications connected to consumer LANs that provide interfaces over HTTP? Aren't certificates tied to IP addresses, which wouldn't work with e.g. DHCP? Not to mention certificate expiration and updates…

Certificates are generally based on hostnames. You can put an IP as the common name but it's problematic (and you can't get one signed by most authorities for an IP address as far as I know).

Generally the devices just generate a self-signed certificate and you have to click through the warning.

Re: TLS in HTTP/2

#10

> Internet Explorer people have expressed that they intend to also support the new protocol without TLS, but when they shipped their first test version as part of the Windows 10 tech preview, that browser also only supported HTTP/2 over TLS. As of this writing, there has been no browser released to the public that speaks clear text HTTP/2. Most existing servers only speak HTTP/2 over TLS. I'm hoping it will stay this…

> > Internet Explorer people have expressed that they intend to also support the new protocol without TLS, but when they shipped their first test version as part of the Windows 10 tech preview, that browser also only supported HTTP/2 over TLS.

> 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.

Post reply on HN