Live data from Hacker News

Explicit Trusted Proxy in HTTP/2.0

tools.ietf.org

31–40 of 48 posts

Re: Explicit Trusted Proxy in HTTP/2.0

#31
post #26

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

You're referring, I think, to opportunistic encryption. As Brad Hill pointed out yesterday: the security situation with HTTP/2.0 opportunistic encryption is analogous to that of OS X with the SecureTransport TLS validation bug. In neither case is "encryption" any more than cosmetic.

Like running ssh without checking fingerprints is analogous to that of telnet.

I for one used to be thinking like that. I had my A4 paper with all my computers fingerprint in my pocket and painstakingly checked it every time I was at a new computer. In my university, studying in the computer security program, I think I was the single person checking fingerprints. Not even the system administrators did it.

I guess in practice, ssh today is nothing more than cosmetic compared to telnet.

Re: Explicit Trusted Proxy in HTTP/2.0

#32
post #31
post #26

Earlier quoted context omitted.

You're referring, I think, to opportunistic encryption. As Brad Hill pointed out yesterday: the security situation with HTTP/2.0 opportunistic encryption is analogous to that of OS X with the SecureTransport TLS validation bug. In neither case is "encryption" any more than cosmetic.

Like running ssh without checking fingerprints is analogous to that of telnet. I for one used to be thinking like that. I had my A4 paper with all my computers fingerprint in my pocket and painstakingly checked it every time I was at a new computer. In my university, studying in the computer security program, I think I was the single person checking fingerprints. Not even the system administrators did it. I guess in…

If you use SSH and ignore key fingerprint warnings then yes, your use of SSH is cosmetic. Competent operators freak out when they get an unexpected key warning.

I don't understand the comparison you're trying to make between SSH and a proposal to transparently MITM a protocol that is designed to be transparently MITM'd. Unless your gripe is that we shouldn't have protocols like that to begin with, in which case I agree, but you should direct your angst to the people who proposed HTTP/2.0 OE, not this proposal.

Re: Explicit Trusted Proxy in HTTP/2.0

#33
post #32
post #31

Earlier quoted context omitted.

Like running ssh without checking fingerprints is analogous to that of telnet. I for one used to be thinking like that. I had my A4 paper with all my computers fingerprint in my pocket and painstakingly checked it every time I was at a new computer. In my university, studying in the computer security program, I think I was the single person checking fingerprints. Not even the system administrators did it. I guess in…

If you use SSH and ignore key fingerprint warnings then yes, your use of SSH is cosmetic. Competent operators freak out when they get an unexpected key warning. I don't understand the comparison you're trying to make between SSH and a proposal to transparently MITM a protocol that is designed to be transparently MITM'd. Unless your gripe is that we shouldn't have protocols like that to begin with, in which case I agr…

[deleted]

Re: Explicit Trusted Proxy in HTTP/2.0

#34
post #17
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.

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.

Re: Explicit Trusted Proxy in HTTP/2.0

#35
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".

Judging from http://hillbrad.typepad.com/blog/2014/02/trusted-proxies-and... it looks like opportunistic encryption is not meant to convey security, but rather add obscurity to in-transit plain-text traffic from the perspective of any in-between listeners (and he has no qualms pointing the finger at governments there).

Sadly he now seems to have changed his mind about the validity of this approach, mostly because users and devs alike dislike complexity in their decision process as to what is secure and what is merely obscured.

Re: Explicit Trusted Proxy in HTTP/2.0

#36
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 alone makes HTTP/2.0 an improvement.

Re: Explicit Trusted Proxy in HTTP/2.0

#37
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 linking to the previous discussion as well.

Re: Explicit Trusted Proxy in HTTP/2.0

#38
post #32
post #31

Earlier quoted context omitted.

Like running ssh without checking fingerprints is analogous to that of telnet. I for one used to be thinking like that. I had my A4 paper with all my computers fingerprint in my pocket and painstakingly checked it every time I was at a new computer. In my university, studying in the computer security program, I think I was the single person checking fingerprints. Not even the system administrators did it. I guess in…

If you use SSH and ignore key fingerprint warnings then yes, your use of SSH is cosmetic. Competent operators freak out when they get an unexpected key warning. I don't understand the comparison you're trying to make between SSH and a proposal to transparently MITM a protocol that is designed to be transparently MITM'd. Unless your gripe is that we shouldn't have protocols like that to begin with, in which case I agr…

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 fingerprints of every ssh connection? Do you prune the CA list and remove any entry that you personally can't vouch the trustfulness of? This is after all what SSL require of each user, so it would be interesting to know if a founder of an software security company do this to his own personal equipment.

Re: Explicit Trusted Proxy in HTTP/2.0

#39

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.

Re: Explicit Trusted Proxy in HTTP/2.0

#40
post #38
post #32

Earlier quoted context omitted.

If you use SSH and ignore key fingerprint warnings then yes, your use of SSH is cosmetic. Competent operators freak out when they get an unexpected key warning. I don't understand the comparison you're trying to make between SSH and a proposal to transparently MITM a protocol that is designed to be transparently MITM'd. Unless your gripe is that we shouldn't have protocols like that to begin with, in which case I agr…

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.
Post reply on HN