SSL makes me crazy (was Re: How to run Microsoft Internet Explorer on NetBSD?)

[Swift Griggs <swiftgriggs%gmail.com@localhost>]

On Mon, 1 Feb 2016, Hal Murray wrote:
> Without something like a chain-of-trust you don't know that your encrypted
> connection is going to the right site.

I understand it's design purpose, but I disagree with where the design 
puts that trust. When it comes down to brass-tacks, do you trust Verisign 
is doing what they say they do to verify that the cert holder is the party 
you want to have an encrypted conversation with ? My answer to that 
question is "hell no". I don't trust Verisign or any other corporation 
that would be a CA under our current system. Thus, I think the system is 
flawed.

> A man-in-the-middle can claim to be your bank.  How do you propose 
> verify that?

Well, the way I understand it, (and I'm probably wrong) but a 
man-in-the-middle would have to be able to break Diffie Hellman unless you 
can force a key update. It doesn't have much to do with the cert being 
presented.  So, I'm not sure that's true (not trying to be difficult or 
troll, just saying). However, I do take your point. Ie.. how do you verify 
the remote party's identity without a trusted 3rd party saying "Yeah, 
that's him" ?  My preferred answer would involve removing the trust from 
the dirtbag corporation and giving it to another entity. Some 
possibilities include:

* A non-profit organization with fewer motives to get in bed with the NSA
  or other corporations.

* A pool or group of trusted users who rate / rank trustability. People
  with a vested interest in getting it right and difficult to pay off or
  bribe.

* Get rid of the trust idea altogether and use some kind of
  physical or manual challenge-response. The genius would be in coming up
  with one simple enough to work, yet maintain security. Do you really
  think folks are clicking on the cert and following the chain of trust
  anyway ? Most users don't even understand it's happening (not good).

I'm not saying that the same issue (authentication of a remote party's 
identity) wouldn't come up in any system you created. However, I am saying 
that SSL has done an exceptionally poor job at...  well... it's job. It's 
over-complicated, apparently quite insecure. So insecure in fact that it's 
been nearly completely broken twice. Each time the fixes have been 
increasingly painful and disruptive enough to warrant asking the question: 
Is SSL really a good system? My experience as a user and admin would 
prompt me to answer "No way, Jose. Start again without the committee."

As an example, PGP was designed well before SSL. PGP has survived all this 
time without any exposures on the order of what we've seen with SSL (it's 
had plenty of coding issues, but no completely-busted algorithm issues). 
It's also quite a bit more simple (and that's kind of my point). 
Complexity is the enemy of security since it only provides more attack 
surface. I would submit that to "secure" is most of the time to simplify.

It's nothing personal against you, Hal, or anyone else. Hopefully, nobody 
here used to work for Netscape or other folks involved with designing SSL. 
I just think SSL was badly designed from the start and I believe the facts 
(the security issues) back me up.

-Swift