Monday, February 25, 2013

Need a good book to read? Read this technical novel!

If you are in the mood for a not-so-boring "technical novel" (there apparently is now such a thing), may I recommend reading this lovely 730 page book:

Engineering Security by Peter "Long-Winded" Gutmann

Reading it does require a level of technical expertise and understanding of how SSL/TLS, SSH, IPSec and a number of rather boring protocols work to truly appreciate what he has to say. For those who don't have the time to read 730 pages, I'm going to summarize:

Security, or at least the average programmer's understanding of it, is...severely lacking. We've had two decades to figure out how to not screw up security and, yet, we still find new, extraordinarily stupid ways to do so. The real problems are a lack of accountability in software development and that anyone can own a computing device without any training whatsoever.

The book then proceeds to attempt to describe fixes for the problems, but I'd wager that around page 50 or so, most readers will get bored and move on, never getting to the author's recommendations. "Since I'm not accountable as a software developer, reading this is a waste of my time. I also feel mildly insulted somehow." That will be the general consensus of the technically-literate (especially programmers).

Personally, I got to about page 40. In general, having been steeped in the security realm for as long as I have, I see where the book is going so I'm not particularly interested in finishing despite being promised moments of humor from the person who recommended reading it (haven't found anything funny yet) but it certainly isn't as dry as I was expecting (it isn't a technical manual). The main problem with this book is that it is too long and not particularly sure of who the audience is. A good author addresses the target audience directly in a manner that makes sense. Not having a target audience causes meandering.

I do recommend reading at least the first 40-ish pages. The only thing I got out of this so far is the phrase "DV certificates". Since I don't do acronyms, I had to look that up on Google and, of course, ran into SSL cert vendors with posts on their blogs saying how they don't do "Domain Validated" certs and how they aren't any better than self-signed (that last part is a bald-faced lie). The real reason is that they would have to offer DV certs for free, which would eliminate a lucrative source of income that is based on a lie. Reading the novel to this point, I've come to the singular conclusion that the DV SSL certificates from StartCom StartSSL (only vendor I know of providing them) are more secure than anything you might purchase. The specified argument against Comodo has pretty significant implications against any type of paid-for SSL cert (i.e. nearly all CAs have similar issues that should raise significant questions of trust). Domain Validated certs are impossible to spoof for a specific domain if the CA does it right. CAs that charge money for a SSL cert are interested in the money, not the validation. While StartCom's policies are too strict and their SSL signing interface rather clunky, the most important aspect of a SSL cert is the trusted path to the root, which they maintain through specific procedures that they stick to. It is also a lie that DV certs are less secure than any other type of certificate. The underlying communication protocol is what matters. If it goes over SSL/TLS and the certificate is within its validation period and that certificate traces to a valid trusted root and the certificate is validated for the specified domain being connected to, then the communication that follows can be trusted as unmodified and unheard by a third-party up to the signing level of the certificate (e.g. SHA256 fingerprinting and a 4096 bit or greater public key as of 2013 is pretty darn secure). Everything else, including organization validation, is icing on the cake. (Firefox lies when it says that a cert that is only DV validated can be eavesdropped upon! Humans are the greatest source of error whereas DV certs can be issued without any human intervention.) The only time the icing matters is if you need to validate something other than a public domain (e.g. a private domain such as an internal network). If you need that, you maintain your own CA, your own trusted root, and your own certificates. For everything else, DV certs are sufficient. If someone obtains a valid SSL/TLS certificate for one of my public domains, how are they going to spoof that owner-locked domain? They would have to spoof DNS on the same subnet as the attack. That's hard enough to do in the first place and too isolated for me to care. Plus, the FBI has SSL cert appliances, which means they have obtained the trusted root certificate private keys for at least one major CA and can generate SSL certs for any domain they so choose and probably can generate EV certs as well (i.e. browser-based PKI, including green bar, is fundamentally broken). If a hacker manages to modify my official DNS entries at the source, then I'm going to notice really fast because only an idiot doesn't have monitoring software in place to watch for network changes (but an attacker is more likely to steal my domain first rather than switch DNS, which I'm for sure going to notice). The takeaway is that DV certs are more secure because CAs will sign organization validated certs for domains that the organization doesn't even own, which is less secure than total automation, which at least guarantees someone has access to the domain itself who is requesting the cert (probably the authorized party). The lesson we should learn from this is that we need to scrap everything but DV certs and reboot every public CA from the ground-up. If you need something more secure, make your own CA and have users install the root cert if they trust you - or just do it yourself since you probably own the computer the user wants to access the resource from.

Other thoughts: Longest paragraph ever.

No comments:

Post a Comment