Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Explicit Trusted Proxy in HTTP/2.0

tools.ietf.org

Post reply on HN
Print view View original

11–20 of 48 posts

Re: Explicit Trusted Proxy in HTTP/2.0

#11

Post by omh »

rdlowrey wrote: post #8
Lukasa wrote: post #5

As discussed yesterday, this is not a new MITM vulnerability. To make this work you need to establish a TLS connection to the proxy which is verified in the usual certificate authority way. Note that the standard says that user agents that discover they're talking to a trusted proxy should obtain user consent to talk to that proxy. Any situation in which someone can force your machine to trust one of these proxies is…

I don't really care to argue this point so I'll just explain why I find this extremely problematic. What percentage of browser users have any concept of how TLS works? This an exceedingly low number. You're essentially creating a dragnet to capture and decrypt the contents of transfers for a huge number of people who likely have no idea that they're volunteering their (sensitive) information. Browser users are not TL…

The same thing is possible today by getting users to install a new CA and maybe configuring a proxy for them. It doesn't seem like these proposals would make this significantly easier.

Re: Explicit Trusted Proxy in HTTP/2.0

#13

Post by noselasd »

Lukasa wrote: post #5

As discussed yesterday, this is not a new MITM vulnerability. To make this work you need to establish a TLS connection to the proxy which is verified in the usual certificate authority way. Note that the standard says that user agents that discover they're talking to a trusted proxy should obtain user consent to talk to that proxy. Any situation in which someone can force your machine to trust one of these proxies is…

This simply means that phone/tablet manufacturers together with carriers will pre-install and trust the proxy certificates of the carrier, without any end user consent.

This will easily allow the carriers to perform their duty of Lawful Interception

Re: Explicit Trusted Proxy in HTTP/2.0

#14

Post by Lukasa »

noselasd wrote: post #13
Lukasa wrote: post #5

As discussed yesterday, this is not a new MITM vulnerability. To make this work you need to establish a TLS connection to the proxy which is verified in the usual certificate authority way. Note that the standard says that user agents that discover they're talking to a trusted proxy should obtain user consent to talk to that proxy. Any situation in which someone can force your machine to trust one of these proxies is…

This simply means that phone/tablet manufacturers together with carriers will pre-install and trust the proxy certificates of the carrier, without any end user consent. This will easily allow the carriers to perform their duty of Lawful Interception

This is not a new security hole. Carriers can do this today and transparently MITM all current HTTPS traffic: no new risk is present.

Re: Explicit Trusted Proxy in HTTP/2.0

#15

Post by rockdoe »

Lukasa wrote: post #14
noselasd wrote: post #13

Earlier quoted context omitted.

This simply means that phone/tablet manufacturers together with carriers will pre-install and trust the proxy certificates of the carrier, without any end user consent. This will easily allow the carriers to perform their duty of Lawful Interception

This is not a new security hole. Carriers can do this today and transparently MITM all current HTTPS traffic: no new risk is present.

Only with SIM locked phones for specific providers, I presume. Otherwise cert pinning will alert pretty quickly.

Re: Explicit Trusted Proxy in HTTP/2.0

#16

Post by 1stop »

higherpurpose wrote: post #9
saurik wrote: post #4

Wasn't this already discussed on Hacker News, in quite some detail, yesterday? And wasn't the big revelation that this only applied to traffic that was not CA verified and thereby was inherently man-in-the-middle-attackable anyway (as the actually-secure https connections are marked in a way where this feature does not apply), making this a misunderstanding?

I thought the whole point of HTTP2.0 was to make traffic encrypted by default, and not let bit vulnerability holes in the protocol like this. Saying "it just makes it as before" doesn't make me feel better. Why are we moving to HTTP2.0 otherwise? For a 5 percent increase in speed? The big selling point of HTTP2.0 from my perspective was the "always-on encryption".

I think the problem is, always on encryption, is always off caching...

Re: Explicit Trusted Proxy in HTTP/2.0

#17

Post by atmosx »

Lukasa wrote: post #5

As discussed yesterday, this is not a new MITM vulnerability. To make this work you need to establish a TLS connection to the proxy which is verified in the usual certificate authority way. Note that the standard says that user agents that discover they're talking to a trusted proxy should obtain user consent to talk to that proxy. Any situation in which someone can force your machine to trust one of these proxies is…

The problem is that this feature can (and will be) used as a legal backdoor for ISPs to snoop traffic, simple as that.

Even they don't want to, they will probably have to after a subpoena. While if you don't implement this and other backdoors to the protocol, you won't be able to do it. At least not transparently.

Re: Explicit Trusted Proxy in HTTP/2.0

#18

Post by nknighthb »

1stop wrote: post #16
higherpurpose wrote: post #9

Earlier quoted context omitted.

I thought the whole point of HTTP2.0 was to make traffic encrypted by default, and not let bit vulnerability holes in the protocol like this. Saying "it just makes it as before" doesn't make me feel better. Why are we moving to HTTP2.0 otherwise? For a 5 percent increase in speed? The big selling point of HTTP2.0 from my perspective was the "always-on encryption".

I think the problem is, always on encryption, is always off caching...

I call that a feature. I'm way past sick of flakey transparent proxies with bad caching behavior.

Re: Explicit Trusted Proxy in HTTP/2.0

#19

Post by brokenparser »

1stop wrote: post #16
higherpurpose wrote: post #9

Earlier quoted context omitted.

I thought the whole point of HTTP2.0 was to make traffic encrypted by default, and not let bit vulnerability holes in the protocol like this. Saying "it just makes it as before" doesn't make me feel better. Why are we moving to HTTP2.0 otherwise? For a 5 percent increase in speed? The big selling point of HTTP2.0 from my perspective was the "always-on encryption".

I think the problem is, always on encryption, is always off caching...

That's not true, your browser still handles caching just fine. More bandwidth trumps caching anyway, and caching forward proxies will be a thing of the past.

Re: Explicit Trusted Proxy in HTTP/2.0

#20

Post by joliss »

Before people start associating this with actual HTTP/2.0, it is worth emphasizing that this is a separate document. None of this "trusted proxy" MITM nonsense is in the HTTP/2.0 draft: http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/?in...

Thankfully, it seems fairly unlikely that the trusted proxy thing is going to get anywhere: It serves the interests of Ericsson and AT&T, but not those of the HTTP/2.0 spec authors (who are from Google and Mozilla) or server and browser vendors that will have to implement HTTP/2.0.

Post reply on HN