This is a slippery slope argument that ends in you arguing that the best tested cryptosystem in common use (TLS) is also insecure. All cryptosystems have vulnerabilities; the question is, how workable is the system after those flaws are fixed.
For the record, I respect the critiques practitioners have of GPG. Unfortunately, their alternatives tend to be ad-hoc. There should be a clean, simple, GPG-like standard, perhaps based on ECC and AE cipher constructions, to replace GPG. But until that happens, in the choice between ugly and workable vs. simple and fragile, ugly and workable is the right choice for most people.
As always I think you drastically underestimate how dangerous this stuff is because you've dedicated your career to it, while normal implementors --- even crypto enthusiasts (look at Tor and SSH) --- have little of the nuance required to get it right.
I like the fundamentals of TLS more than you do; I don't think it's a bad or needlessly complex protocol (except maybe session resumption). I see that reasonable people can differ on that point. But, very importantly, TLS is also a vehicle for collecting and implementing the best known methods in cryptography. I think you tend to overlook that.
As always, my opinions are as a software security practitioner and not as a cryptographer, since I am not one.
The appearance and track record† of the code in OpenSSL does the credibility of TLS no favors, and it is totally understandable why someone who had to deal with software security for a platform that ships and depends on OpenSSL would become allergic to it.
But, two responses to that:
* First, what Joel Spolsky says about rewrites. Sometimes code is ugly for a reason. Clean rewrites of OpenSSL will inevitably introduce bugs. Introducing bugs in SSL†† implementations is perilous.
* Second, there are mature alternatives to OpenSSL. For instance, most? browsers don't use it.
† In fairness, that's because OpenSSL dates back to a time when nobody was getting C software security even close to right.
†† I use TLS and SSL interchangeably, which is a foible I should work on correcting, but the difference doesn't matter much here.
Hey, Since you mentioned TLS/SSL: I can't seem to find an answer to this question: Does my browser or system, need to contact the CA each time it encounters a new SSL Cert, or is having the root certificate enough?
Your browser does not need to contact a CA to verify the signature in an SSL certificate, but may in some cases want to contact the CA to check for revocation.
