6 ms·
One of the Most Alarming Internet Proposals I've Seen
- vezzy-fnord 13y agoIt actually appears that the RFC openly admits the potentials for abuse here: "6. Security Considerations This document addresses proxies that act as intermediary for HTTP2 traffic and therefore the security and privacy implications of having those proxies in the path need to be considered. MITM [4], [I-D.nottingham-http-proxy-problem] and [I-D.vidya-httpbis-explicit-proxy-ps] discuss various security and privacy issues associated with the use of proxies. 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."
- MaulingMonkey 13y agoTo play devil's advocate, this could potentially be less harmful than the existing situation: where e.g. various corporate nets will require you to install root certs to accomplish the same MITM attack, in a less visible fashion (after installation), with some if not all of the same caveats - especially if given the ability to opt out. (Bugs, insufficiently scary UI, and "discovery" are all massive concerns of course...)
- atmosx 13y agoHm, no. Various corporate networks doesn't classify as an ISP, the number of potentially abused users is not the same. A company can do whatever it wants to, an ISP offers a service and should respect the privacy of it's costumers, at least theoretically.
- wmf 13y agoThis proposal isn't intended for ISPs and should never be used on the public Internet.
- atmosx 13y agoOh, my bad then. I miss-understood the proposal and it's implications. But since the protocol supports that, how can we be sure that ISPs won't use it?
- MaulingMonkey 13y agoCynically, "we can't". Or "they already have better options". Alternatively, outcry and blacklisting ISP proxies - just as we do with root cert abuse.
- quotemstr 13y ago> various corporate nets will require you to install root certs to accomplish the same MITM attack They don't even bother making you install CA certificates. They just abuse subordinate CAs: see https://blog.mozilla.org/security/2013/02/15/announcing-version-2-1-of-mozilla-ca-certificate-policy/ https://blog.mozilla.org/security/2013/02/15/announcing-vers... I'm also a huge fan of Google's http://www.certificate-transparency.org/ http://www.certificate-transparency.org/, which makes it very difficult to fool very many people for very long.
- rubbingalcohol 13y agoOpenly admitting the potential for abuse doesn't make this any less ridiculous of a proposal.
- vezzy-fnord 13y agoI'm not saying it does.
- sekasi 13y agoAnother stab at using 'Trusted proxies' huh? I thought we had learnt that lesson a while ago.. Can we move on please, internet?
- deleted 13y ago[deleted]
- samplonius 13y agoThe fact is "trusted proxies" are a real thing right now. Plenty of private networks require that you trust one or more private CA roots and all SSL are intercepted and filtered. It is sort of a pain to do. You have to use something like Microsoft System Center to push the root onto all managed computers. This IETF proposal just formalizes it.
- deleted 13y ago[deleted]
- jstsch 13y agoCrazy. If you want to use caching, just use HTTP for that content.
- stephenbez 13y agoIt's not that simple. If you are going to use HTTPS, you need to use it for all content on that domain. Otherwise if you load for example a large javascript file over HTTP, the attacker can just poison that file and control your whole page. Even if you loaded an image from the same domain, your credentials would sent sent as a cookie in plain text. You could use a separate domain for content as explained here: http://stackoverflow.com/a/5160657/804713 http://stackoverflow.com/a/5160657/804713
- gojomo 13y agoThe web is long overdue for a method to specify an exact resource, by content-hash, from one-of-whatever-sources. Those sources can then be other less-secure protocols, even those unanticipated by the referrer, because the client got the necessary verifier via the secure-path.
- StavrosK 13y agoThat's actually a very good idea... Browsers could load the jquery file in your cache by its hash, rather than its URL. No more having 100 copies of jquery.min.js in your cache just because they're from different URLs.
- mnot 13y agoPrecisely this is actively being discussed in the W3C WebAppSec WG: http://w3c.github.io/webappsec/specs/subresourceintegrity/ http://w3c.github.io/webappsec/specs/subresourceintegrity/ The security folks I talk to are... nervous... about this use of subresource integrity, however.
- gojomo 13y ago
- gnoway 13y agoThere was another article on here a week or two ago effectively blasting the http/2.0 wg for doing stupid things. I think it was the "HTTP 308 incompetence expected" article. Now this. I'm beginning to wonder if I want anything to do with HTTP/2.0.
- hobohacker 13y agoPerhaps you should look at the Hacker News comments on that thread: https://news.ycombinator.com/item?id=7249193 https://news.ycombinator.com/item?id=7249193. Notably, my comments: https://news.ycombinator.com/item?id=7249560 https://news.ycombinator.com/item?id=7249560 and https://news.ycombinator.com/item?id=7249869 https://news.ycombinator.com/item?id=7249869. Basically, the author is wrong.
- Lukasa 13y agoBoth this article and that one were impressively alarmist. Speaking as someone who has implemented a HTTP/2.0 client stack it's really nothing like as bad as either of these articles makes out. For once, I invite you to fully read the comments on this post and the one you're referring to. Or, alternatively, take a read of the draft RFCs and the WG mailing list, which is totally open.
- wfunction 13y agoIs someone from the NSA behind this? Sorry, let me rephrase that. Who from the NSA is behind this?
- saraid216 13y agoAll of them, of course. Believing any less is unpatriotic.
- yk 13y agoApparently the NSA is a intelligence agency. [1] So they are probably not that blunt. [1] https://en.wikipedia.org/wiki/Nsa https://en.wikipedia.org/wiki/Nsa
- sroerick 13y agohttps://www.ietf.org/mail-archive/web/cfrg/current/msg03554.html https://www.ietf.org/mail-archive/web/cfrg/current/msg03554....
- platypii 13y agoThe best part: the "Privacy" section of the document is blank. http://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01#section-7 http://tools.ietf.org/html/draft-loreto-httpbis-trusted-prox...
- atmosx 13y agoThis proposal is so stupid it's hard to believe someone actually made it. Really beats the purpose: Why use SSL? Who am I protecting my data from if the ISP is snooping??? The kid on the Internet Cafe who just found about SSLSnoop? At this point the right proposal should be to just remove SSL altogether, no need to make circles over it.
- quotemstr 13y agoEr, actually reading the specification, it's about proxying http resources, not https ones. This proposal is strictly better than the transparent proxying that's common on the internet today. To distinguish between an HTTP2 connection meant to transport "https" URIs resources and an HTTP2 connection meant to transport "http" URIs resource, the draft proposes to register a new value in the Application Layer Protocol negotiation (ALPN) Protocol IDs registry specific to signal the usage of HTTP2 to transport "http" URIs resources: h2clr. ... 4.3. Secure Forward Proxy and https URIs The Proxy intercepts the TLS ClientHello analyses the application layer protocol negotiation extension field and if it contains "h2" value it does not do anything and let the TLS handshake continue and the TLS session be established between the User-Agent and the Server (see Figure 8).
- vezzy-fnord 13y agoRead the rest. You'll see that these proxies also serve as handlers for all TLS sessions.
- quotemstr 13y agoWhere does it say that?
- vezzy-fnord 13y ago3.1.1 TLS Handshake with Proxy certificate When the user has given consent to the use of a proxy, the User-Agent SHOULD store this consent so that the user does not have to give consent for each new TLS connection involving the proxy. The consent SHOULD be limited to the specific access and MAY be limited to a single connection to that access or limited in time. How the consent information is stored is implementation specific, but as a network may have several proxies (for network resilience) it is RECOMMENDED that the consent is only tied to the Subject field of the proxy certificate so that the consent applies to all proxy certificates with the same name. If the user has previously given consent to use the specific proxy and the user-agent has stored that, the user-agent may conclude that the user has given consent without asking the user again. If the user provides consent, the User-Agent continues the TLS handshake with the proxy. ----------- Right in the next section, it's again implied: The proxy will then notice that the TLS connection is to be used for a https resource or for a http resource for which the user wants to opt out from the proxy. The proxy will then forward the ClientHello message to the Server and the TLS connection will be end-to-end between the user-agent and the Server. ----------- Then in 3.2, again implied: When the User-Agent arrives to the portal page it becomes aware of the existence of a Proxy in the access network and receives a consent request for the proxy to stay in the path for HTTP URI resources. The user-agent then SHOULD secure user consent. When the user has given consent to the use of a proxy, both the User-Agent and the Proxy SHOULD store this consent so that the user does not have to give consent for each new TLS connection involving the proxy.
- bachback 13y agoSSL is such crap. time to make a better internet.
- nathancahill 13y agoWith blackjack and hookers?
- dijit 13y agohe's not wrong about SSL being poor.. rather, the CA system is what I consider to be poor. there was the idea of notaries that never took off, but that would be ideal imho.
- bachback 13y agoyes notaries + alternative DNS. problem is really the root (literally). its the same thing: somebody running a server and making decisions based on profit/power what goes into that server. I mean you choose whether you go to GoDaddy or Comodo, but that's about it. with .com you don't even have a choice but verisign. DNSsec add insult to injury, by making domain regs the CA's. and this 'proposal' is really the height of absurdity. AT&T shouldn't be writing the trust protocols.
- wmf 13y agoThis article ignores the context behind the proposal. Many companies, schools, and prisons are MITMing all SSL traffic today for a variety of liability reasons. Today those users get no notice that their Web browsing is being observed and censored. Trusted proxies are intended to give those users some notice that they're being MITMed. I agree that MITM proxies shouldn't be used on the public Internet and thus we shouldn't make it easier to do so, but what about the people who are already being MITMed? Is there another way to solve this problem or must we throw corporate Web users under the bus to save the public?
- hobohacker 13y agoAs Patrick McManus says in http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0703.html http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/...: If someone can install a root cert onto your computer then you are already owned - there is no end to the other things they can do too. Call it a virus, call it an enterprise, but call it a day - you're owned and there is no in-charter policy this working group can enact to change the security level of that user for good or for bad.. The good news is not everyone is already owned and SSL helps those people today.
- deleted 13y ago[deleted]
- rdl 13y agoThere are some kinda legitimate uses for this in certain environments -- enterprise DLP, various kinds of filtering, etc. Potentially even caching and stuff on the distant end of really weird network connections (when I go to Mars in ~30y, I'd like to have as much cached as possible, and converted to message-based vs. connection-oriented protocols). We have good enough workarounds for this right now (putting wildcard CA certs on devices and proxying that way), but they're not awesome. So, if there were a way to keep this from being used for evil, it could make some existing non-evil activities easier. But, on balance, the risk of evil might be too high.
- JoshTriplett 13y agoThere are potentially legitimate (though still sketchy) reasons to MITM HTTPS traffic from a host configured to allow that (for instance, by trusting an organizational CA). There are no legitimate reasons to MITM HTTPS traffic without the host's knowledge.
- lifeisstillgood 13y agoOk - here is a suggestion: The Right to root. Just as a citizens letters, papers and home are inviolable, should our new papers our new homes be also inviolable - if I own a device, No-one should legally be allowed control over it?
- wmf 13y agoThis proposal is mostly intended for environments where the users do not own the equipment, like offices and schools. But yeah, if you paid for it but can't root it, you got ripped off.
- MichaelGG 13y agoYou'd need to follow it up with a "Right to Own" whereby you can't lease or rent devices to people.
- TophWells 13y ago>if I own a device, No-one should legally be allowed control over it? Then tech companies might start leasing out their devices: you technically don't own it, so you're not allowed to do what you want to it. Not that the Right to Root wouldn't be nice, but the change in attitude has to come first. And we need to somehow convince the likes of Apple that their DRM is bad for business.
- lifeisstillgood 13y agoif someone leases me a notebook, do they get the right to read what I write in it? seems unlikely.
- friendzis 13y agoWasn't that written from a mac/ipad?
- lifeisstillgood 13y agoerrrr... yes. My iphone actually. (How could you tell? Or was that a lucky piece of sarcasm) If the signatories to the US constitution owned slaves, I can use an iPhone while still wanting the Right to Root.
- higherpurpose 13y agoI've become increasingly more disgusted with IETF since I found out they have at least a few NSA agents working with them on protocols, and more importantly refusing to kick them out - even after all the Snowden revelations with NSA trying to subvert and undermine encryption protocols: http://mirrors.dotsrc.org/fosdem/2014/Janson/Sunday/NSA_operation_ORCHESTRA_Annual_Status_Report.webm http://mirrors.dotsrc.org/fosdem/2014/Janson/Sunday/NSA_oper... Then I find out that they've been working with Cisco on another similar thing to this one for "legal intercepts", a.k.a "trusted backdoors", like we're seeing above. https://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/BlackHat-DC-2010-Cross-Attacking-LawfulI-Intercept-wp.pdf https://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/Bl... With NIST being already corrupted by the NSA, and now W3C becoming corrupted by MPAA, too, I think we're seeing the decay and fall of the "standard bodies", because I don't believe the Internet will tolerate these moves. The Internet will ignore them, do its own thing, and make it popular. I think future standards will be built from the bottom-up, and if I'm not mistaken most of the Internet so far has been built that way anyway.
- wmf 13y agoIf you consider a standards body corrupt because they have a single member you disagree with, you might be failing at politics.
- 666c6f 13y agoIt's not like they are just some "ordinary" bad guys, like A&T, who just want to make some bucks. The NSA is one of the most dangerous enemys to free speech and the freedom of the Internet. There is a high chance that they are going to undermine all our efforts to make a free and secure internet.
- hobohacker 13y agoThe specification indeed is about proxying http resources, not https ones. So it's not initially as alarming as some other proposals discussing trusting proxies to intercept SSL connections. For more details, you can refer to https://insouciant.org/tech/http-slash-2-considerations-and-tradeoffs/#Proxies https://insouciant.org/tech/http-slash-2-considerations-and-.... This specific proposal is interesting because it specifically is related to opportunistic encryption proposals, in particular, the one that allows sending http:// http:// URIs over an unauthenticated TLS connection: http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-03#section-3.6 http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-.... The problem here for proxies is, if you mix http and https (authenticated) traffic on the same TLS connection, the proxy cannot tell if it can safely MITM the connection. The proxy vendor would like to know if it can do so, probably for network management / caching / content modification reasons. Of course, the point of the opportunistic encryption proposal is to increase security (although its actual effective impact is controversial: https://insouciant.org/tech/http-slash-2-considerations-and-tradeoffs/#OpportunisticEncryption https://insouciant.org/tech/http-slash-2-considerations-and-...). But if you believe in opportunistic encryption's security purposes, then it doesn't seem to really make sense to make the MITM'able traffic identifiable so proxies on the network path can successfully MITM them without detection.
- userbinator 13y agoThe amusing thing about this is that MITM can also be used to one's personal benefit -- I run a local filtering proxy that strips off most of the crap on the majority of sites, and I've had to do a bit of hex editing to be able to do that without the browser complaining. Look at it another way: With browsers becoming more and more unconfigurable and nearing the point of being user-hostile, it is any wonder that the content providers would want their content, whether or not the user likes it, to be delivered unchanged and forced upon the user? All the Snowden stuff has made us feel that way, but what I'm saying is that the one who is doing the MITM isn't always malicious.
- SudoNick 13y agoYes! If you don't have a reasonably easy way to inspect and modify what is being sent over the encrypted connections your device makes, you are in very serious trouble. Your device will be [ab]used against you.
- news_to_me 13y agoThe most alarming thing about this article is the author's tone.
- droopybuns 13y agoCarriers are fighting against being turned into dumb pipes. Google is fighting to turn carriers into dumb pipes. I can't take this Google consultant seriously in that context.
- crististm 13y agoCarriers _are_ dumb pipes. Carriers are fighting to get rid of that. Internet _is_ dump pipes connected together. Carriers are fighting against that.
- glifchits 13y agoWhen I read the title I thought this was going to be from Upworthy.
- kercker 13y agoMaybe he who proposes this proposal is just meant to be funny.
- the_watcher 13y agoI'm not an expert in internet security or crypto. Some of the comments below raise some interesting points both defending the intent (and implementation) of it and pointing out the flaws. However, as an unsophisticated person interested in my data security, this sounds absolutely awful. Hopefully more clarity on this emerges.