Live data from Hacker News

Explicit Trusted Proxy in HTTP/2.0

tools.ietf.org

41–48 of 48 posts

Re: Explicit Trusted Proxy in HTTP/2.0

#41
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?

A possible objection to the proposal is that those who opt not to use "trusted" proxies will be making themselves more visible, like users of Tor are more visible.

Re: Explicit Trusted Proxy in HTTP/2.0

#42

It is an improvement compared to HTTP/1.1, in that it allows for opportunistic encryption, and it is those connections that can be cached (or if you so prefer, snooped). This will still make it harder for NSA and similar agencies to do mass surveillance without traces. They would either have to insert their own certificate, or get the private key from the ISP. That is far more difficult to do in a covert manner. This…

NSA will have the ISP keys, that's a given.

For American ISPs yes. For ISPs in some allied countries, probably. For all ISPs in every country in the world? Unlikely. And furthermore, that would require a nationwide (or worldwide) scheme where NSA gathered or issued keypairs for every certificate at every ISP. That is much more expensive than just tapping the lines, which is some of the point here, and some data probably would even be off limits. It would also be hard to keep an operation like that hidden, as they could for many years with the current methods.

I have no illusion that NSA can be stopped if they target someone, but it should be possible to make it impractical to just tap plaintext from the internet backbone as they do today. If data generally is encrypted _unless_ they do MITM attack it will be too expensive to just collect everything.

This is of cause not enough in itself, but it is certainly a step in the right direction.

Re: Explicit Trusted Proxy in HTTP/2.0

#43
post #27
post #2

Some context: http://lauren.vortex.com/archive/001076.html "What they propose for the new HTTP/2.0 protocol is nothing short of officially sanctioned snooping."

The post you've linked to is technically inaccurate and highly misleading. Here's Brad Hill's rebuttal: http://hillbrad.typepad.com/blog/2014/02/trusted-proxies-and...

Thanks for the link, it does clarify matters.

Re: Explicit Trusted Proxy in HTTP/2.0

#44
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?

It should be discussed as long as its new or interesting to someone so people can form their own opinion of a potentially important security issue. Your statement is suspiciously close to trying force a consensus opinion that there is nothing to see here. While I give you the benefit of the doubt, this type of steering of online discussion that benefits those that would like to weaken internet security. It might help…

Given that I summarized the pretty-simple point from the previous conversation, if you really think that's wrong you should say why. The Internet has this core problem that people don't learn from discussions and then keep saying things that are clearly, obviously, and even trivially false, giving emotional weight to ideas that actively harm the understanding of others. I mean: look at yourself... in addition to not responding to the specific factual detail I laid out, you are refusing to even take thirty seconds to find the previous discussion yourself... this is work you should have done before ever coming here to post something on this subject... it is the basic, core due diligence that I would argue is not just a courtesy but a responsibility for those who join online discourse :/. This "you may have said something factual, but damn it I like being angry at people for no reason, so I'm going to ignore what you said and pull the 'you are trying to steer the conversation' card" is ridiculous... facts should steer conversations :(.

Re: Explicit Trusted Proxy in HTTP/2.0

#45
post #34
post #17

Earlier quoted context omitted.

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.

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.

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

Re: Explicit Trusted Proxy in HTTP/2.0

#46
post #45
post #34

Earlier quoted context omitted.

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.

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 co…

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.

Re: Explicit Trusted Proxy in HTTP/2.0

#47
post #40
post #38

Earlier quoted context omitted.

I have no gripe since I do no longer consider that better-than-nothing security to be bad. In return for using ssh over telnet, I get security against any passive attack and attacks past first login. Thus the functionality is on a technical basis superior to telnet (except if you use IPsec, then telnet is better than SSH). A personal question: when you install a new personal laptop or server, do you check the fingerp…

No, I copy over my SSH configuration so that I don't need to do that.

How can you securely copy over the configuration? This sound as a chicken and egg problem.

Re: Explicit Trusted Proxy in HTTP/2.0

#48
post #46
post #45

Earlier quoted context omitted.

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 co…

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.

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.

Post reply on HN