But yeah, it would be nice to use this tech rather than reinventing the wheel. The underlying implementation is sound.
1- simpler implementation — one that is easier for users to understand, and includes client certs by default
2- one with a re-engineered cryptographic implementation, one less likely to have the kind of numerous security flaws that have been uncovered in SSL/TLS over the years
SSL was originally meant to serve two purposes:
1- encrypt communication
2- verify, through a trusted 3rd party, that the remote service you're contacting is actually who it says it is
Most laymen, and many technologists, do not know that #2 even exists. Worse, this authentication portion has been all but destroyed by liberal certificate authorities like GoDaddy. From my experience, anyone can get a certificate for a domain without any kind of check to see if you have the right to use that domain. So, in theory, you could register "amaz0n.com" with GoDaddy, get a cert for it, and start using it, without any kind of background check. In the early days (when Verisign was the only CA in town), a business had to supply a Dunn & Bradstreet number and be subject to other background checking before being issued a CA-signed cert. If that sounds heavy-handed, it shouldn't: Verisign was supposed to have the users' backs. If you tried to get a cert for Amaz0n.com, it would have been rejected unless you could prove you actually are Amazon.com.
I think that kind of authentication has a real place on the modern Internet.
edit: formatting
I'm not sure what you're suggesting. A nicer UI would definitely be a good idea, but you can do that without changing the underlying crypto implementation.
>2- one with a re-engineered cryptographic implementation, one less likely to have the kind of numerous security flaws that have been uncovered in SSL/TLS over the years
That's not how you get secure cryptography. You need not just a secure algorithm but a secure implementation, one resistant to timing attacks, compression attacks, and all sorts of nonobvious things. OpenSSL is far from developer-friendly, but the vulnerabilities have been hammered out over those 20 years, and there is a body of knowledge on how to use it securely. A new implementation would have to go through that all over again.
>From my experience, anyone can get a certificate for a domain without any kind of check to see if you have the right to use that domain. So, in theory, you could register "amaz0n.com" with GoDaddy, get a cert for it, and start using it, without any kind of background check. In the early days (when Verisign was the only CA in town), a business had to supply a Dunn & Bradstreet number and be subject to other background checking before being issued a CA-signed cert. If that sounds heavy-handed, it shouldn't: Verisign was supposed to have the users' backs. If you tried to get a cert for Amaz0n.com, it would have been rejected unless you could prove you actually are Amazon.com.
True enough, but fixing that doesn't require any changes to SSL itself - you just have to curate the list of root certificates the browser trusts more carefully.
Now with PRISM and total global surveillance becoming a sad reality, we could certainly do with more decentralized approaches and (ideally) overcoming the "authority" paradigm (but this will likely remain a dream).
Not that there aren't other problems at times with SSL, especially depending on how you use it, but your criticism may be more limited than you realize.