A lot of resistance comes from the fact that too many people don't like to do work or do the job right the first time. I'll admit -- a PKI requires work and is not easy. I'd even go as far to say that it is a painful experience. Well, so is getting your authentication credentials or your identity stolen.
This all begs the question, "Why SSL?". I'm glad you asked.
By using SSL, a system is able to provide:
- Authentication
- Encryption
Authentication allows you, the client, to verify that the server you are speaking to is, in fact, the server you expect to be speaking with. In more complex setups, it also allows you, the client, to prove your identity to the server.
Encryption allows the two endpoints in the conversation to ensure that the data transfered cannot be tampered with and that it cannot be read by unauthorized eyes.
Unfortunately, these two points alone are typically not enough to justify SSL to some people. So, practically speaking, where are the risks? As I see it, the risks are almost entirely network related.
For sake of discussion, we'll ignore the fact that the two endpoints in a conversation could be compromised and, regardless of SSL, the conversation could be compromised. We'll also ignore the fact that it is entirely possible that they way in which the encryption system was designed or implemented could be flawed, thereby exposing any supposedly encrypted communications.
A compromise of any of the following could result in unencrypted communications between two endpoints to be exposed.
En-route Network Equipment
I am sure there is some survey somewhere that measures or attempts to approximate the average number of network hops the average human's network traffic passes through prior to it reaching its destination, but I say that 10 is a good guess. We've all heard the phrase "cut out the middle man", but when it comes to your personal data the saying could never be more true. When I connect to my bank, my traffic hops through at least 11 network devices that I do not control, all of which are owned and operated by at least 3 major, multi-million/billion dollar providers:
$ traceroute -q 1 -n -A -w 1 nomansbank.com traceroute to nomansbank.com (a.b.c.d), 30 hops max, 40 byte packets 1 192.168.0.1 [AS28513] 1.455 ms 2 208.127.144.1 [AS19817] 25.108 ms 3 66.51.203.33 [AS19817] 26.738 ms 4 63.209.70.133 [AS3356] 27.904 ms 5 4.68.102.30 [AS3356] 39.692 ms 6 4.69.137.33 [AS3356] 31.824 ms 7 4.69.132.82 [AS3356] 104.852 ms 8 4.69.134.186 [AS3356] 98.615 ms 9 4.68.17.6 [AS3356] 100.826 ms 10 4.68.63.2 [AS3356] 102.223 ms 11 216.140.9.9 [AS3356] 105.364 ms 12 65.88.122.190 [AS3356] 110.851 ms 13 *
As much as I'd like to be able to say that none of these hosts or providers could ever be compromised, they can be compromised and have been in the past. All it takes is one and your bank data, juicy IM conversations or scathing gmail messages are exposed.
At the same time, the world of security is not always about the bad guys out to get your data. In this day and age, it is safe to assume that every bit of data you transmit from your computer is monitored in some way. This monitoring could be fairly innocent in the form performance monitoring or debugging by a network provider along the path of your packets. Or, it could be a true "Big Brother" type situation where a government is monitoring, logging and analyzing all traffic. You will be sorely mistaken if you trust that your data captured during monitoring will never suffer any ill will.
Just as you should fully trust that if you hurl stacks of money into the streets that people will do whatever it takes to get that money, you should also assume that when you send personal data unencrypted over the Internet people will make every effort to intercept it. That is, of course, if they don't already have it.
DNS
The first thing that happens when you attempt to connect to a system by name is that your DNS resolver must do a forward DNS lookup to resolve that name to an internet protocol (IP) address. At that point, a connection is established to the IP address identified in the previous step, and eventually data is transfered back and forth and life is good.
Or not.
Since DNS is (generally) UDP based, forging responses is fairly easy. All you have to know is the source port of the original request and with darn near any programming language you could forge enough fake traffic to eventually accomplish your goal. Fortunately, the designers of DNS implemented a 16-bit transaction ID in order to allow resolvers to match responses with requests. While not cryptographically secure, these 16 bits can make brute force approaches a real bear.
Or not.
Unfortunately, far too many implementations of transaction IDs within DNS resolvers are not only random, but predictable in numerous implementations.
The situation is totally shot to hell if an attacker has the ability to intercept traffic between a DNS client and server. At that point, a transacation id -- cryptographically secure or otherwise -- does not matter. Intercept the original request and forge a response back to the client in the attacker's favor before the legitimate DNS server does and then the sky is the limit.
Dug Song's venerable dnsspoof (part of dsniff) has been exploiting this "flaw" for nearly 10 years now. I wrote an improved knock-off version a while back called dns_spoof that picks up where Dug's tool left off. On a system that has ability to intercept (legitimately or otherwise) DNS requests from your target:
dns_spoof -p "A . A 1.2.3.4"
This will intercept all requests that are A record requests for any name and will return an A record of 1.2.3.4. On the victim system which now attempts to connect to their bank:
$ telnet nomansbank.com 80 Trying 1.2.3.4...
Now if you were in control of 1.2.3.4, you are free to intercept and molest the traffic that the victim believes to be going to nomansbank.com.
ARP
In the previous section, I said that one of the first steps in a connection to host by name is for DNS to resolve that name. This is true, but a bit misleading. The true next step is for the DNS client to arrange for its DNS request to be delivered to the DNS server. In the case where the DNS client and server are on the same broadcast domain, a simple ARP (address resolution protocol) request will return the layer 2 address of the layer 3 address belonging to the requested name server. If the DNS client and server do not have direct layer 2 connectivity, the DNS request must be properly routed. In this case, the ARP request is made by the DNS client for the appropriate next hop router.
If you've done any serious network security work, or this article is tickling the right brain cells, hopefully you already see where this is going. Just as DNS requests can be intercepted and molested, so can ARP requests, except in the case of ARP the situation is much worse. Or better, depending on whose side you are on. If an attacker can forge and ARP response that includes a layer 3 address that they control before the legitimate system(s) respond, then similar attacks to those described above can continue.
So. Again. Why SSL?
Take the super paranoid approach and always assume that the attacks on your unencrypted data are always under way. Protect your communications with SSL and the risks are largely eliminated. This is what other articles or security practitioners will preach. Unfortunately, it is only partially true.
The title of this entry should really be "Why proper SSL?". SSL is nearly useless if the PKI upon which it is built is not properly implemented. I'd actually argue that SSL that is deployed as part of a sloppy PKI implementation is less secure than not implementing SSL at all. Why, you ask? If you train your users to not send sensitive data over unencrypted channels, they become lulled into a false sense of security when they encounter a connection secured with SSL. They then inherently trust SSL connections and send sensitive data over said connection and have little basis on which to judge whether or not that SSL connection is secure aside from the little lock in their browser or the fact that the "S" in "SSL" stands for "Secure".
The power and security of a PKI comes largely from the trusted third party that is the CA (certificate authority). The lack of a CA or lack of a properly implemented CA is exactly what can jack up what would otherwise be a secure and properly implemented PKI.
A PKI that is implemented without a CA isn't really a PKI at all. This results in what is typically called "self signed certificates". This is the security equivalent of a kid getting a report card and, instead of bringing it home to have his parents sign it, simply putting his own signature on it. As I said before, much of the security in a PKI comes from the CA, but how is that? When an X.509 certificate is issued, it is issued by the CA on behalf of the particular participant in the PKI that wants to be uniquely and securely identified. In plain terms, the certificate issued by the CA says that anyone who can display this certificate is in fact who they claim to be. The catch is that merely possessing the certificate is not enough. You must also possess the private key that was used when requesting the certificate in the first place.
OK, so great. You've got an SSL certificate that was given to you by a CA. All is well, right? Sadly, no. The problem all comes back to that little word we call trust. The lack of a trusted CA comes in two forms.
The simplest is that if the CA is not trusted, there is no telling how their ship is run. They could be issuing certificates to any old bloke that wants one without actually validating their identity. They could be issuing certificates that lack some of the most basic X.509 attributes that can tarnish any PKI.
The worst thing that can happen as a result of an improperly implemented PKI is not a technological one, but people problem. We've all seen a browser message warning that a certificate is signed by a CA that we don't trust, or the host that we are connecting to does not match the hostname that the certificate claims to be for. The result is that users get into this habit of blatantly clicking "OK" when their browser warns them of this security issue.
Oh, it gets worse. Recall all those attacks regarding traffic interception and deception using DNS and ARP tricks when trying to intercept unencrypted data? Once your users get into the habit of blindly clicking through browser warnings, these attacks are perfectly valid ways of intercepting data encrypted using an insecure PKI. ARP spoof or forge DNS requests into getting a victim to connect to a host you control, and then the fact that you throw up an invalid or otherwise insecure X.509 certificate is not a problem because these users will blindly click through most any warning message and then their data is yours.
Game. Over.
Posts
