Slashdot Mirror
Most Alarming: IETF Draft Proposes "Trusted Proxy" In HTTP/2.0
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."
The draft seems to read the opposite of what the summary is saying.
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.
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Also, she really needs a shave.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
Are you sure you understand what is being discussed?
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.
XML is like violence. If it doesn't solve the problem, use more.
You don't understand how things work, do you? This bypasses your "acceptance" requirement.
They can just do it transparently.
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.
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.
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.
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.
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.
Pain is merely failure leaving the body
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.
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?
Drinking habits can be dangerous. You can choke on the cloth and the nuns will wonder where their clothes are.
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.
Yes, I'm sure I'm not. Just like I know you're an AC idiot wanking away in your mother's basement.
And she looks really butch on the motorcycle with the ape hangers.
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."
Mod me down, my New Earth Global Warmingist friends!
Is that Section 7, "Privacy Considerations," has no content.
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.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
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.
Mod me down, my New Earth Global Warmingist friends!
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... from 14:40 .
"Free software as in beer, copy protection as in racket" - Telsa Gwynne
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?
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.
no, I don't have a sig
But possibly with the side effect of loosing your connection, or the ISP makinbg it slow for you like they do with Netflix.
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.
Mod me down, my New Earth Global Warmingist friends!
It seems to me this is just an attempt to standardize what people are already doing with fakey hackish methods involving bogus certs etc.
Ken Ham has lots of followers but that doesn't make most all of what he says true.
Consent can be as simple as logging in to a web portal. Think about it a little more. It'll come to you.
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.
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.
Sure, you have a "choice" whether or not to trust a particular proxy, but in many cases it's a Hobson's choice: "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?
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).
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.
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.)
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.
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.
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.
Sounds like a certain someone doesn't know how SSL/TLS works.
Mod me down, my New Earth Global Warmingist friends!
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
Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
You a thinker, ain't ya? We don't do none of that thinkin stuff round these parts, boy.
My apologies, Senator.
Strat
Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
Ken Ham would think that the RFCs on Avian Carriers were groundbreaking science and is not a Google consultant with 20 yrs of IT under his belt.
His followers are mostly led-by-the-nose idiots; Lauren's are largely grizzled geeks & distrustful nerds.
Pain is merely failure leaving the body
It's not going to be presented as a matter of trust. If the proxy bothers to ask the user to opt in, they will ask "Do you want us to use the SuperMegaFast approach to get this page or the normal way that's likely to be somewhat to much slower?" When phrased like that, I think most non-technical users (and even some technically-savvy users) would choose the fast MITM approach.
"someone didn't RTFM!"
And apparently that someone was not alone.
Right there on the first page it also says it calls for a mechanism for the person making the request to provde consent for the "trusted" proxy to, well, be a proxy.
Granted, there could be problems with people consenting when they shouldn't. There might also be problems with essentially coerced "consent", as in a situation where that is the only avenue for accessing that resource. But those are different problems than that of someone just inserting themselves in as a man-in-the-middle.
Sounds like a certain someone doesn't know how SSL/TLS works.
Sounds like someone has never heard of "router level redirect to proxy" and "deep packet inspection" so that you can either use their proxy and let them see your traffic, or you don't get to negotiate a connection.
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.
Really? Because the draft says that the end user must explicitly given permission for every session(no "always agree" option). You really think FireFox and Chrome will not prompt the user and ask them if they want to use the proxy? If they didn't, I guarantee that someone would immediately fork the projects and make them work that way.
Oooh "router level redirect" that sounds serious. I bet it never occured to the creators of SSL/TLS that *routers* could be involved with transferring the traffic.
Heavens no.
Mod me down, my New Earth Global Warmingist friends!
One of the benefits of using HTTPS currently is that it avoids broken proxies. There are all sorts of implementations that claim to support HTTP 1.1, but don't support 100 Continue, content negotiation, or other important features you might need to use. If you use HTTPS, it currently avoids all the breakage (unless the destination server itself is actually broken). Besides the security issues inherent in this model, you have to worry about all the cases in which somebody installed some broken proxy that doesn't actually implement half the standard, breaking all sorts of sites.
Have you ever used a hotel wifi? When you login, they can use that to as your "agreement" to use the proxy as well. Did you read the draft? They can set it up such that if you disagree, you are stuck in limbo hell.
TLS would indicate a man in the middle by means of a certificate warning. Now imagine getting a warning that the certificate is signed by your ISP for every single HTTPS site you visit other than your ISP's own site. You check the knowledgebase on the ISP's site and find a statement to the effect: "Either you accept our proxy certificate or you don't get to connect."
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.
Even if the only private piece of information is the session cookie identifying the logged-in user to the site, that's still "a private matter between" the user and the site. Since the Firesheep tech demo became public, it has become common for some web sites to go all HTTPS all the time to prevent intruders from snooping and replaying session cookies. Facebook and Twitter do this, and Wikipedia turned it at the end of August of last year. The biggest historical obstacle to HTTPS implementation for any site on a VPS or bigger has been mixed content introduced by ad networks, but in September of last year, Google finally enabled HTTPS for AdSense.
Argument from authority and popularity are fallacies.
So does installing the Ask Toolbar, but I'll be damned if I can find anyone who knew they had consented to installing it...
Not always. Especially when the person in question is something of an expert and the rebuttal consists entirely of "he's wrong"
Pain is merely failure leaving the body
Some workplaces are already in that situation due to those stupid "SSL accelerator" boxes.
Personally I think that is insane even if 100% of the traffic is work related - do people really want a nice handy little box where an outside contractor, the new kid helping out with cabling, the vendors of the device and anyone who knows the backdoors in such a never patched appliance get only confidential traffic nicely sorted and giftwrapped for them?
Please log into your account and press yes to agree that you want to use internet though our ISP and to use out transparent proxy which is an integral part of our service. Thank you.
If there was a caching proxy closer to the edge that made your wget of an ubuntu ISO 10* times faster, wouldn't you want that?
There are a million ways to do this already.. CDN's, anycast, redirects... how is operating a proxy at scale a viable alternative to all the other shit that stays out of the data path?
No, you don't want your HTTPS Gmail to be cached and snooped - but that's perfectly ok, because that's NOT what is being proposed here.
No it is just ISO of your new operating system that will be used to access your gmail account. Oh yea those **MD5** checksums on Ubuntu's.. I give up.
This is the same question as what to do with "HTTP" (not HTTPS) requests when transported over HTTP2 (which is supposed to be all TLS) and SPDY (which is already all TLS, and which HTTP2 is based on). Usually it's framed in the context of "do we need to authenticate and verify TLS certificates when the user didn't originally request HTTPS?"
Some people are of the opinion that "TLS is TLS, and if you can't 100% trust it, there's no point." And I can see the logic in that. Obviously that should always be the case when you've explicitly requested an HTTPS connection, and ideally, at some point in the future, it would be nice to be the case for all network connections, all the time.
But when you step back, you have to realize that those connections are currently completely unencrypted and untrusted - they're HTTP, not HTTPS. And that the march to encryption is slow. The majority of websites have no TLS encryption capability at all, maybe as many as 20% of the remainder are self-signed, and quite lot of the rest may have certs which don't match the domain being requested. (The same is no doubt true of apps, mobile or otherwise.) And the latter problem, particularly, is quite difficult to solve for technical reasons in a lot of cases critical to the orderly and economical operation of the internet, such as CDNs.
This goes beyond the usual lament that sites will need to pay $100+ per year to get a cert - that's not really the problem, though from my experience most site owners will have to be dragged kicking and screaming before they bother to install a cert and get HTTPS running properly. Even if a cert is installed, most of them want to redirect back to HTTP at any opportunity.
Besides performance, cost, and administrative hassle, the big problem is the royal pain that it can be to take care of all the issues of trusted certs across hosting providers, CDNs, lead generation partners, etc. That's because in a lot of cases, those providers are hosting assets under a variety of domains - sometimes hundreds or thousands of domains - on single shared servers (or many copies of shared servers), each with a single IP address shared among the various domains. It's shared hosting all over again, this time writ large across global CDNs and the like. Even with your own hosting provider, you might face the same problem on development and staging environments even if not on production, making testing difficult. And while they're working on the problem, so far HTTPS does not play well with shared hosting. (On top of that, a lot of ad networks don't support HTTPS at all, so they introduce the mixed content problem into your pages. If your site depends on ads, you might not be able to serve them over HTTPS connections, which is why some sites offer HTTPS only to paying customers.)
The whole idea of SPDY or HTTP2 being "TLS-only" is laudable, to gain opportunistic encryption even when the user didn't request HTTPS. But by so thoroughly breaking sites with mixed content or untrusted certificates (either expired or self-signed or for the wrong hostname or whatever), I'm of the opinion that all it's doing is delaying the adoption of TLS for websites. Rather than going "oh well, to get HTTP2, we'll have to fix this", most sites, faced with the hassle and resulting broken pages, will drag their heels adding HTTPS or enabling HTTP2, forcing downgrades to HTTP 1 for many years to come.
Encryption absolutists portray the question in simple terms: why would you not want to trust your encrypted connection? You'll be vulnerable to man in the middle attacks, therefore they should always be authenticated and verified. But the real question is: when users haven't specifically requested HTTPS, is it better to have those connections mostly be COMPLETELY unencrypted and untrusted (which are even more susceptible to MITM), but when they are encrypted to trust them (even if the user can't see that they're encrypted or trusted)? Or for a larger proportion of them to be encrypted, but not necessarily always trusted in the f
Even if the proposal became a Standard, that doesn't mean EITHER web-server developers, or browser developers, must actually implement it.
There's a book with a crab on the cover that you probably should read so you can get an idea of what we are discussing here.
sure, "by connecting to ISP x's network you agree to provide consent to our use of trusted proxies to provide you with enhanced network facilities. Do you want to proceed?"
That assume they don't just bury it in the small print and so you "agree" to its use permanently.
The whole point of the article was own to this - trusted proxies will be inserted everywhere by your ISP and your data will be mined by them. Maybe its a bit paranoid,but its probably best to be quite clear right from the start.
See here - http://en.wikipedia.org/wiki/L...
Pain is merely failure leaving the body
This is laughably a bad idea.
This will be abused the instant it hits code. The temptation is too great. This will sink the adoption of http 2.0 and 1.1 will live for a far greater time.
With all of the news around man in the middle attacks I just can't believe this will be a feature.
This needs to be amended. I can see trusted chains, Where you would trust a chain from end to end, but just the proxy? With each node in the chain being able to cache.
Sure, Terry, but what's worse, an MITM DOS ("you don't get to negotiate a [n https] connection") or an MITM that allows full inspection and modification of data that one (typically the server-side) or both ends think is an HTTPS connection?
The server side has lots of standardized and/or developed tools to protect the integrity and privacy of data between the server and the browser that does not rely upon perfect (or even any) HTTPS. The assumption that HTTPS is perfect -- or even close enough -- has been holding back deployments of such tools for more than a decade.
Apart from opening doors to greater network efficiency along several axes (caching and other deduplication and localization approaches, distribution away from single front ends, greater concentration of resources on single NLA addresses), deliberate trusted proxy ought to push people into reconsidering whether only-the-server-side-has-a-certificate TLS is *sufficient* for integrity and privacy. (I don't think it is, and I suspect that view is shared by at least some people behind two-factor authentication etc.)
However, the safer bet is that the proposal is likely to be strangled by people with a very narrow view of HTTPS, or by a lack of engagement on the way deliberate trusted MITM affects the security model of the whole WWW (few people will ask if it can actually *improve* overall security compared to the many people who will argue that it necessarily erodes it). It's a pity, because separating integrity (arbitrary chunks of data with some signed checksum) and privacy is likely to be a clear win on energy where integrity-but-not-privacy-required data are popular enough to warrant being highly distributed and/or highly cached.
Finally, another question that ought to be addressed is that a lot of eggs are in the HTTPS basket, and not all of them have been inherited from everything-over-HTTP. That deliberate trusted MITM exposes this question is not a bad thing, I think. However I would again bet that the consensus will be that the convenience of everything-over-HTTPS will trump that of a standard approach to making (especially) HTTP inside HTTPS amenable to caching, ad-removal, virus-removal, and whatever else a "middlebox" might do with HTTP now. After all, if someone really wants to do that, they can simply disallow (well, "break", even) HTTPS negotiation altogether...
Thus, my own answer to my question at the top: where there is agreement to enable a trusted MITM to act, then an MITM DOS is much worse; but for any other case it's the lesser of two evils. The key thing here is in how to determine agreement and trust; where that's not clear to either the client side or the server side (which is likely a harder problem), surely it's not enormously different from an MITM DOS ("can't establish a valid HTTPS connection" because of anything from TCP port blocking to pinned certificate mismatching).
From the fine artiicle at http://www.theregister.co.uk/
"...the proposal is sponsored by AT&T..."
We should be alarmed. No good will come of this, except perhaps to wake a few innocent slashdot readers from their dream of a safe friendly internet.
Things have changed on the webs - there is evil out there.
How do you think companies, and even countries intercept https traffic?
Also, by way of self-followup, the internet-draft proposes a mechanism to distinguish between https URIs over encrypted http2 connections and http URIs over encrypted http2 connections, with the goal that only the latter will be subject to manipulation by an explicitly trusted proxy, and that the client, the server, and conforming proxies all take steps to avoid unnoticed manipulation or examination of https URI related data. (The client, server and proxy all have opportunities to "opt out" of the proxy's manipulation or examination of http URI related content).
Did you miss the "get only confidential traffic" - it's going to take a hell of a lot of normal traffic before you get 1TB of encrypted stuff.
If the argument is, "trust me, I'm a popular authority" then sure, that isn't convincing.
If the argument is, "Here is my argument _page_of_text_, oh, COUPLED WITH I'm an authority on the subject because thousands of other people have a history of listening to me, (aka 'this is not my first rodeo')" then perhaps your should at least listen.
This is the core of "who do you trust". You trust people because of their history that got them to their current position of authority, not just because they are currently in a certain position.