On Mon, Feb 1, 2016 at 11:16 PM, Swift Griggs <swiftgri...@gmail.com> wrote:
> 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 > Sorry to bum in, but are you aware of --> https://letsencrypt.org/ !?
