You Heard Me: Die SSL. Die Now.

It’s time to dismantle another orthodoxy that will probably annoy a lot of people: Secure Sockets Layer or “SSL”. Let me first say that I completely understand the need for both authorization and authentication. I really do get it. However, I do not believe SSL is the right solution for either one in just about any application.

For me it comes down to these few issues: trust, track record, and design. I believe that SSL has a flawed trust model, an (extremely) checkered track record, and operates on risky design & coding principles.

Let’s first talk about trust. Ask yourself these questions. Do you tend to trust corporations more than people? Do you think, in general, big companies are just a good bunch of folks doing the right things? Are you in the 1% and believe that companies should have the same rights as humans? Do you believe most companies would stand up to the NSA? You see, personally, I do not trust corporations. That is my default position: zero trust. I trust corporations much less than a shady stranger sharpening a knife in a train station.  I also think corporate personhood should be abolished unless of course corporations can be charged criminally just like an actual human when/if they harm or kill someone, which of course, isn’t the case today.

So, do you trust Verisign, Comodo, GoDaddy and friends with information you’d traditionally have put in your safe (ie.. banking info etc..) ? I sure as hell don’t. They are just corporations. They can be bought and sold if their policies don’t suit one corporate puppet master or another. They can be easily bullied by law enforcement to issue a fake certificate. There is absolutely nothing stopping the NSA from walking in the door with a subpoena and demanding a signed cert for any domain they wish (or even a signed signing-cert). There is no way for normal citizens to know if that happened.

Now another point about “trust”. I said I don’t trust corporations and I don’t trust Verisign to pat me on the head and “insure” that the cert actually belongs to the real company. Crazy me. I don’t trust that one big corporation that got paid to say I should trust another big corporation. Here’s the point on trust: the whole model points to entities I feel I can never actually trust.

Last point on the issue of trust is this. Have you ever been “verified” by one of these commercial certificate authority? I have. I was working for a very well known and now defunct bank at the time. I payed very close attention to the steps they took to do the verification. I assert my opinion that with a fairly small budget and a small amount of social engineering, their process can be completely derailed. Yes, they make a few phone calls. This security measure is not insurmountable by any stretch of the imagination. You really think even a small group of cops or well heeled couldn’t make that happen?

So, moving along, let’s talk about SSL’s track record. Frankly, it’s tough to make any fair comparison since there aren’t any viable alternatives with any track time. However, in my opinion, there is a close relative we can compare with and that’s PGP. It’s older than SSL. It handles encryption, has a trust model, and has seen 20 years or more usage. No, it’s not a perfect apples-to-apples comparison, but it’s pretty fair nonetheless.

Now we’ve established the context for comparison is “other encryption schemes that have a tough job to do and have been doing it a very long time”. So, I’ll just say it. SSL has an extremely terrible track record.  I don’t really see anyone with credibility trying to argue against this. The best the devil’s advocate could do would probably be to point out the many band-aids that have been applied. Okay, great it’s all fixed now right? Uhh, maybe. There is credible evidence that the NSA knew about the Heartbleed bug for years before it was discovered.

It’s true that the NSA and any group of spooks would probably (okay definitely) warehouse as much zero-day as they can in secret, SSL or otherwise. OpenSSL not only has a checked past, but also, in my opinion, the software architecture almost insures that hacks will happen again and again.

Writing secure software isn’t easy, but there are some design guidelines which certainly help you. Let me give you my top three and we’ll examine each in the context of SSL.

  1. Keep it as simple as you can. Complexity is the enemy of security.
  2. Design strength beats design secrecy every time.
  3. Validate any trust you depend on for security.

How does SSL stack up? Well, right up front let’s be clear, they nail the second one. The standards and the implementations are open. So, hey, at least that’s good. However, the first point about the KISS principle is a big problem, since SSL is very complex. I’ve been coding since I was six years old. I am not a crypto expert, but I’ve also done my fair share of implementing cryptographic algorithms in C code, which is the same languages as OpenSSL. My impression of SSL’s level of complexity is somewhere between ridiculous and “to the moon, Alice!” I’m not the first person to ask “How can one ever secure something that complex?” That’s an especially troubling question when one considers the troubling criticisms of the OpenSSL project’s code quality.

What would I propose to replace SSL? Well, I’d say that for one we should completely change the trust model. It needs to be decentralized (eliminating a sweet target for state and corporate actors). In my opinion, trust should be allocated more like it works in PGP. If I trust person X, company Y, and non-profit org Z then I would allocate greater trust to any key they have all three signed.  Also, I’d allow for some greater variability in the way trust is distributed and by whom. For example, if Mozilla puts trust (and embeds it in their browser) in keys signed by the freedom-loving non-profit organizations but Microsoft puts their trust in other big nasty corporations, then it properly reflects the value-system of the users and gives greater choice in exactly who I’m trusting.

The bottom line is this: SSL sucks and must die. Some would say the only way out is through, and we should improve SSL. I disagree. It should be phased out and eventually completely discarded. As an individual you should start distrusting SSL as much as can be borne in your personal situation. I already know that appears to be a long shot these days, but I’m a geek, I don’t care. Like most geeks I’m more interested in building a technical meritocracy rather than continuing to support the corporatist status quo.

 

 

Advertisements

~ by aliver on March 3, 2016.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: