full-disclosure - Five Ways to Screw Up SSL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e024ccca0605220902u7e23adcdx77cc96aa4e565f98@mail.gmail.com>
Date: Mon May 22 17:02:35 2006
From: dudevanwinkle at gmail.com (Dude VanWinkle)
Subject: Five Ways to Screw Up SSL

On 5/22/06, Michael Holstein <michael.holstein@...ohio.edu> wrote:
> > I was referring to the CA that signs it. It was implied that
> > freessl.com, who gives out trial certificates, is an unreliable CA. I
> > do not understand why their certs would be any less valid than
> > anothers.
>
> Not less valid, less trusted. SSL is a heirarchical "web of trust".
>
> > As long as the website listed on the cert is the website you are
> > visiting, why should it matter who issued the cert?
>
> Because how can I know that a certificate issued to "A" is really entity
> "A", unless I trust a central authority to do the homework.
>
> Phishing attacks love this trick. If anybody could get a cert for
> "www.chase.com" that was valid to the browser, then anybody that could
> do DNS foo to the client could spoof the real Chase.


DNS foo to the client, how easy is that? Would you have to get the
upstream DNS server to  cache your bogus entry?

-JP<the confused>