The best part: the "Privacy" section of the document is blank.
http://tools.ietf.org/html/draft-loreto-httpbis-trusted-prox...
One of the Most Alarming Internet Proposals I've Seen
11–20 of 95 posts
Re: One of the Most Alarming Internet Proposals I've Seen
#12This 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.
Re: One of the Most Alarming Internet Proposals I've Seen
#13Crazy. If you want to use caching, just use HTTP for that content.
It'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:/…
The 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.
Re: One of the Most Alarming Internet Proposals I've Seen
#14Er, 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).Re: One of the Most Alarming Internet Proposals I've Seen
#15Another stab at using 'Trusted proxies' huh? I thought we had learnt that lesson a while ago.. Can we move on please, internet?
[deleted]
Re: One of the Most Alarming Internet Proposals I've Seen
#16It 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 iss…
To 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…
Hm, 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.
Re: One of the Most Alarming Internet Proposals I've Seen
#17SSL is such crap. time to make a better internet.
Re: One of the Most Alarming Internet Proposals I've Seen
#18Er, 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 n…
Read the rest. You'll see that these proxies also serve as handlers for all TLS sessions.
Re: One of the Most Alarming Internet Proposals I've Seen
#19Crazy. If you want to use caching, just use HTTP for that content.
If HTTP 2.0 requires TLS then to get speed and caching you'll need some kind of trusted proxy.
Re: One of the Most Alarming Internet Proposals I've Seen
#20It 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 iss…
To 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…
> 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-vers...
I'm also a huge fan of Google's http://www.certificate-transparency.org/, which makes it very difficult to fool very many people for very long.