Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Most Alarming: IETF Draft Proposes "Trusted Proxy" In HTTP/2.0

timothy posted about 5 months ago | from the you-have-reached-the-internet-mailbox-of-al-gore dept.

The Internet 177

Lauren Weinstein writes "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. What they propose for the new HTTP/2.0 protocol is nothing short of officially sanctioned snooping."

cancel ×

177 comments

Sorry! There are no comments related to the filter you selected.

if you want a trusted proxy.. (0)

gl4ss (559668) | about 5 months ago | (#46315945)

..why the fuck not just connect to the proxy over an encrypted pipe?!?

Re:if you want a trusted proxy.. (4, Interesting)

gbjbaanb (229885) | about 5 months ago | (#46315989)

someone didn't RTFM!

and do what with the data then?

The main point of a proxy here is to allow things like caching, so you connect to the proxy using an encrypted pipe and as the proxy is trusted, you allow it to de-crypt your data, do whatever network efficiencies it wants to do and then re-encrypt your data to pass on to the destination.

I'm sure you can see why this might be a problem - your encrypted, secure data is automatically decrypted right at the point the NSA (or your ISP) wants it. Now if you trust your ISP or NSA to protect you and you don;t care if they are data mining your communications, then this is a great thing, let then do it as efficiently as possible.

if on the other hand, you think that the data you encrypt is done to stop others from performing man-in-the-middle attacks, then you'd not want this to be used.

Personally, I think its an ok thing as long as there's another mechanism for encrypting private data. I mean - you encrypt the boring stuff that you still don't want intercepted over a wifi link for example, but you still want your passwords to be properly encrypted and unreadable even by the trusted proxy. I would want the benefits of SSL on all my comms and have the benefits of proxy servers working with these, but still have my private data encrypted. I'm not sure how we could achieve this though, hopefully someone will enlighten me.

Re:if you want a trusted proxy.. (-1, Offtopic)

Anonymous Coward | about 5 months ago | (#46315993)

If I had a son who told me he was gay, I would nervously say "Th-that's okay, son," while choking back tears. Not tears of joy, but the tears of terrible disappointment. I would become sullen and withdrawn, sighing and staring out the window. My wife and I would run our son's life through our heads over and over and over again, wondering where we went wrong. Was my wife too overbearing? Was it that time he missed catching the football I threw him and got a bloody nose? Did the girls at school pick on him too much? Did he watch too much of Viacom's degenerate homosexual miscegnative swill on TV?

I would stand with him at little-league games staring at the ground out of shame and embarrassment that my son is a fairy playing on a team of young men. I wouldn't even bother teaching him about save sex, as he'll be dead in a few years anyway, with AIDS. Maybe I'd secretly change my last name and move to a different town, so none of the neighborhood chatter would associate me with the defective offspring sashaying around the Pride parade dressed like Rob Halford or Elton John, performing rhythmic gymnastics with his limp wrists.

What if that happened? Man, oh man, I don't know what I'd do. It's not like you can just toss kids out and go get another one.

Re:if you want a trusted proxy.. (-1, Troll)

binarylarry (1338699) | about 5 months ago | (#46315997)

I think that's what the IETF was trying to do.

Some journalist dickbag is trying to make it sound Orwellian but it's not at all. If you don't *TRUST* the proxy, don't accept it's use. So if it's from Evil Govt, Evil Inc, etc or anyone else you don't trust to snoop, don't use it.

Want a proxy you can trust? Set it up and maintain it yourself. Is that not good enough? Maybe the Internet isn't how you should send that data.

Re:if you want a trusted proxy.. (3, Insightful)

Anonymous Coward | about 5 months ago | (#46316023)

That works for you, me, and maybe a few other people.

For the billions of people online who don't/can't/won't think about what's actually going on, it doesn't work at all. In effect, all that matters is what Joe Sixpack does, and that's pretty clear. You can manipulate Joe into anything you want, by putting a shiny icon on it and telling him he can watch NFL Cheerleader Tryouts 15 in glorious High Definition.

Re:if you want a trusted proxy.. (0)

binarylarry (1338699) | about 5 months ago | (#46316213)

That's a pretty impressive way to soak up mod points by saying nothing pertinent at all.

Just throw in tons of "Joe Sixpack can't" and "poor oppressed people."

Re:if you want a trusted proxy.. (5, Informative)

the_B0fh (208483) | about 5 months ago | (#46316043)

You don't understand how things work, do you? This bypasses your "acceptance" requirement.

They can just do it transparently.

Re:if you want a trusted proxy.. (1)

binarylarry (1338699) | about 5 months ago | (#46316199)

ORLY?

From TFAbstract:
"This document describes two alternative methods for an user-agent to
      automatically discover and for an user to provide consent for a
      Trusted Proxy to be securely involved when he or she is requesting an
      HTTP URI resource over HTTP2 with TLS."

Re:if you want a trusted proxy.. (1)

the_B0fh (208483) | about 5 months ago | (#46317701)

Consent can be as simple as logging in to a web portal. Think about it a little more. It'll come to you.

Re:if you want a trusted proxy.. (0)

Anonymous Coward | about 5 months ago | (#46317861)

IN ORDER TO READ THIS COMMENT, YOU MUST READ THE FOLLOWING 3 WORDS: "YES I ACCEPT"

It will be yet another popup on your web browser, saying "security security security click here to access this website, if you don't click here you wont access this website"

Guess which button people will be hitting?

Protip: it isn't the one that denies them access to the website they were trying to go to.

Re:if you want a trusted proxy.. (5, Interesting)

haruchai (17472) | about 5 months ago | (#46316071)

Lauren Weinstein is no lightweight; there's a good reason he's a Google consultant and have 400,000 followers. It's not for his singing & dancing.

Re: if you want a trusted proxy.. (0)

Anonymous Coward | about 5 months ago | (#46316429)

Really? Because it seems he doesn't understand what is being proposed at all...

Re: if you want a trusted proxy.. (1)

mellon (7048) | about 5 months ago | (#46318053)

Did you read the draft? He's articulated quite accurately what's being proposed. Maybe that's not what the authors intend to be proposing, but that's what the document currently does in fact propose. (I say "authors" because the IETF has not adopted this work, so it's not accurate to say that the IETF is doing this work—the IETF is explicitly not doing this work at the moment.)

Re:if you want a trusted proxy.. (1)

DAldredge (2353) | about 5 months ago | (#46317655)

Ken Ham has lots of followers but that doesn't make most all of what he says true.

Re:if you want a trusted proxy.. (1)

Z00L00K (682162) | about 5 months ago | (#46316369)

And the scenario where an ISP sets up a "trusted proxy" and forces all traffic to go through it - even your bank traffic.

That proxy would be a goldmine for hackers and fraudsters.

Re:if you want a trusted proxy.. (2)

binarylarry (1338699) | about 5 months ago | (#46316395)

It's only trusted by you if you assert that it is. This proposal formalizes the act of notifying of an available proxy and allowing the user to trust (or not trust) said proxy.

Take it or leave it (3)

tepples (727027) | about 5 months ago | (#46317997)

Sure, you have a "choice" whether or not to trust a particular proxy, but in many cases it's a Hobson's choice [wikipedia.org] : "Trust us or we block all your packets." If all ISPs willing to offer service to you offer a choice between their proxy or no Internet access, are you willing to take no Internet access? Would enough other home users agree with you to make serving them profitable?

Re:if you want a trusted proxy.. (1)

tlambert (566799) | about 5 months ago | (#46318093)

It's only trusted by you if you assert that it is. This proposal formalizes the act of notifying of an available proxy and allowing the user to trust (or not trust) said proxy.

And if they simply redirect all port 443 traffic to their proxy by default so that they can cache content and optimize their network?

You can either trust their proxy, or you can fuck off and not use https.

Re:if you want a trusted proxy.. (1)

binarylarry (1338699) | about 5 months ago | (#46318589)

Sounds like a certain someone doesn't know how SSL/TLS works.

Re:if you want a trusted proxy.. (1)

sjames (1099) | about 5 months ago | (#46318249)

In the vast majority of cases, when you are using an encrypted connection it is because the information you are exchanging is a private matter between you and the other endpoint. Mostly it's uncachable anyway since only you will have the page info filled in exactly that way. Why cache my bank account summary, nobody else should ever be able to fetch that exact page but me anyway and I already have it.

So it's a 'feature' that is largely useless for it's claimed intent but tremendously useful for nefarious purposes.

Re:if you want a trusted proxy.. (2)

X10 (186866) | about 5 months ago | (#46316591)

If you don't *TRUST* the proxy, don't accept it's use.

That's true. But then, if you're a user who's not very security savvy (like 95% of the people on the internet) and you think "https is secure, my isp can't see my data", and you think "secure proxy, sounds good!", then you're stuffed. Either the rfp should require isps to notify their customers that "secure" in this case means "secure, but we can see it", or the rfp should describe a solution where the isp really can't see the users data.

Re:if you want a trusted proxy.. (1)

binarylarry (1338699) | about 5 months ago | (#46316905)

That's true. However, the browser is going to be the technology that ultimately allows the user to act. So as long as Google, Mozilla, etc make the security risks clear, everything should be okay.

The current set of browser security warnings are pretty effective (giant red screen with lots of scary text). If the end user still approves, it's their fault.

Re:if you want a trusted proxy.. (0)

Anonymous Coward | about 5 months ago | (#46317887)

There is no difference between this proxy; and an unsecure certificate.

NONE AT ALL

Unless it is a giant red screen saying: "HOLY SHIT THIS IS INSECURE DONT FUCKING DO THIS" it will be a failure. And; since we already have the giant red screen of BTW THIS AINT YOUR WEBSITE, then why are we standardising another way to do this?

Re:if you want a trusted proxy.. (1)

mellon (7048) | about 5 months ago | (#46318033)

What proxy would you trust with your banking details? Because this spec will let them see your private conversations with third parties including banks. Weinstein is correct to be worried about this proposal. However, this is not an IETF document. The IETF isn't trying to do anything here. This is a document some people have floated in the IETF. As written, I don't see it getting traction, because it's in violation of existing IETF policy [ietf.org] .

Re:if you want a trusted proxy.. (1)

the_B0fh (208483) | about 5 months ago | (#46316029)

Are you sure you understand what is being discussed?

Re:if you want a trusted proxy.. (-1)

Anonymous Coward | about 5 months ago | (#46316063)

Are you sure you're not a cum dumpster with Bruce Peren's ball juice on your lips?

Re:if you want a trusted proxy.. (1)

the_B0fh (208483) | about 5 months ago | (#46316181)

Yes, I'm sure I'm not. Just like I know you're an AC idiot wanking away in your mother's basement.

Re:if you want a trusted proxy.. (1)

mellon (7048) | about 5 months ago | (#46317989)

That's what the draft says. But it's NOT A BLOODY IETF STANDARD. It's an individual submission to the IETF. The IETF isn't working on this. Some IETF participants are. The IETF has a formal policy excluding work on lawful intercept technology or even allowing for it in our protocol specifications.

And in some cases, you get to do this. (-1)

queazocotal (915608) | about 5 months ago | (#46315957)

If I own the device, and the network, then this sort of action may in fact be legally required in some cases.
It's certainly often permitted - if the user is explicitly informed first, and they do not own in any manner the device.

(I am not referring to contract phones, but to employer provided devices)

Re:And in some cases, you get to do this. (1)

Zero__Kelvin (151819) | about 5 months ago | (#46316013)

I read the summary. I even read the article. It wasn't until I read what you wrote that I had a true WTF moment. Nothing you wrote makes any sense to me. Seriously. It is to the point where I would really like to know what the hell you were trying to say.

Re:And in some cases, you get to do this. (2, Informative)

the_B0fh (208483) | about 5 months ago | (#46316047)

You have no clue what you are talking about. The "legally required" shit is already being done. There's no need to do any IETF crap.

This is for ISPs to do it to you, without you being able to prevent it.

Re:And in some cases, you get to do this. (1)

mellon (7048) | about 5 months ago | (#46318075)

Actually if your TLS implementation is solid, there is no way for the ISP to do this to you. They don't have access to the keys. They can prevent you from using HTTPS, but if they do you will stop using them, because you won't be able to do online shopping or online banking, or even log in to Facebook.

Also, TLS and HTTP are "IETF crap." Whereas the document Weinstein is up in arms about is not—it's a document that's been proposed as work in the IETF by a couple of people, but it is not work the IETF has adopted.

Opt out (0)

Anonymous Coward | about 5 months ago | (#46315961)

At least it is possible to opt out.

Re:Opt out (1)

johanw (1001493) | about 5 months ago | (#46316607)

But possibly with the side effect of loosing your connection, or the ISP makinbg it slow for you like they do with Netflix.

heard of WCCP? (0)

Anonymous Coward | about 5 months ago | (#46315971)

Nothing new.

user transparency? (1)

Anonymous Coward | about 5 months ago | (#46315975)

The draft seems to read the opposite of what the summary is saying.

Re:user transparency? (1)

Zero__Kelvin (151819) | about 5 months ago | (#46316093)

It proposes an Un-trusted Proxy?

Re:user transparency? (0)

binarylarry (1338699) | about 5 months ago | (#46316405)

No, the summary is fucking retarded and sensationalist.

dark matters eating to live vs. living to eat,, (-1)

Anonymous Coward | about 5 months ago | (#46315999)

spiritual sandboxing in the peanut butter vortex; for 85 then; what does is it feel like to be starving to death,, physically &/or just spiritually (the inexorable intertwinance)? seems only some millions of innocent infants can answer this one completely without speculation... points for all takers...

omni-answer box remains empty (-1)

Anonymous Coward | about 5 months ago | (#46316115)

which coincidentally is the correct answer. extra gilt for all of us good sports with good spirits giving until it stops hurting.....

Cluelessness and hyperbole combined (-1, Flamebait)

Kjella (173770) | about 5 months ago | (#46316007)

Trying to drive traffic to her own blog, I guess. In short it's the same kind of snooping many corporate PCs do on your HTTPS traffic today, formalized into a protocol. Big whoop.

Re:Cluelessness and hyperbole combined (4, Funny)

Zero__Kelvin (151819) | about 5 months ago | (#46316017)

Also, she really needs a shave.

Re:Cluelessness and hyperbole combined (1)

Rick Zeman (15628) | about 5 months ago | (#46316187)

And she looks really butch on the motorcycle with the ape hangers.

Re:Cluelessness and hyperbole combined (0)

Anonymous Coward | about 5 months ago | (#46316237)

Maybe her father was listening to Johnny Cash [youtube.com] when she was named.

Well for one... (4, Insightful)

Junta (36770) | about 5 months ago | (#46316039)

Pretty much anyone can submit an IETF RFC if they really want. The existence of a draft does not guarantee a ratified version will exist someday.

For another, it could be much worse. There is explicit wording at least here about seeking consent from the user and allowing opt-out even in the 'captive' case, as well as notifying the actual webserver of this intermediary, and that the intermediary must use a particular keyusage field meaning that some trusted CA has explicitly approved it (of course, the CA model is pretty horribly ill-suited for internet scale security, but better than nothing). Remember how Nokia confessed they silently and without consent had their mobile browser hijack and proxy https traffic without explicitly telling the user or server? While something like this being formalized wouldn't prevent such a trick, it would be very hard to defend a secretive approach in the face of this sort of standard being in the wild.

Keep in mind that in a large number of cases in mobile, the carriers are handing people the device including the browser they'll be using. A carrier could do what Nokia admits to in many cases without the user being the wiser and claim the secretive aspect is just a side effect today. If there was a standard clearly laying out that a carrier or mobile manufacturer should behave a certain way, that defense would go away.

I would always elect the 'opt out' myself, but I'd prefer anything seeking to proxy secure traffic be steered toward doing things on the up and up rather than pretending no one will do it and leaving the door open for ambiguous intentions.

Please correct me if I'm wrong... (2)

cardpuncher (713057) | about 5 months ago | (#46316051)

But as I read it, the issue seems to arise from the fact that HTTP2 will permit TLS to be used with both http: and https: URLs. If it is used for http: URLs, then existing proxy and caching mechanisms will simply break. I think this is a proposal for "trused proxies" to be permitted where an http: URL is in use and TLS is also employed, I don't think it's proposed that this should apply to https: URLs.

In other words, it doesn't make things any worse than the current situation (where http: URLS are retrieved in plain text all the time) and does permit the user to control whether they want some protection against interception or potentially better performance. And it doesn't appear to change the situation for https: at all.

Or that's how it appears to me.

Re:Please correct me if I'm wrong... (0)

Anonymous Coward | about 5 months ago | (#46317917)

TLS SNI extensions already exist for secure connections, allowing for proxying of HTTPS traffic.

You don't get to see anything other than the hostname, and it sure as shit is useless for caching, but your proxy can proxy the (encrypted) data.

If you want caching, then you need to start distributing trusted certificate authorities, and providing secure certificates that fake out other websites as the traffic leaves your building. If you are BigCorp you have this sorted (you deploy and manage the hardware, you can install your CA there fine - you don't even get an error popup!). If you are anyone else you pretty much shouldn't be seeing secure traffic data ever, so... why would you want this?

The current solution (2, Informative)

Anonymous Coward | about 5 months ago | (#46316055)

If you want to do this now, you're typically in one of two situations:

You need to proxy the traffic for all users of a company, in order to filter NSFW content and to scan for viruses and other malware. In this case you add your own CA to all company computers. Then you MITM all SSL connections. This doesn't work for certain applications which use built-in lists of acceptable CAs, but mostly the users will be none the wiser.

The other situation is that you want a reverse proxy in front of your hosting infrastructure. In this case you just have the proxy operator install your certificate and make it look like the proxy is your actual server.

In both cases, the Trusted Proxy extension would make more transparent what's actually going on, instead of pretending that there is no proxy when in fact there is.

Re:The current solution (0)

Anonymous Coward | about 5 months ago | (#46318327)

As someone that has been implementing transparent SSL proxies for network security appliances used primarily at corporate perimeters, the current state of affairs has been pretty bad. Trusted Proxy mechanism would make it less kludgy, and hopefully in general, more mature.

Prevention of standardization now that HTTP/2.0 with more widespread encryption is shaping up is not a solution that would be particularly beneficial to anyone. Quite the opposite, in my opinion. I don't like the idea that deep packet inspection systems run by owner of the network and with consent of its' users need to be some sort of giant hacks.

Hidden problems with proxies (4, Informative)

MobyDisk (75490) | about 5 months ago | (#46316069)

My employer uses a MITM HTTPS proxy. The IT department pushed down a trusted corporate certificate, and most people don't even know their HTTPS connections aren't secure any more. The real problem is when some application, other than a browser, needs internet access and it fails. This includ sethings like web installers that download the app during installation, automatic update systems, secure file transfer software, or things that call home to confirm a license key. On occassion a developer curses some installer for not working, then we inspect the install.log file and find something about a certificate failure.

IT departments forget that HTTPS is used for more than just browsing the web.

Re:Hidden problems with proxies (2)

timeOday (582209) | about 5 months ago | (#46316173)

Same at my company, but I take issue with "people don't even know their HTTPS connections aren't secure any more". Corporate machines are "rooted" in the first place, they generally install whatever new software the employer wants during each reboot or login. Probably half the cycles on my work computer are wasted on Symantec spyware. So, you can't lose the privacy you never had.

Re:Hidden problems with proxies (1)

smash (1351) | about 5 months ago | (#46316195)

IT departments forget that HTTPS is used for more than just browsing the web.

No, not necessarily. Some IT departments are just more paranoid than others about letting un-filtered https go through the firewall, due to the new generation of malware which is typically doing C&C over HTTPs to thousands of randomly generated and not blacklisted URLs.

You have a choice - you MITM/inspect HTTPs, you allow only whitelisted HTTPs connections (which is not really practical due to the ever changing whitelist), or you allow any and all malware C&C straight through the corporate firewall. Option 3 is not really acceptable.

Re:Hidden problems with proxies (0)

Anonymous Coward | about 5 months ago | (#46316759)

or you allow any and all malware C&C straight through the corporate firewall. Option 3 is not really acceptable.

Depends on how paranoid you are; if you control what is installed and have the machines locked down against foreign (employee) installations. How can something call home if it doesn't exist on your systems?

Re:Hidden problems with proxies (0)

Anonymous Coward | about 5 months ago | (#46317959)

By assuming you have it locked down against all possible installations of malware or otherwise - you have already lost the battle.

Assume the machines that are in your control but not your direct line of site (and even then!) will be compromised. Plan to mitigate the effects of the compromised machine from the start (not after they have stolen thousands of credit card numbers from your POS machines).

Re:Hidden problems with proxies (0)

Anonymous Coward | about 5 months ago | (#46318309)

By assuming you have it locked down against all possible installations of malware or otherwise - you have already lost the battle.

A battle with whom? The NSA ?

AC, I see that you're paranoid, you may want to tighten that tinfoil hat a bit.

Re:Hidden problems with proxies (1)

silas_moeckel (234313) | about 5 months ago | (#46316241)

Those applications are broken. If they fail to respect the OS proxy and CA settings they are the ones at fault.

In a corp environment nothing should be calling home ever, that is what they made licences servers for.
Updates should be gotten from an update server, ya know something that IT approves.
Installers calling home again should never happen.
Post SOX/HIPPA there is no secure file transfer your IT dept has a legal requirement to look and record things coming in and out the door.

Re:Hidden problems with proxies (1)

drolli (522659) | about 5 months ago | (#46316751)

That depends on what the purpose of this application is. There are purposes for which you may prefer an application failing instead of accepting another certificate. If the application promised end-to-end safety, with a very specific *certified* configuration ending on the target (i imagine Software updates for the development of embedded systems in cars), then failure by default is the right behaviour until sombody signs of a sheet of paper that he/she/the company takes responsibility to the end customer (e.g. the development department) for anything transmitted in the wrong way.

Re:Hidden problems with proxies (1)

silas_moeckel (234313) | about 5 months ago | (#46316895)

Anything like that is not running on a GP computer, as the hardware is very much part of the solution. Nor should it be connected to the general corp lan, an environmental system would be a good example it goes in a DMZ gets holes punched through to exactly what it needs and can not access anything else.

Re:Hidden problems with proxies (1)

drolli (522659) | about 5 months ago | (#46316913)

The development systems for embedded software *are* running on GP computers. Simulink embedded coder etc require windows PCs. And yes, these developers dont transfer everything by floppy/sneakernet.

Re:Hidden problems with proxies (0)

Anonymous Coward | about 5 months ago | (#46318095)

Absolutely false.

The CA system is deeply flawed. There is no way to create a list of "trusted entities" where each and every one of those entities is allowed to issue a certificate for any secure communication.

No secure communications can use CA settings. The applications ARE NOT BROKEN.

Re:Hidden problems with proxies (0)

Anonymous Coward | about 5 months ago | (#46316471)

IT departments forget that HTTPS is used for more than just browsing the web.

They don't forget (at least the decent ones don't). They simply see browsing as covering (say) 95% of the situations and optimize for it.

And any other "non-standard" situations they want to know about to reduce the chances things getting in and things getting out.

Dual-horizon DNS and blackhole (internal) routing is pretty good for finding malware.

Re:Hidden problems with proxies (1)

Anonymous Coward | about 5 months ago | (#46316623)

The real problem is when some application, other than a browser, needs internet access and it fails.

Correct if wrong, but I thought that if the IT department installed the certificate in Windows itself, most outside programs use this library for their certificates?

Re:Hidden problems with proxies (0)

Anonymous Coward | about 5 months ago | (#46318537)

Consider yourself corrected. Take, for example, an application that downloads updates that *must* be secure. (Doesn't matter why, but let's say it's for a life-critical safety system and legislation requires it.) As best practice it confirms the CN and fingerprint of the SSL server it's trying to connect to but instead of getting the SSL certificate it expected it gets the certificate generated by your dodgy IT department's MITM proxy server.

Unfortunately most applications are inherently insecure because they don't bother checking either the CN or the fingerprint of presented certificates, they rely on the crypto library throwing errors if the expiry dates have passed or the certificate was signed by an unrecognized/untrusted CA. And almost none of them check the CA's Certificate Revocation List URL to see if the presented certificate revoked.

I don't see what the fuss is about. (5, Interesting)

SuricouRaven (1897204) | about 5 months ago | (#46316081)

It's already quite easy to add a * certificate to a browser to allow a proxy to intercept SSL. This is a standard practice in many LANs to allow the web filter to work on SSL pages - otherwise it'd be impossible to perform more than the most basic DNS/IP filtering on HTTPS sites, which would let a *lot* of undesired content through - google images alone would be quite the pornucopia.

All this proposal does is formalise the mechanism that people are already widely using. The end user still needs to explicitly authorise the proxy, no different than adding a * certificate today - and that's something so common, Windows lets you do it via group policy. The author's big fear seems to be that ISPs could start blocking everything unless the user authorises their proxy - and they could do that already, just be blocking everything unless the user authorises their * certificate!

And either way, they won't. For reasons of simple practicality. Sure, they could make the proxy authroisation process easy by giving a little 'config for dummies' executable. Easily done. Now repeat the same for the user's family with their three mobile phones (One android, one iOS, one blackberry), two games consoles, IP-connected streaming TV, the kid's PSP and DS (Or successor products), the tablet and the internet-connected burgler alarm. All of which will be using HTTP of some form to communicate with servers somewhere, and half of them over HTTPS, with the proportion shooting *way* up if HTTP/2.0 catches on.

Re:I don't see what the fuss is about. (0)

Anonymous Coward | about 5 months ago | (#46316391)

If you want to remain relatively secure in your data, you would run these through your OWN server, and filter packets sent out to the internet. Preferably you have some sort of management to potentially 'secure' devices (computer, phone) and 'unsecure' devices (consoles, handhelds). Why the fuck you would ever want to plug a television into the internet (excepting a critical system update and the obvious that the tv is designed to update only from internet connectivity) is beyond me. I believe there is an LG tv out there that phones home and tells the motherserver what you're watching, including the title of movies from a usb stick. I would also cover the camera (with something totally opaque, like a strip of duct tape) and daub a good bit of epoxy into the microphone cavity.

Re: I don't see what the fuss is about. (0)

Anonymous Coward | about 5 months ago | (#46317483)

Samsung SmartTVs do also a tremendous amount of spying and reporting to unnamed third parties.

Re:I don't see what the fuss is about. (1)

SuricouRaven (1897204) | about 5 months ago | (#46317819)

Because some televisions come with built-in netflix streaming support.

Re:I don't see what the fuss is about. (0)

Anonymous Coward | about 5 months ago | (#46316699)

Before MITM HTTPS spying, some places blocked port 443 altogether, so Google images wouldn't work anyway; as well as all credible shopping sites.

Re:I don't see what the fuss is about. (1)

SuricouRaven (1897204) | about 5 months ago | (#46317869)

Not an option with HTTP/2.0. Encryption is required - something it inherited from SPDY. This is because the SPDY designers very much do not want proxies getting in the way and potentially causing all sorts of screw-ups - it's just awkward when a string of perfectly innoculous data happens to trigger a profanity filter and causes a web-app to fail without obvious cause. Also, Google is an ad company, so they are naturally opposed to the other great function of HTTP proxies: Ad filtering.

Re:I don't see what the fuss is about. (0)

Anonymous Coward | about 5 months ago | (#46318353)

I am interested about that as it didn't appear to cause many problems when I was at college when they blocked said port..

Re:I don't see what the fuss is about. (1)

x0ra (1249540) | about 5 months ago | (#46317617)

The NSA, GCHQ and other acronym agency are already spying everybody, so let's just formalize that even more. HTTPS MITM very basics is wrong, formalized or not.

Re:I don't see what the fuss is about. (1)

tlambert (566799) | about 5 months ago | (#46318137)

It's already quite easy to add a * certificate to a browser to allow a proxy to intercept SSL. This is a standard practice in many LANs to allow the web filter to work on SSL pages - otherwise it'd be impossible to perform more than the most basic DNS/IP filtering on HTTPS sites, which would let a *lot* of undesired content through - google images alone would be quite the pornucopia.

So, if I understand you correctly, this proposal does nothing which it is not already possible to do, and should therefore be discarded...

Misleading summary (1, Interesting)

claytongulick (725397) | about 5 months ago | (#46316121)

From the *actual* draft:

This document describes two alternative methods for an user-agent to
            automatically discover and for an user to provide consent for a
            Trusted Proxy to be securely involved when he or she is requesting an
            HTTP URI resource over HTTP2 with TLS. The consent is supposed to be
            per network access. The draft also describes the role of the Trusted
            Proxy in helping the user to fetch HTTP URIs resource when the user
            has provided consent to the Trusted Proxy to be involved.

The entire draft is oriented around user consent and transparency to the user... where is the problem here?

The linked article by Lauren Weinstein is very heavy on sarcasm, scorn and flippant one-liners, but pretty light on technical details. From what I can discern, her primary concern is that ISP's will force all of their users to consent to them acting as a trusted proxy or refuse to serve them.

This is pretty far fetched, imho. First of all, the backlash from the average consumer would be staggering. If, every time they go to their bank's web page, they get a scary security notice "do you want to allow an intermediary at "trustedproxy.verizon.com" to see your private data?" they answer, every time, will be "hell no". And if they are then unable to access their bank account because of this... well, that's not going to be a pretty picture for L1 support.

Second, the *last* thing most ISPs want is to have to deal with yet more PCI concerns. If they end up storing your cc number and ssn in a plain-text cache, that introduces all sorts of potential problems for them.

It seems like the primary use case for this technology is in serving media-heavy content that SSL screws up, like streaming video over ssl etc... so, it would allow caching etc for various media streams that really don't need SSL. And the user could make the decision for whether they want to do it or not.

This seems like a pretty smart thing to me, I'm not sure what all the hand-wringing is about. Maybe I'm missing something obvious?

Re:Misleading summary (0)

Anonymous Coward | about 5 months ago | (#46316319)

It is like saying "We supply condoms to all people who work closely with children." It is fundamentally missing the point. There are so many things wrong with JUST the idea that proposing this draft on any day other than April 1st was out of line.

Perhaps someone got trigger happy on this year's April Fools RFC.

Re:Misleading summary (2, Insightful)

Anonymous Coward | about 5 months ago | (#46318565)

This is also from the *actual* draft [ietf.org] :

7. Privacy Considerations

Notice how it's empty? The author(s) plainly don't give two hoots about use privacy.

A Question (2)

turkeyfish (950384) | about 5 months ago | (#46316167)

What is going to happen to all those secure credit card transactions that are the life-blood of internet commerce, when third parties figure out how to decrypt packets en-route by infiltrating the procedures of ISP's and alter them to "achieve efficiencies"?

You would think capitalists have a lot to loose if this proposal goes forward.

Re:A Question (1)

smash (1351) | about 5 months ago | (#46316197)

You mean playing man-in-the-middle with your HTTPS? It's already been going on for years.

Re:A Question (2)

TheGratefulNet (143330) | about 5 months ago | (#46317161)

if I didn't install the OS and I'm inside a corp LAN, I assume the worthless little 'lock' icon doesn't mean shit anymore.

I would use my own laptop and my own purchased and installed VPN.

these days, if you are in corp LAN, you have to assume you are being logged and traffic sniffed. this isn't 10 yrs ago when it was new and hot to do this; I would assume any company bigger than 10 people have this 'proxy' shit going on (mitm ssl).

and about 10 yrs ago, I had an interview at bluecoat when I was informed by a manager there that they were SO PROUD of the sniffing and fake certs they make users accept (crafted to look very much like 'real' ones) and that the lock icon is worthless from now on. I didn't take the job (it was too creepy) but that was a huge eye-opening for me. I did post about it and got lots of disbelief. well, NOW there isn't so much disbelief anymore. turns out I was right (or rather, BC was right when they showed me this demo at the interview).

Re:A Question (0)

Anonymous Coward | about 5 months ago | (#46318419)

I would use my own laptop and my own 4G dongle

I feel this would be more secure, in the event that VPNs are blocked at said workplace.

Re:A Question (1)

Rick Zeman (15628) | about 5 months ago | (#46316209)

What is going to happen to all those secure credit card transactions that are the life-blood of internet commerce, when third parties figure out how to decrypt packets en-route by infiltrating the procedures of ISP's and alter them to "achieve efficiencies"?

You would think capitalists have a lot to loose if this proposal goes forward.

No kidding. Every day brings more and more proof that the bad guys are smarter (or at least way more motivated) than the good guys.

Re:A Question (0)

Anonymous Coward | about 5 months ago | (#46317853)

Nah, they're fine with it because their brand of capitalism is heads they win tails we lose. They don't give a shit about security because it falls on the consumers.

"Alarming"? (0)

BlueStrat (756137) | about 5 months ago | (#46316279)

Yes, to those who believe that there should be limits to government power.

It's certainly not surprising or unexpected for those who've been paying attention.

At it's root, the cause is simple.

People want government to provide more and more stuff and do more and more things.

In order to do all that, government must have the wealth and powers to accomplish it.

Because human nature is what it is, giving any person or group that much power insures eventual corruption, and ultimately, results in an authoritarian/totalitarian regime if left unchecked.

It's like gravity, in that one cannot set in place any set of laws/rules/etc to change it. That's why the writers of the US Constitution tried to make as much of government as possible a strictly local matter and leave very little for the central government to do except things like treaties and wars. We left that behind in the early-1900s thanks to Woodrow Wilson, FDR, and the Progressive movement, and haven't looked back.

In order for government to grow, individual freedom, choice, and wealth must suffer, as it is only from limiting/taking the people's wealth, freedom, and power of choice that government is able to act.

Everybody is born free, government can only limit that freedom just as government creates no wealth and can only take it from those who create actual wealth.

More government = less freedom. It's a zero-sum equation. More of one necessitates less of the other.

How much less-free do you want to be today?

Bastardizing or just plain ignoring the Constitution to grow government since the 1950s at a nearly geometric rate to feed the entitlement bread-and-circuses to buy votes and paying for it by enslaving future generations with our bills and loss of freedoms and choices has been working out *great* so far.

$17 trillion in debt and an emerging authoritarian police/surveillance state with thermonuclear/biological weapons and one of the top3, if not the top, military in the world, great.

The world needs to pay attention, because once those in the US government have secured their power here and raped the domestic economy, that military will be sent out to secure more wealth from other countries to feed the beast.

You people in other countries had better pray to whatever/whoever you hold dear that those citizens in the US fighting to try to reduce the size and power of the US Federal government succeed or, and heed my words well, what will be coming your way if they fail will make the Nazi reign of terror and death look like a Cub Scout jamboree and George Orwell's "1984" look like an independent-thinker's and truth-lover's Utopia.

Be afraid. Be very afraid.

Strat

Re:"Alarming"? (0)

Anonymous Coward | about 5 months ago | (#46316479)

You a thinker, ain't ya? We don't do none of that thinkin stuff round these parts, boy.

Re:"Alarming"? (0)

Anonymous Coward | about 5 months ago | (#46318101)

Yes, sirree! Everyone, make sure to vote Republican, we have to make sure these unconstitutional powers are used the right way! We have to make sure people only have approved sex and ingest approved substances, and make sure they do nothing to upset our corporate masters.

Wake me when the tea party is dead and the social "conservatives" have impaled themselves on a Jesus dildo so we can vote for some real conservatives.

Re:"Alarming"? (1)

BlueStrat (756137) | about 5 months ago | (#46318597)

Yes, sirree! Everyone, make sure to vote Republican,

Sorry to ruin your fun at my expense, but the Republicans are just as guilty as the Democrats.

It's not an (R)/(D), Left/Right. Liberal/Conservative thing.

It's a "basic civil rights all humans are born with" thing.

Sell that partisan (R)/(D) crapola somewhere else. I'm not buying.

Strat

every firewall is already doing this (0)

Anonymous Coward | about 5 months ago | (#46316281)

most firewalls that decrypt SSL session already do this. Their method is slightly different. They launch a MITM attack by faking the digital certificates of websites. Bet you didn't know this.

Re:every firewall is already doing this (0)

Anonymous Coward | about 5 months ago | (#46318505)

And most workplaces install the fake certificates so the firewalls don't cause any popup errors like "ZOMG BROWSER CERTIFICATE MISMATCH" with the famous two options, "Proceed"? or "Get Me Outta here"?

My Favorite Part (3, Funny)

redshirt (95023) | about 5 months ago | (#46316301)

Is that Section 7, "Privacy Considerations," has no content.

Re:My Favorite Part (1)

bussdriver (620565) | about 5 months ago | (#46317697)

Should we trust anything coming out from the US Department of Commerce?

Re:My Favorite Part (1)

Alsee (515537) | about 5 months ago | (#46318583)

Actually there is an extensive section on Privacy Considerations, but it has been deemed classified under U.S. National Security.

-

Heck no stay out of the middle (1)

mattr (78516) | about 5 months ago | (#46316373)

Call me old school but transparent interception of https does not increase my feeling of safety. It breaks the net and any security I might imagine in a transaction. This technology will make it really easy for anyone to do what for example Microsoft does to Skype connections (which is why Skype isn't allowed in my company). It provides for any number of decryption points to be created between you and your bank or whatever. The doc suggests that it can be used for both anonymization and deep inspection, positing that both are "good". I think it depends on who the user is whether one is desirable or not. As for a company pushing corporate certificates down its users' throats without them knowing it, I think this is pretty dangerous. The Internet is such a pervasive part of life now that if not informed, a user has a reasonable expectation that his or her communications will not be intercepted and possibly reformulated. It is like an operator listening to your conversation and being able to interject words into the conversation that you both think the other has said. Perhaps some people who don't remember a time when there was no social media don't get it. However I think a company should trust its employees and not intercept communications leaving the company, it is despicable immoral and weakens human dignity.

If there are such overarching security issues like multimillion dollar contracts or secret plans that are worth alienating your workforce, then you should tell them and also install other demeaning but powerful security technology like biometrics, laser fields, strip searches, etc. The idea that some guys sat down to write this document and imagined that the "good" uses of this would not be massively overshadowed by the horrible uses of it is just so appalling it nauseated me to read it.

Yes this sort of thing is going on now. But no, I don't think it is a good direction for society, I am not talking about national security forces but about corporations who will find plenty of reasons to implement this, so that while the desired "responsibility to management" i.e. load balancing, security monitoring, whatever is performed, there will become much more generally available back doors into any available communication ready waiting for someone who thinks it might be neat to open the door. The technology works regardless of whether there is a court order or anyone responsible in the vicinity. You may think I am paranoid but I think it is one thing when the police need wiretapping to catch mobsters. (I doubt they would catch any terrorists that way but who knows.) But it is another thing when the campus police, the kindergarten babysitter, every tom dick and harry with a web/phone/video startup is going to see this as a fresh new playing field. If they want to outlaw ssl fine. But I don't want to be using ssl and not know if it really is working or not because my ISP or phone company or cable company feels a need to be a man in the middle. Must the net be infinitely porous? They just can't leave shiny toys alone.

Not your computer (1)

dackroyd (468778) | about 5 months ago | (#46316449)

The author who says that this is 'most alarming' is missing one key thing; sometimes people use computers that belong to someone else.

Any company that needs it's employees to be able to use the internet, but also want to be able to detect any employee that is sending documents via the internet to outside of the company would love to use this, as well as have every permission to install this on their own computers. They could then have the employees computers trust the SSL proxy, and it could easily detect any documents being transmitted.

Poul-Henning Kamp covers this at the end of his talk at http://www.infoq.com/presentat... [infoq.com] from 14:40 .

Re:Not your computer (1)

tlambert (566799) | about 5 months ago | (#46318171)

The author who says that this is 'most alarming' is missing one key thing; sometimes people use computers that belong to someone else.

Any company that needs it's employees to be able to use the internet, but also want to be able to detect any employee that is sending documents via the internet to outside of the company would love to use this, as well as have every permission to install this on their own computers.

Alternately, they put in a transparent https proxy, and sign a trust certificate for the proxy, and install the cert on all the corporate computers. Attempts to access port 443 from interior computers which do not already have the cert installed are redirected to a download page for the cert, and have a one-time "opt in". Making the proposal totally unnecessary for this use case.

The blind leading the blind (2)

LostMyBeaver (1226054) | about 5 months ago | (#46316569)

While the article justifiably blows a whistle on what could be an abuse or power, the premise of the article is BS at best. It suggests that the tech could be used to maliciously snoop on people without their knowledge. The spec says nothing of the sort. It allows a user to make use of a proxy. In the case of a TLS only HTTP 2.0, this is needed. Without it, people like myself would have to setup VPNs for management of infrastructure. I can instead make a web based authenticated proxy server which would permit me to manage servers and networks in a secure VPN environment where end to end access is not possible.

Additional benefits of the tech will be to create outgoing load balanced for traffic which add additional security.

How about protecting users privacy by using this tech. If HTTPv2 is any good for security, deep packet inspection will not be possible and as a result all endpoint security would have to exist at the endpoint. Porn filters for kids? Anti-virus for corporations? Popup blockers?

How about letting the user make use of technology like antivirus on their own local machine to improve their experience? How many people on slashdot use popup blockers which work as proxies on the same machine.

This tech adds to their security end-to-end instead. After all, it allows a user to explicitly define a man-in-the-middle to explicitly trust applications and appliances in the middle to improve their experience.

What about technology like Opera mini which cuts phone bills drastically or improves performance by reducing page size in the middle.

Could the tech be used maliciously? To a limited extent... Yes. But it is far more secure than not having such a standard and still using these features. By standardizing a means to explicitly define trusted proxy servers, it mitigates the threat of having to use untrusted ones.

Where does it become a problem? It'll be an issue when you buy a phone/device from a vendor who has pre-installed a trusted proxy on your behalf. It can also be an issue if the company you work for pushes out a trusted proxy via group policy that now is able to decrypt more than what it should.

I haven't read the spec entirely, but I would hope that banks and enterprises will be able to flag traffic as "do not proxy" explicitly so that endpoints will know to not trust proxies with that information.

Oh... And as for tracking as the writer suggests... While we can't snoop the content, tools like WCCP, NetFlow, NBAR (all Cisco flavors) as well as transparent firewalls and more can already log all URLs and usage patterns without needing to decrypt.

So... May I be so kind as to simply say "This person is full of shit" and move on from there?

Re:The blind leading the blind (2, Insightful)

Anonymous Coward | about 5 months ago | (#46318013)

This tech adds to their security end-to-end instead. After all, it allows a user to explicitly define a man-in-the-middle to explicitly trust applications and appliances in the middle to improve their experience.

I think you need to re-examine your use of the word "security" and "end-to-end".

This does precisely the opposite of what you said, to achieve the aim you stated.

"This tech reduces their security end-to-end, to improve their experience" is what it does. I admit, it has the potential to improve their experience, if cached content is more important that secure content. But it can only *reduce* security end-to-end. There is no possibility whatsoever that it could ever maybe slightly increase security. It can only possibly improve their experience, as long as that experience is wholly devoted to page-load-times due to cached content and content compression.

If their "experience" is ever tainted by things such as, information leak or third party malware injections, then this technology can only ever reduce security, since there is an additional place to target for such things that never existed before.

YOU FAAIL IT (-1)

Anonymous Coward | about 5 months ago | (#46317171)

shaal we? OK! and that th3 floor

Not Sure this is particularly alarming (1)

the eric conspiracy (20178) | about 5 months ago | (#46317335)

It seems to me this is just an attempt to standardize what people are already doing with fakey hackish methods involving bogus certs etc.

If users blindly follow ISP instructions (1)

nmoore (22729) | about 5 months ago | (#46317949)

How would most users respond if their ISP told them "You must add these certificates to your browser" (with instructions, or even a little installer program)? They could then use their bogus CA to MitM every use of facebook/google/whatever.

This seems no different, since it's up to the browser (not just the ISP) to enable the trusted proxy stuff. If a browser enables it without your consent (just as if they deliberately add a bogus CA to the trusted cert list), the browser is being evil and needs to be fixed. If it is left to the user, who enables it without understanding, that's unfortunate, but no worse than what can currently happen.

Did you look at the authors? (1)

slincolne (1111555) | about 5 months ago | (#46318011)

The authors for this RFC are interesting.

You have a team from Ericsson (as in SONY Ericsson). It's not like any business worth its salt would seek advice regarding security from Sony.

You also have authors from AT&T - who have probably been passing customer data on since the days of Teletypes and morse code.

Section 7 (Privacy Concerns) is blank - you have to ask why (too hard, or not a concern).

Requires consent of the user, sky is not falling. (0)

Anonymous Coward | about 5 months ago | (#46318035)

"...when the user has provided consent to the Trusted Proxy to be involved..." and
"The user-agent then SHOULD secure user consent."

The way it is going to work is that a certificate is installed, via a trusted authority, that is flagged as being used for proxyAuthentication. The client software attempts to connect to a server through a proxy, usually on purpose. Examples: caching server for speeding up transit, tor-like proxy for conveying anonymity, corporate network for preventing malware or tracking usage, etc. The client software is required to notify the user they are connecting through a proxy, present the certificate to them for verification, and ask them if they give consent to the proxy to decrypt their data. The user can at this point, reject the connection.

This is being blown out of proportion, it is not intended to be used in MITM attacks unbeknownst to the user. Let me summarize the draft in english:

1) It requires user consent before it can happen.
2) The user is informed it is happening, so they're aware of the proxy.
3) The IETF draft even requires that the consent is only active for the current session, future sessions will requires consent by the user again. Unless the user explicitly requests to permanently provide consent. But, again, the user is involved int he decision.
4) If the user does not provide consent, then the proxy connects the user and the destination server directly. The proxy is just passing encrypted messages it cannot read to the server for the client at this point.
5) On the other hand, a captive proxy although it sounds scary, directly presents the user with a webpage requesting consent before allowing access to the connection provided by the proxy.
6) The user can opt of the proxy.
7) The draft requires the headers provided by the server indicate their is a proxy in between.
8) Not just anyone can generate one of these proxy certificates, it requires extended validation.

Nothing to see here, move along citizen.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>