[Lukasa]

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 a situation when they had administrator access to your machine anyway, and in that situation you're already screwed.

Would it kill HN to actually read one of these specs instead of just whining about it?

[rdlowrey]

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 TLS experts. They will click right through warnings without a second thought. No, this standard doesn't harm the very small minority of people capable of protecting themselves. It only takes advantage of everyone else. This is why, to me, dismissing this off-hand as no big deal is seriously negligent. Yes, I've read the draft. Yes I have the technical experience and qualifications to understand fully what it proposes. And yes, I believe this is an egregious thing to propose.

[tptacek]

The TrustedProxy standard specifically documents that it not be invoked for HTTPS URIs. TrustedProxy doesn't interact at all with TLS the way it's understood now.

[Lukasa]

That's a totally understandable fear. Personally, I trust the ability of user-agents to help users make informed decisions in this area, but I can understand why you don't. Nevertheless, even with this proposal HTTP/2.0 will be substantially more secure than HTTP/1.1 is, at least in the aggregate.

It's also worth noting that this is a proposal. You didn't actually make this mistake yourself but I do want to highlight it: the HTTP WG is not yet discussing this as anything more than a suggestion (see http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/... ). If you are worried about this sort of proposal becoming a draft, I highly recommend you join the working group and keep an eye on the proxy discussions.

[omh]

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.

[noselasd]

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

[Lukasa]

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

[noselasd]

Sure it is, the old way you either

* get an alert when going to e.g. www.google.com as the carrier tries to hijack the session with a fake certificate.

* the carrier have their own versions of libraries/browsers/etc. installed on the phone that disables certificate checks/alerts that would pop up when they hijack a session.

* the carrier have actually gotten hold of a certificate for www.google.com - which I'm sure is doable, but harder, and is thus able to perform a successful mitm attack.

With this approach, the carrier just needs to generate their own certificate, install it on the phone they sell, and can proxy any service they want without user alerts. A significant lower entry bar.

[omh]

The "old way" is actually to install a new CA on the device. Then the proxy can just dynamically create dummy certificates signed by that CA.

This is simple on the client and avoids any security warnings. It's supported in quite a few firewalls and even squid, so it would be very easy for a carrier to roll out tomorrow if they needed to.

[rockdoe]

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

[atmosx]

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.

[tptacek]

No, it can't. You're arguing very confidently about a proposal you haven't even read. What you've instead done is take the headlines about the proposal at face value, and then constructing an argument by reasoning about what global TLS MITM would mean for the Internet.

[atmosx]

Actually I did, here are the relevant parts[1]:

uers should be made aware that, different than end-to-end HTTPS, the achievable security level is now also dependent on the security features/capabilities of the proxy as to what cipher suites it supports, which root CA certificates it trusts, how it checks certificate revocation status, etc. Users should also be made aware that the proxy has visibility to the actual content they exchange with Web servers, including personal and sensitive information.

Now the question is, did you???

I've seen the link[2] you posted and I didn't find ANYWHERE the part where it specifically talks about HTTP and not HTTPS. There's even the above part explaining making things even more complicated...

[1] http://tools.ietf.org/html/draft-loreto-httpbis-trusted-prox...

[2] http://hillbrad.typepad.com/blog/2014/02/trusted-proxies-and...

[tptacek]

Since the entire point of Brad's post is the distinction between http/https as it applies to HTTP/2.0 and specifically TrustedProxy, I call "shenanigans" on the idea that you actually read either of these.

[atmosx]

I got what you mean the second time I went through both of the texts, my bad. I thought HTTP2.0 was about always-on TLS layer, which is false so. And to be fair, reading the draft is kinda hard to understand the exact meaning, especially since they added the 6th paragraph (posted above), which in this case doesn't really make sense. If the connection is non-encrypted anyway, why ask the user a permission to tunnel the connection through TLS?

ps. I really did read them both, I just tend to be a little strong-opinionated.