written on Tuesday, April 28, 2015
In psychology there is the term of affordances. It's the concept that an object affords different actions for someone interacting with it. Most objects in this world have a plethora of things you can do with them, many are not even intended by the designer of that object. As a crude example: a chair does not just afford sitting on it, it could also be used as a table if you sit on the floor. What I find interesting about that concept is that most of the time the actions that you can perform on an object are heavily shaped by your state of mind and environment.
An extreme example of this would be the use of bank notes. For you and me, the use of bank notes is to pay for goods and services. If you would have asked a person from the Weimar Republic however a not unlikely use of banknotes was to throw them into an oven and burn them for heat. Clearly never intended by the creator of the currency, but a very reasonable decision given that it was more expensive to buy wood than to burn the currency directly.
A similar thing applies to the enforcement of rules. For instance in order to ride a subway you need a ticket. There are two ways in which this can be policed: you have gates that prevent people without a ticket from passing onto the platform or you instead make spot checks. The engineer in me would obviously argue for the gates as it's a technical solution to a problem but upon closer inspection the gates might actually have a bunch of unintended downsides. The gate is a very binary access method: you either get through or you don't based on if you have a valid ticket. It however leaves out a perfectly reasonable affordance which is the idea of riding the train without paying for it. Now obviously one could argue that the whole point of the gate is to prevent this from happening but there are plenty of situations in which it would be entirely legitimate to ride the train without a ticket. A good example for that are emergencies. You cannot really talk to a ticket gate and make your point, it's a soul-less thing.
This is less of an issue for public transportation but it would become a bigger one for cars but cars do not (yet?) enforce laws themselves. There are plenty of people that are not legally allowed to drive a car under normal circumstances but should not be prevented from driving a car in emergency situations.
I'm not going to discuss whether digital enforcement is a good thing or not, more that when you take such a strong stance on an issue it's important to not just consider the situations in which everything goes by design.
Which leads me to the concept of encrypting everything. There is the idea that “there is no such thing as insensitive web traffic” and that the privacy of communication is absolute. For a long time this was not a very contested idea because the total number of encrypted traffic was quite a small percentage of the overall communications. Now however pretty much everyone wants to have their website encrypted which starts to alarm many actors including governments and system administrators.
Traditionally many institutions and professions and their customers had legitimate reasons for why they want encryption. That includes banks and lawyers for instance. 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. 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.
However encryption is like a ticket gate in the sense, that there is no way around it. For nobody (if it works). This has a lot consequences I think we did not yet discuss as a society.
When implemented properly, encryption is a very binary enforcement: there is no way around it. It's something that we as developers like very much because it just “makes sense” to us. But it does not come for free.
First of all encryption cannot stand on its own, it needs the concept of trust. The most common form of encryption these days is SSL where the user does not really have much of a choice in defining trust. 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. Now that everybody and their dog uses SSL on their blogs the total stress put on this system is even larger than in the past and as such slip-ups are only going to increase. It was bad enough to secure the CA system for a few hundred hosts that needed SSL, but now I have no idea how any CA in the world is supposed to verify people's identities. It's also making the encryption icon more and more meaningless and puts more and more emphasis on who and for whom things are signed.
There is another cost and that's the actual cost in CPU cycles. SSL is bloody expensive compared to not doing it. First of all there are still services which do not support SNI, so SSL is a big factor in exhausting the IPv4 address space faster than we would otherwise need. As an alternative you can fall back to many subject alternative names on your certificate. This is being executed to ludicrous degrees due to our instance on the use of SSL. The frontend that does SSL offloading for firebase.com for instance currently lists more than 580 subject alternative names. 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. The certificate in front of “firebase” is also good for “tappinass”. Sure enough, neither firebase nor that other website are holding the private keys to the cert, so they cannot impersonate each other, but their CDN provider can. Don't get me wrong, there is nothing wrong with that because they chose to outsource this to their CDN, but from a user's perspective this sort of SSL deployment does not actually guarantee that the communication is secure from their side until they hit the intended server.
SSL scales really badly intentionally. Until fairly recently there was no real way to scale SSL without handing over your private keys to a your frontend SSL machines. (Cloudflare outline their Keyless SSL method here). The cost of deploying SSL should not be underestimated, and forcing SSL on people out of principle should consider that. Not everything needs encryption. Especially in cases of big emergencies, being able to access information is crucial. The first thing Germanwings did after their horrific crash when their website was down was to replace it with a static HTML page (unencrypted) with a phone number you could call if you were affected.
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. So given a government that is allowed to rule a website illegal there are two ways to get the website offline. One involves going to the hosting provider of that website and tell them to shut it down. This can be very tricky because the website is typically hosted in another country. 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. 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. For Russians for instance github was down for more than a day because ISPs had no other change than taking the whole website down until github changed their servers to blacklist the content in question for Russian IPs.
These problems will not become less but more and it will require a proper discussion within the legal bodies of our countries. We as the tech community should not make this decision on our countries' behalf. It should be a technical reason and not a political one.
The more we put our money behind encryption the more will we put the problem of active man in the middling on our radar. When a couple of years ago you could get away with pinning SSL certificates in your Windows desktop apps, we are now far away from that. 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. From an economical perspective a few years ago nobody would have thought about building a SSL MITM proxy for these purposes. Now however you will find them everywhere. Even reputable companies like Nokia have been found intercepting SSL traffic on their mobile phones.
Worst of all is that “SSL everywhere” goes against what it should actually protect as a side effect. There are probably more misconfigured SSL systems that give users the illusion of safety than correctly set up ones. There will be the point in a year or two when the first websites that got forgotten and had SSL configured, will have their certificates expire. And then users will start to get used to clicking certificate warnings away because it's the only way to get to the website they needed.
The greatest impact on user's safety would have been the development of per user encryption for public Wifi access points. 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.
But instead we fixed the problem on every single website out there instead of one Wifi standard [1]. But administrators largely don't understand SSL. And I can't blame them. Right now the total number of people in the world that probably understand the entirety of SSL are most likely in the low hundreds. I have been dealing with SSL for years now and the more I use it, the more I have to surrender to the complexities in it. When a few years ago I would have said “I understand SSL” I now no longer claim I have any understanding of SSL at all.
This is a problem. Because SSL at this point is becoming more and more of a requirement it means there is a crucial part of my stack which I have to fully trust. And it's written in a way where it's impossible for a normal human being to understand the internals of it. Cryptography is black magic. One can argue that for as long as SSL engines are Open Source there should be plenty of eyes that ensure that our crypto code is secure, 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.
As HTTP 2 now basically is TLS only as that's the only transport that modern browsers implement. Gone are the days where you could fully understand how a web application works. We're now deep in the territory where a relatively simple text based protocol has been replaced with a multiplexed stream of octets wrapped in a TLS connection. The future is now.
| [1] | It was brought up that even if you can trust other Wifi users you cannot trust the provider of the Wifi connection. That is definitely true and defeats my point somewhat given how many Wifi access points are provided directly by unknown entities (bars themselves etc.). At this point there is definitely no way back anymore, but the rollout of Wifi could have worked similar to the rollout of home internet. At the end of the day you need to trust your ISP as well. The same rules could have been applied to Wifi providers originally. |
I don't think everyone should be forced to understand SSL and I don't think everybody should be forced to implement encryption.
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. 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. As there is no need to operate on a partial file there is no technical reason why the entire transfer would have to be SSL encrypted.
Encryption is a good thing, but I believe it needs to be applied carefully. At the same time I think we as people need to start having a serious discussion what effects the widespread deployment of cryptography can have and how we deal with it. Working encryption is pretty much an absolute: there is no way around it. This is something that our countries previously did not have to deal with.