[lacnog] Fwd: [ PFIR ] No, I Don't Trust You! -- One of the Most Alarming Internet Proposals I've Ever Seen
Carlos A. Afonso
ca en cafonso.ca
Vie Feb 28 06:16:20 BRT 2014
Compas, esto me pareció preocupante. ?Que opinan?
[]s fraternos
--c.a.
-------- Original Message --------
Subject: [ PFIR ] No, I Don't Trust You! -- One of the Most Alarming
Internet Proposals I've Ever Seen
Date: Sat, 22 Feb 2014 21:05:38 -0800
From: PFIR (People For Internet Responsibility) Announcement List
<pfir en pfir.org>
Reply-To: PFIR (People For Internet Responsibility) Announcement List
<pfir en pfir.org>
To: pfir-list en pfir.org
No, I Don't Trust You! -- One of the Most Alarming
Internet Proposals I've Ever Seen
http://lauren.vortex.com/archive/001076.html
If you care about Internet security, especially what we call
"end-to-end" security free from easy snooping by ISPs, carriers, or
other intermediaries, heads up! You'll want to pay attention to this.
You'd think that with so many concerns these days about whether the
likes of AT&T, Verizon, and other telecom companies can be trusted not
to turn our data over to third parties whom we haven't authorized,
that a plan to formalize a mechanism for ISP and other
"man-in-the-middle" snooping would be laughed off the Net.
But apparently the authors of IETF (Internet Engineering Task Force)
Internet-Draft "Explicit Trusted Proxy in HTTP/2.0" (14 Feb 2014)
haven't gotten the message ( http://j.mp/1fkCtnb [IETF] ).
What they propose for the new HTTP/2.0 protocol is nothing short of
officially sanctioned snooping.
Of course, they don't phrase it exactly that way.
You see, one of the "problems" with SSL/TLS connections
(e.g. https:) -- from the standpoint of the dominant carriers anyway --
is that the connections are, well, fairly secure from snooping in transit
(assuming your implementation is correct ... right?)
But some carriers would really like to be able to see that data in the
clear -- unencrypted. This would allow them to do fancy caching
(essentially, saving copies of data at intermediate points) and
introduce other "efficiencies" that they can't do when your data is
encrypted from your client to the desired servers (or from servers to
client).
When data is unencrypted, "proxy servers" are a routine mechanism for
caching and passing on such data. But conventional proxy servers won't
work with data that has been encrypted end-to-end, say with SSL.
So this dandy proposal offers a dandy solution: "Trusted proxies" --
or, to be more straightforward in the terminology, "man-in-the-middle
attack" proxies. Oh what fun.
The technical details get very complicated very quickly, but what it
all amounts to is simple enough. The proposal expects Internet users
to provide "informed consent" that they "trust" intermediate sites
(e.g. Verizon, AT&T, etc.) to decode their encrypted data, process it
in some manner for "presumably" innocent purposes, re-encrypt it, then
pass the re-encrypted data along to its original destination.
Chomping at the bit to sign up for this baby? No? Good for you!
Ironically, in the early days of cell phone data, when full capability
mobile browsers weren't yet available, it was common practice to
"proxy" so-called "secure" connections in this manner. A great deal of
effort went into closing this security hole by enabling true
end-to-end mobile crypto.
Now it appears to be full steam ahead back to even worse bad old days!
Of course, the authors of this proposal are not oblivious to the fact
that there might be a bit of resistance to this "Trust us" concept.
So, for example, the proposal includes the assumption of mechanisms
for users to opt-in or opt-out of these "trusted proxy" schemes.
But it's easy to be extremely dubious about what this would mean in
the real world. Can we really be assured that a carrier going through
all the trouble of setting up these proxies would always be willing to
serve users who refuse to agree to the proxies being used, and allow
those users to completely bypass the proxies? Count me as skeptical.
And the assumption that users can even be expected to make truly
informed decisions about this seems highly problematic from the
git-go. We might be forgiven for suspecting that the carriers are
banking on the vast majority of users simply accepting the
"Trust us -- we're your friendly man-in-the-middle" default, and not even
thinking about the reality that their data is being decrypted in
transit by third parties.
In fact, the fallacies deeply entrenched in this proposal are
encapsulated within a paragraph tucked in near the draft's end:
"Users 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."
Who are they kidding? It's been a long enough slog just to get to the
point where significant numbers of users check for basic SSL status
before conducting sensitive transactions. Now they're supposed to
become security/certificate experts as well?
Insanity.
I'm sorry gang, no matter how much lipstick you smear on this
particular pig -- it's still a pig.
The concept of "trusted proxies" as proposed is inherently
untrustworthy, especially in this post-Snowden era.
And that's a fact that you really can trust.
--Lauren--
I'm a consultant to Google. My postings are speaking only for myself,
not for them.
- - -
Lauren Weinstein (lauren en vortex.com): http://www.vortex.com/lauren
Co-Founder: People For Internet Responsibility:
http://www.pfir.org/pfir-info
Founder:
- Network Neutrality Squad: http://www.nnsquad.org
- PRIVACY Forum: http://www.vortex.com/privacy-info
Member: ACM Committee on Computers and Public Policy
Lauren's Blog: http://lauren.vortex.com
Google+: http://google.com/+LaurenWeinstein
Twitter: http://twitter.com/laurenweinstein
Tel: +1 (818) 225-2800 / Skype: vortex.com
_______________________________________________
pfir mailing list
http://lists.pfir.org/mailman/listinfo/pfir
Más información sobre la lista de distribución LACNOG