One of the Most Alarming Internet Proposals I've Seen • Hacker News Board

Re: One of the Most Alarming Internet Proposals I've Seen

#21

Post by wmf » Sun, Feb 23, 2014, 11:33 PM UTC

This 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?

Re: One of the Most Alarming Internet Proposals I've Seen

#22

Post by quotemstr » Sun, Feb 23, 2014, 11:33 PM UTC

vezzy-fnord wrote: post #18

quotemstr wrote: post #14

Er, 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.

Where does it say that?

Re: One of the Most Alarming Internet Proposals I've Seen

#23

Post by wmf » Sun, Feb 23, 2014, 11:34 PM UTC

atmosx wrote: post #16

MaulingMonkey wrote: post #4

Earlier quoted context omitted.

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.

This proposal isn't intended for ISPs and should never be used on the public Internet.

Re: One of the Most Alarming Internet Proposals I've Seen

#24

Post by StavrosK » Sun, Feb 23, 2014, 11:35 PM UTC

gojomo wrote: post #13

stephenbez wrote: post #9

Earlier quoted context omitted.

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.

That'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.

Re: One of the Most Alarming Internet Proposals I've Seen

#25

Post by saraid216 » Sun, Feb 23, 2014, 11:37 PM UTC

wfunction wrote: post #8

Is someone from the NSA behind this? Sorry, let me rephrase that. Who from the NSA is behind this?

All of them, of course. Believing any less is unpatriotic.

Re: One of the Most Alarming Internet Proposals I've Seen

#26

Post by zachrose » Sun, Feb 23, 2014, 11:38 PM UTC

gojomo wrote: post #13

stephenbez wrote: post #9

Earlier quoted context omitted.

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.

I believe there's already a standard HTTP header for this: Content-MD5.

Browsers definitely don't cache across origins by this though.

If they did, would it be possible to create a malicious JavaScript file with the same MD5 as jQuery?

Re: One of the Most Alarming Internet Proposals I've Seen

#27

Post by nathancahill » Sun, Feb 23, 2014, 11:43 PM UTC

bachback wrote: post #17

SSL is such crap. time to make a better internet.

With blackjack and hookers?

Re: One of the Most Alarming Internet Proposals I've Seen

#28

Post by atmosx » Sun, Feb 23, 2014, 11:44 PM UTC

wmf wrote: post #23

atmosx wrote: post #16

Earlier quoted context omitted.

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.

This proposal isn't intended for ISPs and should never be used on the public Internet.

Oh, 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?

Re: One of the Most Alarming Internet Proposals I've Seen

#29

Post by vezzy-fnord » Sun, Feb 23, 2014, 11:46 PM UTC

quotemstr wrote: post #22

vezzy-fnord wrote: post #18

Earlier quoted context omitted.

Read the rest. You'll see that these proxies also serve as handlers for all TLS sessions.

Where does it say that?

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

Re: One of the Most Alarming Internet Proposals I've Seen

#30

Post by bbatsell » Sun, Feb 23, 2014, 11:51 PM UTC

quotemstr wrote: post #14

Er, 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…

HTTP/2 changes the meaning of the http:// scheme. All connections will now be TLS-encrypted. (Edit: Maybe not. See hobohacker below.) http:// means that the endpoint has not been verified using the CA system and is using a self-signed certificate (and is thus trivially vulnerable to a MITM should certificate keys not be checked out-of-band).

The purpose is to provide confidentiality to the vast majority of traffic, even if the authentication part of the CIA triangle isn't achieved. This proposal's purpose is to undo that and expose all traffic using the http:// scheme to your ISP, exactly as it is today. (I would also note that this draft is proposed by AT&T, which is now rolling out new plans in Austin that charge an extra $30/month if you do NOT agree to them inspecting and data-mining all of your internet activity and selling it to advertisers.)