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?
Explicit Trusted Proxy in HTTP/2.0
41–48 of 48 posts
Re: Explicit Trusted Proxy in HTTP/2.0
#42It 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.
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
#43Some 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...
Re: Explicit Trusted Proxy in HTTP/2.0
#44Wasn'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…
Re: Explicit Trusted Proxy in HTTP/2.0
#45Earlier 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.
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
#46Earlier 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…
Re: Explicit Trusted Proxy in HTTP/2.0
#47Earlier 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.
Re: Explicit Trusted Proxy in HTTP/2.0
#48Earlier 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.
ps. I really did read them both, I just tend to be a little strong-opinionated.