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