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."
..why the fuck not just connect to the proxy over an encrypted pipe?!?
world was created 5 seconds before this post as it is.
At least it is possible to opt out.
Nothing new.
The draft seems to read the opposite of what the summary is saying.
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
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 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.
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.
And she looks really butch on the motorcycle with the ape hangers.
Maybe her father was listening to Johnny Cash when she was named.
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
Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
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.
Is that Section 7, "Privacy Considerations," has no content.
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.
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?
It seems to me this is just an attempt to standardize what people are already doing with fakey hackish methods involving bogus certs etc.
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.
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).
"...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.
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.
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.
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.
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.
So does installing the Ask Toolbar, but I'll be damned if I can find anyone who knew they had consented to installing it...
Well, perhaps "bit" is perhaps minimizing that you are obviously challenged in both critical reasoning as well as verbal expressiveness.
I'll bet you can't find a job. And you probably have no idea why. You probably blame "the man".
The difference is that the Ask Toolbar doesn't ask you every time that it wants to run if you want to allow it to run. It just runs. Whereas, this trusted proxy draft requires that client software ask the user again each time a new network session is established. The user will not only be made aware of the connection, but be allowed to prevent it. And, the client will also state that you are connected to a proxy, for example a browser will show the certificate issued to the proxy. You'll know you're not connected directly to the server. In addition, you'll notice that you can opt out of proxy connections, the draft includes this. That means you'll be able to set a flag in a client to prevent a proxy from ever even asking you if you want to provide consent. This proposal is obviously intended to a workaround for people who need an encrypted proxy for some reasonable purpose that they actually want to consent to. It is not intended for surreptitiously slurping communications as all of the consent and opt requirements show. It is being blown way out of proportion by people who did not actually read the draft.
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
It's simply a way to keep existing proxy functionality for HTTP 2.0, since all of HTTP 2.0 is encrypted by default. If you configure a proxy in your browser and give it "trusted" status as this draft proposes, then it's doing the SSL work for you and has access to your data. Now the proxy can cache files and do it's general thing.
Don't want that? Don't configure a trusted proxy. This is mostly useful for corporate networks and some other places that either are bandwidth constrained or need/want to log all access and run policy against it.
The "article" is pure FUD with appeal to emotion, witch hunting and lack of any serious analysis.
The "more crypto to the rescue" was thoroughly debunked by PHK in its FOSDEM 2014 keynote (and got ovations from several thousands of tech-savy floss-oriented people).
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.
In this case you add your own CA to all company computers. Then you MITM all SSL connections
That's why the first thing you do on any company machine is remove any company CA certificates from the certificate store.
That's why I unplug the Ethernet cable before boot every morning and don't plug it in until after I'm booted to the desktop. I have a tiny wired router running Tomato acting as the firewall between my machine and the corporate network to fend off their usual hidden VNC or remote desktop assistance spying and remote registry changes. If they do something to the PC while I'm not at work, I just roll back to a previous state using snapshots I save to a TrueCrypt volume on my removable HDD.
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?
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.