Slashdot Mirror
Making PKI Work
Vegigami writes: "The U.S. General Accounting Office (GAO) has released this 80+ page PDF report on Information Security: Advances and Remaining Challenges to Adoption of Public Key Infrastructure Technology. Some good straight talk about what its going to take to get PKI to really work on a large scale. The obstacles seem formidable."
I find it heartening to see, on page 80, that the PDF is printed on recycled paper...
--
I think half the reason you can't do encrypted e-mail (or encrypted anything else, for that matter) is that most "PKI"s are neither public, nor infrastructure.
Company A goes and spends a kagillion dollars on an Entrust solution and gets an overgrown LDAP server that only knows about its own keys. Who cares that Company B spent half a kagillion dollars on a Versign solution? Neither can communicate with the other, because they can't look up each other's public keys.
Everybody wants to push this stuff down to the end user, too. They want every Outlook, Netscape, etc, to have its own list of LDAP servers to query. LDAP is the kitchen sink of directories. It's totally overkill for the problem of "gimme a key!" Plus, why should every application writer have to maintain their own list of LDAP servers, write their own query mechanism, etc.
DNS has long had support for the essential key-distribution features. The resolver library ships on every single OS that can use the internet. The query structure and mechanism is known. The hierarchy rearranges itself flexibly. Delegation is easily achieved, both by InterNIC registration and KX records. If people would give up LDAP and move to something more flexible for key lookup, PKI's goal of being "public" and being "infrastructure" would be more attainable on a large scale.
Paco is an employee of Tovaris, Inc. who speaks his own mind and not theirs.
About 80% of the people in this field seem utterly clueless about security. And this is being charitable. Most developers I have talked to these days are astounding in their lack of knowledge about real security attacks. Some even whine about why things don't work when they try to loosen security. This is utterly mind-boggling!
Java doesn't cut it here. The simple reason why is due to the overhead in loading in all the security classes. There was an excellent and simple example of some JSSE code in Dr. Dobbs recently; try downloading and running the code with TSL turned on - you'll see what I mean.
Another sad reason is the lack of algorithm support in Java. Yes, it's a start; and yes, it has a LONG way to go to get up to speed with OpenSSL. I daresay it will take years to develop the same breadth and confidence as OpenSSL.
OpenSSL is the best thing out there, and it needs a serious rewrite. I don't wish to belittle the excellent work done by Eric, Ben, Ralph and many others. But let's be honest here. OpenSSL has evolved into a mishmash, and it's time to rewrite it. Of course, by the time that's done, then Java will probably have come up to speed. I doubt it will be as fast, but I'd like to be optimistic here.
The biggest security flaw in ebiz is conveniently overlooked. People seem to be litterly sticking their heads in the sand on this one. It was reported last summer on bugtraq , and yet, almost no one seems to be paying attention to it.
Many people are trying to implement security models using Java applets. This is a fatal mistake, and will leave you or your clients rather vulnerable.
The simple reason why is because if your browser gets hit with a rogue applet, you are screwed. Not only can a reverse-tunnel to a hostile site be set up, but under some circumstances, the applet can initiate a secure connection to (say) your bank, using your password from the cache!!!
You get NO warning that this has happened; and the bank thinks that it really was from you. Good luck disproving this one in court. And most firewalls won't protect you.
The potential for serious damage here has not been fully exploited, thank God. But it's only a matter of time. Especially when people highjack a sites' DNS server, and point it to a hostile look-alike. Ugh.
What's also scary is the number of sites using pure Java or Javascript. Javascript is even worse, and IMHO can't be fixed security-wise without a complete rewrite.
But the bottom-line is that Java and Javascript leave you vulnerable; and it's only a matter of time before this hits the fan. Sun has as big an exposure as MS (with IE and Outlook virii) - it's only a matter of time before this is exposed.
Just turn off Java. This might protect you (though I suspect that actually even this may not help).
But the products which are coming out using applets for security is of real concern. In fact, it might well seriously hinder the new move to application servers, depending on how things are done.
This is frighteningly fertile ground for exploits.
So, yes, the bottom line is that PKI has a VERY long way to go. This is surprising given that people have been working on it for eons. IMHO, the lack of progress here is the best example of how the U.S. export restrictions have hurt business.
And, if you really want to put this in perspective, take a look at InfoSec's recent study, they noted that only 2/3 of all ebiz transactions are done with encryption (and this is an *improvement*!?!).