Unintended Affordances (or why I believe encrypting everything is a bad idea)
lucumr.pocoo.org
lucumr.pocoo.org
The essay seems to center on "privacy" and "hiding".
The other use for encryption is "authenticity". We want to have trust that the pixels on the desktop monitor or iPhone are actually correct. Whether a user is a city administrator looking at weather.com pixels to decide whether to shutdown schools for the day, or a grandmother looking at NYT or Yahoo pixels to check a stock price before selling, encryption helps ensure the veracity of what their eyeballs see.
Grandma doesn't care if the government or Facebook knows she read the New York Times. Someone on the subway can look over her shoulder to discover that same datapoint. On the other hand, she does need to have confidence that what she reads has not been tampered with.
One could attempt to write "data protection" protocols that send multiple hashes to verify the payload. However, if the hashes are cleartext, you're back to where you started with broken trust because the hashes can be spoofed. The necessity of encryption (without regard for hiding or privacy) appears again.
It would be trivial to add something like <rel signatory="https://this.same.domain/verify" algorithm="sha2"/> to any web page, or an HTTP header of the same nature, and run an HTTPS endpoint to check the url/signature pair. Probably international news agencies could run this, so that the proverbial China government would be able to see that a web page has nothing subversive on it, but anyone could see that the page has not been tampered with, by running a checksum against the page source. A browser extension could be used for that.
But it seems that nobody cares enough.
That's not true at all. For instance that we fetch web fonts via SSL is just because there is no other way to verify the identity of the webfont otherwise. There is nothing inherently private about a web font.
The same applies to Python packages on PyPI etc.
If NYT or Yahoo Finance has a javascript widget to let a reader pick a stock symbol, and dynamically choose start and end points of stock performance, what "body of text" is relevant to compute a "signature"? What if the NYT has an option to dynamically translate their stories into other languages, or rotate different related stories on a sidebar? Are servers constantly regenerating thousands of signatures for all unforseen combinations of dynamic text? And how do these multiple signatures continuously travel from the server to the browser? Presumably it would be an encrypted channel because cleartext signatures would be vulnerable to tampering. Would a browser then have twin-channels (2 ports) open for the NYT page? One channel is encrypted for the signatures and the other channel is the cleartext? Why would this scheme be "better"? You still have encryption somewhere.
You can make value based arguments for/against pervasive encryption, but technical arguments against it continue to be debunked.
Netflix, and many others before them, have demonstrated it is possible to do so. Obviously there is an impact.
But many people like to immediately say, "its too resource intensive! it cant be done! its not practical". Those people are wrong. It's expensive. It may take engineers. But it can be done.
For other operations that provide authenticity like an HMAC it's the same deal, the good thing about having a cryptographic MAC assigned to a message is that you can easily compress the entire message in transit and now have to force clients to compress the message prior to encryption.
The cost of putting a checksum on a document however is tiny in comparison. Any many of the cases where we currently fetch resources from CDNs there is no reason we could not leave out the SSL and instead reference assets by SHA1.
A signed checksum like an HMAC is much better.
And even if we would go back to cryptographically signing resources you still benefit from it tremendously speed wise because after the initial signing, you can serve up the same data to everyone directly from memory or filesystem. Your argument does not work either way.
Then you have all the problems of setting up a second, secure channel. This would seem to increase complexity, not decrease it.
>> And even if we would go back to cryptographically signing resources you still benefit from it tremendously speed wise because after the initial signing, you can serve up the same data to everyone directly from memory or filesystem.
Sure, if all your data is static this might help in terms of speed, you could drop some of the TLS overhead, though not all of it because you've still got to somehow verify a server signing key or your 'out of line' channel (which is probably going to have to be authenticated and integrity checked itself now.... TLS seems a good way to achieve this)
It reduces the total number of endpoints that need to go through SSL. That is a win complexity wise. I do not need to hand over SSL keys to my CDN for instance. I just put the file there and keep my checksum list on a server I actually do control the keys on. As an example. That is reducing complexity and makes it more secure in the process. At the cost of people knowing which files are downloaded.
So each asset loading connection now requires two connections, one to the content-holder or cache and another to the reference server. I'm not sure this is really reducing complexity. Plus you now need another server that's prepared to accept just as many connections as the CDN to serve signatures, likely increasing latency. I would be surprised if the total compute power and cost comes down very much with this scheme.
I can see how it helps server security in this case, reducing private-key proliferation.
>> At the cost of people knowing which files are downloaded.
Yes, this is still the case, that an observer will know exactly what assets you are loading.
No. If you do it checksum based the checksum is embedded at the place where the asset is referenced from which is an encrypted page. There is even a spec for this in the context of web resources already.
If you do it with cryptographic signing then the same rule applies as with SSL, you just skip the encryption. This is not rocket science.
So you are still loading an encrypted page from somewhere? This scheme gets more complex by the post! I think by extracting this idea from your head piecemeal we have confused me!
Let's see if I have this straight -
I browse to https://www.example.com and get served a page that is authenticated and integrity-checked, but not encrypted. Probably via TLS in NULL cipher mode. Embedded in that page are simple sha2 (sha1 is bad, collisions may be possible) hashes of all the images etc that I need to load. The CDN provides these and I can verify the hashes against what I'm expecting.
OK, you've removed protocol overhead on the assets (if they are binary assets this is likely a very small percentage). And you've removed encryption from everywhere. This allows people to get a verified page that's not secret. There's no reason I can think of this would not work. You're still having to give your private key to any third party cache/front-end that serves your HTML.
At this point we're down to an idealogical argument - I think crypto-everywhere is good because I prefer as little information as possible to leak to any interested parties, regardless of how sensitive it is, and because using crypto on everything helps to hide the important stuff. You would rather some things be observable, and don't think the overheads are justified. This we are not going to resolve :)
You shouldn't do that anyway. If you want to offload your large files to a CDN without compromising your SSL traffic, just have your CDN serve your huge files from yoursite.thecdn.com, for which they legitimately can have an SSL certificate, and then serve your checksums from yoursite.com, for which you have an SSL certificate.
There's no reason why browser-makers couldn't put in a capability to fetch some resources this way, without telling the user that what thy are doing is 'secure'.
However by the time you've done your RSA verification and a per-packet SHA256 HMAC or similar, the overhead of AES encrypting the data might not actually be all that much more...
I would not be able to teach my grandmother the UI of this system, she has a hard time with chrome's SSL lock icon as it is. Encrypting everything is a great situation for her so she can shop online safely.
It doesn't solve the CA problem or the cost problem (you still have the whole cost of setting up a TLS session, actually encrypting the payload is the cheap part). But it's possible.
"Lawful intercept": sure, you have the right, good luck with that. We're not going to make the Internet less secure for the benefit of government interception; if anything, we're making it more secure because of the possibility of government interception. This one is a very old argument, and easily debunked: assuming you allow any encryption at all, just having less of it doesn't make lawful interception any easier, because of course all the illicit traffic will be encrypted. The only thing it does is make encrypted traffic seem more suspicious, which isn't good for anyone.
SNI works just about everywhere these days, and it's quite safe for most services to just turn it on and write off the few systems (IE on XP, and truly ancient mobile devices) that can't cope.
People don't get used to clicking certificate warnings away because browsers have gone out of their way to make that painful, and it should be.
If you don't understand TLS, learn, or count on other people to have learned. That's no excuse for not using it.
There are many folks working on fixing the CA problem, but even without that completely fixed, SSL is still better than cleartext.
All that said, I do think the first section of the article, about unintended affordances (such as emergencies) is worth considering in other technological contexts. That point was made years ago: http://code-is-law.org/
Government censorship is happening if you want it or not. The main difference is now that there is a lot more collateral damage with SSL deployed.
> If you don't understand TLS, learn, or count on other people to have learned. That's no excuse for not using it.
I agree in the sense that anyone who runs a security critical website should deploy SSL and there is no excuse for not doing it. However what triggered the whole article was that more and more websites become completely impossible to use in the absence of SSL even for anonymous data access.
How would you bootstrap a secure encrypted login for a user who was browsing the site without SSL? I agree with you that anonymous data access is often encrypted unnecessarily, but in practice deploying HTTPS is an all-or-nothing deal.
If you have a website where users sign in you are pretty much left with SSL from the sign-in form on but you can move an indirection between the sign in and out so that a user has a chance to verify they are authenticating on the right site. Fundamentally there is no difference from the user's perspective for as long you are okay with moving the log-in box to a secure URL where the user can check the authentication.
Excellent. It means that it's a lot more out in the open and noticeable.
>> owever what triggered the whole article was that more and more websites become completely impossible to use in the absence of SSL even for anonymous data access.
Also good, making sure there's a lot of uninteresting stuff under encryption means that the interesting stuff stands out less.
Also makes it harder for ISPs to alter content or inject advertising. A good thing.
Good. Censorship and other attacks should be as noisy, obtrusive, and damaging as possible, so that we have more incentive to stop it (by both legal and technical means). Such attacks should not pass silently.
> However what triggered the whole article was that more and more websites become completely impossible to use in the absence of SSL even for anonymous data access.
Why do you need to use them in the absence of SSL?
Many ridiculously tiny devices still have enough power to run a simple TLS stack. And if you're really trying to access web services from some potato-powered device that can't run a TLS stack, you have much the same problems as a device that can't run a fully capable network stack at all. In either case, speak a simpler encrypted protocol (e.g. Bluetooth Low Energy, 6LoWPAN) to a local device, that can either provide the services you need or access them on your behalf.
Agreed. It's human nature to not bother to speak up when a group you're not a part of is attacked. If widespread encryption means that more people will be affected when governments try to censor traffic, then I'd say we have one more argument for widespread encryption. http://hmd.org.uk/resources/poetry/first-they-came-pastor-ma...
Good. Make the censorship visible. Make it all or nothing. Force people to move to technologies that cannot be censored (or that at least are more resistant).
The alternative is to let the government censor everything they want and let people see only what the government approves of, with the latter just being easier to deploy and switch to the former if it ever crosses the line.
>Unfortunately, SSL prevents this. Unfortunately because it means that if a website hosts partially illegal shared content, then the whole website is down and not just the subsets of it which are legally problematic.
>But not everybody is entitled to privacy in all situations. For instance convicted criminals are not. Likewise many lawful professions need to be heavily surveyed for security.
>a pilot hid his psychological problems from his employer and intentionally caused a plane to crash.
In my view this is all valid reasons to encrypt everything. When prisoners are made such based on unjust laws, I say that anything that gives them their rights is good. Forcing a government to be very overt about its censorship of websites is good. Allowing people to hide their mental disorders in a world where a mental disorder is still seen as a moral failing is good.
Encrypting everything enforces a positive change on society. Governments have to be more open about their censorship, allowing for greater discussion. Dissidents can communicate in secret, allowing for greater freedom. Critical systems have to be built so that a single individual cannot cause a large loss of life. Groups that are required to be surveyed must directly incorporate it into their systems
As for the cost of using SSL, my understanding is that they are much overstated.
I respect the author but this doesn't read well reasoned.
Firstly CAs not being equipped to scale and the inevitable mistakes that will happen in a highly manual process. Thankfully this has already been resolved, we have DNS - if you are in control of DNS you are authenticated. This is is the system to be used in the EFF automated certificate issuing protocol.
As for CPU cycles we have Moore's law (which is still in full effect for things like SSL decryption). That and many many motivated engineers.
The next bit is where things get sour.
It seems the argument is because law enforcement has the "right" to read your traffic that anything you do to dissuade them will only result in further systematic destruction of privacy, i.e MITM attacks on SSL.
The final points around complexity do make some sense but those are against SSL, not against encryption IMO. SSL and TLS are both hugely complicated but this need not be the case.
As for my point of view.
We need encryption. Why? Because communication has changed.
Communication used to be manual and as such the attacks against it were manual and unable to be orchestrated at scale. Government surveillance was better understood because communication was simpler so lawmakers couldn't destroy all privacy accidentally.
Now almost all communication is digital, it's become economical to simply subvert -everyones- privacy. Lawmakers are at a loss to understand even basic computer science let alone what motivated and technically sophisticated "law enforcement" agencies can do with such massive amounts of information.
We need encryption to save privacy before it's lost forever.
I never said that we don't need encryption, far form it. I said we do not need to encrypt everything and I firmly stand by that. If we do want to encrypt the entirety of the internet traffic then I believe we need to consider all the consequences this causes. That was my point, not more, not less.
The long term solution is to get to the point where lawmakers talk about encryption, authentication and integrity as things they actually understand. Rather than having people with ulterior motives explain these things to them with snail mail analogies.
However, that is many decades off. For now we have encryption and the means to ensure MITM attacks are ineffective.
... as justified by many arguments from ignorance, like "I don't think everyone ...", and "There is no technical reason..." over and over. Even one counterexample for those (some helpfully supplied in comments hereabouts) makes the arguments invalid.
I gave one very practical example of encryption being applied to file transfers without a technical reason why that has to be. The same applies to the majority of resources fetched from CDNs. The only reason we use SSL for that is because there is no other method that browsers currently support for guaranteeing the integrity of the loaded information.
When it comes down to it, it's nobody else's business what python code-modules I'm downloading, it might give them enough information to attack my servers, so secrecy isn't a bad thing either.
I also think it's a bit of a shame that we're having to do all this encryption these days. Think of all that wonderful caching capability we're losing. Still, I come down on the side of "necessary evil", given the increasingly malicious attacks on parties that aren't using it.
There is much bigger issue there: nobody verifies package signatures. Most packages do not even have ones. So you fundamentally have no way to verify that what you downloaded is what you wanted. Someone could have stolen my PyPI access credentials and uploaded a broken package under one of my releases.
Or I'm just a bad person and would ship you bad code.
SSL does not solve that problem.
This is bad practice, and is not solved by less integrity and authenticity checking!
>> Or I'm just a bad person and would ship you bad code.
Nobody said it solves everything, but it does help prevent unrelated third parties getting in on the act, actively or passively.
No, it's a completely orthogonal issue which was my point. But you were bringing up a potential security issue which is that people might know what packages you are using. I'm bringing up that you are installing completely untrusted packages which is your actual issue there, not that someone might be able to know what you are using.
Let alone that with AGPL libraries for instance you are required to disclose that anyways.
There are multiple 'actual' issues here.
One, you have identified, is that the content on the server is not very well verified. This is a problem I agree, and solutions are likely non-trivial. TLS will not fix this for you.
The second one is making sure that what is on the server is accurately replicated on the client. Authentication (am I talking to the real server?) and integrity checking (did I really get what the server tried to send me?) are important here. TLS can address this.
The third is giving away information about modules installed, which may be another risk. TLS will mitigate this.
You're right that the AGPL would require you to disclose to any user which modules are in use and give over the source to anyone that uses your service and asks for it, and in general security by obscurity is a bad idea anyway - however I may not have users, I may be setting up a server only for me to access, and I may not want passive traffic sniffers to know that my experimental server is likely to be running an easily-compromised version of a service for the next five minutes until I patch it.
While this may make short-term practical sense, it's fundamentally wrong. Nobody should be raped, short skirt or not. It's the law enforcement that needs to change and prevent such things, not women. Women, if anything, should carry pepper spray.
Same thing applies to the privacy of communication. Nobody should be a subject to an unreasonable search. Yes, having your communication open provokes any number of three-letter agencies to want to snoop on it, just in case. And if they find it encrypted, they want to crack it — again, just in case. Why not yield?
Again, this is fundamentally wrong, it goes against the letter of the law and the spirit of it. It's the law enforcement that needs to change, not citizens. First have a probable case, preferably a court order, etc. Citizens, id anything, should use encryption more.
This discussion went emotional very quickly.
> It's the law enforcement that needs to change, not citizens.
Last time I was looking there was no world government. What a country has to do and does not have to do is fundamentally decided by it's lawmakers. In some countries those are elected, in others they are not. I'm a programmer and as such I limit my general impact on technical things. I might have the opportunity to shape legislation but I do not claim that I know what every country should do.
Also please note that nobody is forced to wear revealing skirts or use concealing encryption. You are free to do what you think is right. I very much appreciate what you do, and wish you to continue unhindered. I hope we can disagree on the point of usefulness of encryption in certain cases without affecting everything else.
"Oh, I see you're downloading this package in a slightly old version that is still vulnerable. I guess you're going to install it, which means you'll be vulnerable in the next 10 mins"
This is one of the main obstacles of things like apt-p2p or debtorrent (i.e downloading your system packages in a p2p fashion): you don't wan't to tell the whole world what are the packages on your machine.
There's a political reason as well: "I see you just downloaded pycrypto - we're going to throw you on a watchlist since you obviously want to hide something". This speculation is based on past actions doing this very thing with Tor.
Assuming that, once it's off the wifi, it's utterly unrealistic that an attacker could be anywhere else in the packet path? That -- even outside of ecommerce -- there's no way any icky ISP could be doing deep packet inspection to sell your data out for ads, or any virus on a cheap consumer-grade router interested in hijacking your profile to turn into a spambot? And assuming, moreover, that this New Technological Capability would be deployed in a consistent and timely fashion? Sure, I agree it'd be an excellent deterrent to many attacks on its own, but end-to-end encryption easily wins. (And if you're really an interesting "larger website" then you have the resources to make SSL happen.)
This is a fundamental disconnect with how many people on the pro-encryption side think - the government has no right to do this, regardless of the law, and therefore we will do all we can to get in the way.
>> Cryptography is black magic.
It's maths.
>> As of recently the Python package installer downloads every package via SSL. Why? There is no technical reason for this unless you want to hide
There are multiple reasons.
One might be to ensure integrity of the file, and authenticity of the source. TLS gives you this, plaintext not so much.
Another is that the more uninteresting stuff there is getting encrypted, the better, as it means it's less noteworthy.
This is demonstrably false in light of releases like Snowden's stuff. There is little to no democratic oversight, and at every turn the people are denied the knowledge of what their government is doing and are therefore denied the ability to voice any opposition.
How can you democratically oppose something if nobody will even tell you it's going on?
>> Such policy-change-by-technology bypasses democratic process and is dangerous.
Democracy is being bypassed everywhere here.
Pro-encryption people think that blindly trusting government is a bad idea because that trust is too easy to abuse, and cryptography is needed to maintain individual autonomy in a digital world so as to enable individuals to exert their democratic power over the government, so that policy changes can still happen in a democratic process in the future.
Also, you might want to think about why you would not call it a "decree from elites" if the same people decided to not offer encryption, thus not giving individuals the option to encrypt their data as they wish. Or would you?
This is satire, right?
Non-democratic governments. Tyranny of the majority. Independent agencies with the ability to blackmail those in authority.
>not by decree from elites using technology such as encryption
We aren't forcing you to encrypt. You can post your credit card number in plain text on any forums you like. You can choose to only use websites that allow http and choose to always use http.
Pro: Democracy is more stable and more guaranteed Pro: Lower level criminals are thwarted and the cost of attacks prohibit profitability of small attacks. Pro: Increasing value of transactions are becoming possible online. No one in their right (or educated) mind would sign into a $10k+ account if their password/traffic wasnt protected.
sslsniff was released over a decade ago.
But then the message / proposed solution is "let's just give up on TLS except for what I arbitrarily define as important". What I would have hoped for is "let's try to make it better".
The only argument against pervasive solid encryption with potential validity is external-party bypassing; where the external-party is outside the intended group of involved parties (Bob & Alice) and wishes to access or manipulate the secured communications. The most obvious situation being some external authority wishing to prevent or prosecute a crime.
Traditionally, in the US, you (and your property) have agency until a warrant, subpena, or probable cause arises. At this point, and no sooner, the acting authority suspends some part of that agency for the assumed greater good of the society and begins collecting evidence through an established process. Without this suspension of agency the authority, traditionally, cannot and should not be treating you or your property with reduced agency; the authority should not be preemptively diminishing your agency by starting that evidence collection process (compromising protections) with zero probably cause.
It is the problem and responsibility of that authority, as set out by the social contract of free agents comprising our society, to reduce agency and collect evidence AFTER probably cause arises and NOT as the default against every citizen.
What is the recourse for the average Joe when his social network doesn't encrypt logins? Facebook did this for years, the average user just ignored it and logged in, no amount of training or convincing could dissuade many.
What will the user interface look like for a site that is not encrypted but verified secure? It is hard enough to get people verify the lock icon is green or gold. Many ignore and just assume that online shopping is so fraught with hackers that it cannot be done safely. This will not help that situation.
Why do we care about the cost of CPU cycles? No matter how good the encryption is a human still needs to make a decision. Settling on a simple one helps the human make it faster. CPU cycles get cheaper every year but the brain hasn't improved in thousands.
Encrypting everything is simple and can be made to work even for less technical people.
If we forgo simplicity I will still encrypt what I can. Having only some protection is not the same as my protection being an illusion.
Perhaps he should have said "Using SSL is like using antibiotics. If everyone is using it all the time, the attackers just find ways around it that are impossible to defend against and you're screwed."
Not sure I get the analogy about having gates on the subway are bad when people need to use the subway in an emergency. Like, if you have a stab wound and are taking the subway to the hospital, its better not to have to fumble around for change in your pocket and line up for a ticket? Seems like there are actually very few or no emergencies where someone needs to ride the subway for free.
Also, I'm no SSL expert, but even if the certificate is expired and the user acknowledges the error, isn't the communication still encrypted? They don't lose the encryption just because of an expired certificate do they? I honestly don't know, but I just assumed that's how it worked.
The one thing I agree with is that the trust model for SSL is opaque to most users. I have no idea who my browsers trust by default, and I have no idea who those guys trust, and even if there is a 3rd degree of trust beyond that, and so ultimately there are thousands of people around the world who could spin up an SSL certificate that my browser would trust without question. Strange system.
Except no such mechanism exists. If you build proper crypto, it's secure, attackers can not simply make it insecure by wishing it were.
> Also, I'm no SSL expert, but even if the certificate is expired and the user acknowledges the error, isn't the communication still encrypted?
But it might be using a compromised key, for example. Also, one problem is people getting used to clicking "OK" on SSL warnings, which might backfire when confronted with an actual attack.
It's like the XKCD cartoon.[1] The best crypto can be defeated by a wrench and a guy willing to hit you with it. Or more likely, by passing laws requiring all the major companies of the world to give the government access to the servers whenever they wish. Or by building backdoors into routers that allow them into networks.
The way to defeat good crypto is to go around it.
Except we are dealing with intelligent actors instead of unguided evolution. They will go after those tools as long as anyone could possibly use SSL.
On a social level, I don't find any of the arguments convincing. The positives of ensuring private communication far outweigh the negatives.
Consider the two-dimensional graph of difficulty of hostile interception of traffic vs. the value of hostile interception of traffic to the intercepting entity. ("Interception" including both attacking authenticity and privacy of the connection.) In the low/low side, you have, say, my blog posts. Deliberately public, of interest to pretty much nobody "official", unencrypted, unauthenticated HTTP. On the high/high side, well-encrypted inter-colo traffic between two computers owned by a bank, or perhaps an arms manufacturer.
10 years ago, this was a rich graph with lots of interesting nuances. Who even cares about the easy/easy cases? Of course the hard/hard cases justify encryption. And there's a lot of in between and useful cost/benefit analysis that could be done. I think the original article is written based on this mental conception of the landscape.
However, recently between technological advances and increased discovery about what is being done by governments (and remember, not just the US government, many have been caught doing things and many more are presumably getting away with things we still have not heard about) and a variety of corporations (and remember all this Superfish stuff and such predates the mandatory encryption!) has revealed that the previously-rich 2D landscape really isn't 2D after. It turns out that there is no "difficulty" dimension. It's all very easy to intercept, at scale, if not downright trivial. Governments hoover (both the vacuum and as in J. Edgar) up entire fiber optic trunks. Companies and spyware get a footprint on a machine and basically nuke all SSL flat for thousands of machines or entire major corporations at a time.
In the other dimension, it has become pretty clear that even "trivial metadata" allows far more information to be exposed about someone than any but a handful of computer scientists would have believed 10 years ago [1]. Everything has a great deal more value than we thought.
The net effect of all of this is that it collapses the entire previously-two-dimensional landscape to a nearly a single point. Everything is trivial to collect, and everything leaks a shocking amount of information, and information is power.
Consequently, regardless of the fact that both answers suck in their own way, we really only have one choice: Require encryption, or not. There's no middle ground anymore. We used to have one, but it's collapsed away.
And, frankly, acknowledging everything in the original article and with the amplification that there's probably even some stuff missing that could be added, I'm pretty sure that in the end, there's still only one reasonable choice, which is the direction we're currently headed in. Yeah, it sucks. But a root cause analysis of the problem isn't that it's the encryption's fault... it's the companies, spyware, and government that have put in so very, very much effort into collapsing this landscape. Blame them for the measures we have to take to protect everybody.
Though, even as you do so, bear in mind that in the rich, complex ecosystem of the Internet, parasites are ultimately inevitable, so it's also no use pretending that if we just fix the current companies and governments we could somehow change the problems. The only answer is that, yeah, we have to rewrite how the "laws of physics" of this ecosystem work. The only other alternative is the overproliferation of parasites and a resulting value collapse of the ecosystem to humanity as it becomes too untrustworthy to use for a variety of things we'd really like to use it for. (That is, I'm not claiming that the Internet would become entirely useless, but we'd really like to be able to use it for important things, not just Buzzfeed and cat videos.)
Unfortunately, I think you have over-simplified a complex issue to a dichotomy (encrypt everything or nothing) that is perhaps more confusing than helpful.
Encryption is a broad and diverse subject, as well as a field of expertise (not mine). I doubt parties in the debate have axioms that align here as there are so many interpretations and levels of detail to disagree about. Put more clearly I don't think any three people reading this would agree on what you mean by encryption in your post.
If you instead said "protect" "everything" / all traffic / all data/ all browsing /... , and gave some details as to the threats you are concerned about, it might strengthen the argument you are making.
EG : "protect" the "names of sites I visit" from sousveillance ... "protect" the "integrity of software packages I download" from "evilgrade" attacks ... protect "the pseudo-anonymity" of "journalists posting to social networks" from "state sponsored malware injection" ... and so on. Encryption techniques could be (are) used against all of these problems, but in different ways.
There is a lot to discuss and try to understand in these issues. Thank you for contributing positively to the discussion ( and I hope I am as well).
And no, it's not "the same thing" if China forced baidu to do it directly, or if they made CNNIC forge an SSL cert.
Most people are entitled to privacy on the machines that they own. Having to log or monitor internet traffic is the special case, and should not be the default.
> That privacy and safety stand in a big conflict was recently quite dramatically demonstrated when a pilot hid his psychological problems from his employer and intentionally caused a plane to crash.
You claim a background in psychology, you should be able to recognise this as fear mongering.
> The trust there is acquired by giving someone at a specific (private!) institution money and a copy of a passport. This system does not scale, and the number of SSL hosts is exploding.
A technological limitation in the current state of internet crypto is not a reason to abandon the concept. Everyone agrees that the concept of a CA isn't great. Someone will solve the problem eventually.
> SSL is bloody expensive compared to not doing it.
SSL is largely implemented in hardware these days. This is no longer true.
> SSL scales really badly intentionally.
I find it hard to accept that someone sat down and designed a system to not scale intentionally. Especially hard to believe when you look at the scale of SSL deployment today.
> A big cost of encryption however is lawful interception. This is not the place to discuss if governments should have the ability to intercept your internet traffic or not but in many cases they have that right.
A big cost of any societal construct is law enforcement. You can make the same argument about cars, or wigs, or plastic surgery. Most of the world strives to not limit personal freedoms out of fear.
> Unfortunately because it means that if a website hosts partially illegal shared content, then the whole website is down and not just the subsets of it which are legally problematic.
It is up to the website owners to manage this risk, with or without encryption.
> A shocking amount of Windows users run software that MITMs SSL connections to scan for viruses, malware etc. Even Ad providers (Superfish cough) started to destroy SSL traffic because it became so widespread that it was necessary. I'm firmly of the opinion that none of that would have happened if SSL traffic was less common.
MITM is the default with unsecured traffic. Again, TLS isn't perfect, but why give up?
> To give you an example of how ridiculous our love for SSL has become: PyPI. It's the Python package service. As of recently the Python package installer downloads every package via SSL. Why? There is no technical reason for this unless you want to hide from someone that you are downloading a specific Python package which seems pointless.
NO!!!!! Package managers are a huge target! What better way to sneak malicious code into someone work than through package management traffic? TLS mitigates this! This is a situation in which a trusted connection is a must.
You're right.
To the author: What, pray tell, is this magical secure place that's secure despite not being authenticated or encrypted?
Yes, the system is certainly larger (as is the internet as a whole) and slip-ups are natural. Luckily these 'slip ups' are typically simple things like certs expiring or supporting outdated cipher suites. These are just minor configuration fixes that things like Lets Encrypt aim to fix (both distribution and configuration of TLS). The thing is, even the worst 'slip ups' don't make you any more insecure than only supporting HTTP. _Any_ amount of TLS is better than none. That is a weak argument to start with.
>"SSL is bloody expensive compared to not doing it."
No it’s not. Certs are not expensive (another thing improved by Let’s Encrypt). This opinion exists from people spreading these kinds of rumors. It’s 2015 and the minor difference in processing power is negligible. If your web hosting can’t handle the difference in processing costs, you need to look for a better hosting platform.
>"Not only does that mean that you are downloading a really big certificate, but also that the SSL encryption is a bit of a lie for you as a user.”
'Really big certificate' when has this been an issue for anyone ever? A CDN providing SSL is still better than no SSL. That "lie" _still_ protects the user at their host->Local Router->ISP->CDN. This is massive value not offered via just HTTP.
>"The cost of deploying SSL should not be underestimated, and forcing SSL on people out of principle should consider that.”
The cost raised by implementing SSL vs the cost of hosting a web application is negligible. It's pennies on the dollar to ensure your users can have a safer experience using your site. Security comes at a cost, this is part of life.
>"The second method is to go to the local ISP and tell them to disable access to it. The rather is the better option in the sense that it only affects the citizens of that country and it isolates the problem. Unfortunately, SSL prevents this.”
Yep it's a real shame that it's harder to censor websites. Joe Shmoe the intended reader shouldn't use SSL just in case the government wants to blacklist his domain.
>"Even Ad providers (Superfish cough) started to destroy SSL traffic because it became so widespread that it was necessary. I'm firmly of the opinion that none of that would have happened if SSL traffic was less common. “
THE WHOLE REASON THESE AD PROVIDERS ARE BREAKING SSL IS BECAUSE THEY CAN NO LONGER WILLY NILLY READ/INJECT YOUR TRAFFIC. This exactly what Version + AT&T's "super cookie" was doing to HTTP traffic. SSL _prevents_ shit like this from happening. SSL being less common in no way equals less ads reading/injecting your content.
>"The greatest impact on user's safety would have been the development of per user encryption for public Wifi access points.”
This exists. It's called IPSec and it's a way bigger hassle than SSL, so we all agreed in the 90's that it made more sense to prioritize SSL over IPSec.
>"Instead what happened is that now every larger website has to implement SSL to protect against the only realistic attack vector which is someone surfing at Starbucks.”
This is absolutely false. I would argue the _most_ users are at risk further down the pipeline, not at Starbucks. We know for a fact that ISP's like Verizon have injected cookies into HTTP traffic leaving their networks and we know for a fact that Governments have done dragnet collections of HTTP traffic. SSL protects users at every step of their internet journey, suggesting half ass encryption is bullshit.
>"I now no longer claim I have any understanding of SSL at all.”
This is the most accurate statement he makes in the entire article.
>"Cryptography is black magic.”
Here in lies the problem. It's not. It's actually the opposite, it's open source and it's inner workings can be explained by a multitude of resources. The various features you call 'bugs' in SSL/TLS are things the security community has refined over many years. Crypto is hard, and a lot of things that seem intuitive are not. TLS exists in it's current state because it accomplishes what we want crypto to do. Saying "everyone fuck this thing I'm frustrated with" is counter productive to the whole process. ANY amount of SSL is better for the user than none.
>"but the truth is that the most popular cryptography library (OpenSSL) is an old and complex mess. Even if the library itself would be okay, there are so many ways to misuse it and it's really badly documented.”
Oh boi let's jump on the OpenSSL hate wagon. We know OpenSSL has had it's issues and there are lots of people helping to make it better (https://cryptoservices.github.io/…/2015/03/09/openssl-audit…). The fact that OpenSSL has the occasional implementation error doesn't make the SSL/TLS protocol any worse.
>"Gone are the days where you could fully understand how a web application works.“
This has gone from trying to make some kind of point to full whine fest. Yes, web applications have become complicated. So have all parts of technology. As things grow their internals become more intricate and complicated. Also gone are the days where you can fully understand the inner workings of your car engine. Doesn't mean we shouldn't use airbags.
>"As of recently the Python package installer downloads every package via SSL. Why? There is no technical reason for this unless you want to hide from someone that you are downloading a specific Python package which seems pointless."
Or you know, you don't want packages injected/swapped out with malware when you download them. If I'm downloading code I'm about to run on my system, you better be sure as hell I'm going to want to want integrity and confidentiality of said code. TLS is a standardized way of ensuring both of those things.
>"It's plenty to download the package over an untrusted connection and to then verify the checksum with one you downloaded from a secure place."
WHERE IS THIS MAGICALLY SECURE PLACE? HOW DOES ONE COMMUNICATE WITH THIS SECURE PLACE? For a guy who considers SSL to be too much effort, I'm to believe that everything he downloads is checked against checksums received via his 'secure place'