8 ms·

Explicit Trusted Proxy in HTTP/2.0

109 points by rdlowrey 13y ago

tjaerv 13y ago
Some context: http://lauren.vortex.com/archive/001076.html http://lauren.vortex.com/archive/001076.html "What they propose for the new HTTP/2.0 protocol is nothing short of officially sanctioned snooping."
- tptacek 13y ago
  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-privacy-wolves.html http://hillbrad.typepad.com/blog/2014/02/trusted-proxies-and...
  - tjaerv 13y ago
    Thanks for the link, it does clarify matters.
rdlowrey 13y ago
Section 6 (Security Considerations) is truly shocking. And Section 7 (Privacy Considerations)? Whaddya know? It's empty!
saurik 13y ago
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?
- higherpurpose 13y ago
  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".
  - tptacek 13y ago
    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.
    - belorn 13y ago
      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.
      - tptacek 13y ago
        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.
        deleted 13y ago
        [deleted]
        belorn 13y ago
        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.
- tptacek 13y ago
  Yes.
- flipgimble 13y ago
  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.
  - saurik 13y ago
    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 :(.
- nitrogen 13y ago
  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.
Lukasa 13y ago
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 13y ago
  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.
  - Lukasa 13y ago
    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/0692.html 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.
crbaker 13y ago
I understand that HTTP/2.0 needs to address both scalability and security, but the proposed "trusted" proxies smells really bad. Knowing what we know today, in that the current level of security offered by HTTP/1.1 is barely adequate to protect web citizens from real and present threats, shouldn't we be radically rethinking HTTP security.
yeukhon 13y ago
This would be an awesome term project for students studying computer security to find problems in the draft, if there is any.
barrkel 13y ago
I particularly like how the Privacy section is completely blank.
- deleted 13y ago
  [deleted]
joliss 13y ago
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/?include_text=1 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.
dschiptsov 13y ago
In some third-world countries you cannot get a telecom licence unless you "implement" this, or your license could be easily revoked or canceled. In Russia, for example, there are explicit regulations which says that no telecom company can operate unless it provides "monitoring and law-enforcement facilities". My guess is that each country nowadays has regulations of this sort, so telecom equipment manufactures are forced to "add required functionality". Of course, US has such "secret" regulations.) So, it is much better to face the reality and to standardize this shit to reduce the pain of telecom "workers".)
alephnil 13y ago
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.
- lallysingh 13y ago
  NSA will have the ISP keys, that's a given.
  - alephnil 13y ago
    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.

109 points by rdlowrey 13y ago

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

tptacek 13y ago
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-privacy-wolves.html http://hillbrad.typepad.com/blog/2014/02/trusted-proxies-and...
- tjaerv 13y ago
  Thanks for the link, it does clarify matters.

rdlowrey 13y ago

Section 6 (Security Considerations) is truly shocking. And Section 7 (Privacy Considerations)? Whaddya know? It's empty!

saurik 13y ago

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?

higherpurpose 13y ago
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".
- tptacek 13y ago
  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.
  - belorn 13y ago
    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.
    - tptacek 13y ago
      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.
      - deleted 13y ago
        [deleted]
      - belorn 13y ago
        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.
tptacek 13y ago
Yes.
flipgimble 13y ago
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.
- saurik 13y ago
  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 :(.
nitrogen 13y ago
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.

Lukasa 13y ago

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 13y ago
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.
- Lukasa 13y ago
  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/0692.html 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.

crbaker 13y ago

I understand that HTTP/2.0 needs to address both scalability and security, but the proposed "trusted" proxies smells really bad. Knowing what we know today, in that the current level of security offered by HTTP/1.1 is barely adequate to protect web citizens from real and present threats, shouldn't we be radically rethinking HTTP security.

yeukhon 13y ago

This would be an awesome term project for students studying computer security to find problems in the draft, if there is any.

barrkel 13y ago

I particularly like how the Privacy section is completely blank.

deleted 13y ago
[deleted]

joliss 13y ago

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/?include_text=1 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.

dschiptsov 13y ago

In some third-world countries you cannot get a telecom licence unless you "implement" this, or your license could be easily revoked or canceled. In Russia, for example, there are explicit regulations which says that no telecom company can operate unless it provides "monitoring and law-enforcement facilities". My guess is that each country nowadays has regulations of this sort, so telecom equipment manufactures are forced to "add required functionality". Of course, US has such "secret" regulations.) So, it is much better to face the reality and to standardize this shit to reduce the pain of telecom "workers".)

alephnil 13y ago

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.

lallysingh 13y ago
NSA will have the ISP keys, that's a given.
- alephnil 13y ago
  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.