full-disclosure - HTTP AUTH BASIC monowall

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 for Android: free password hash cracker in your pocket

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

Message-ID: <441AD4CB.4070902@sdf.lonestar.org>
Date: Fri Mar 17 15:25:57 2006
From: bkfsec at sdf.lonestar.org (bkfsec)
Subject: HTTP AUTH BASIC monowall

Tim wrote:

>
>
>I think you are lumping several types of trust into one.  (Though please
>correct me if I'm wrong.)
>  
>
My discussion was meant solely to discuss the "web of trust" as it 
relates to SSL Cert Authorities, which was the scope of my message.  I 
wouldn't refer to the PGP "web of trust" as having the same issues 
because, as you accurately point out, the two methods of trust are 
different.

And, again, as you accurately point out, the reason why SSL cert trust 
is flawed is the distinction of "forced trust"... meaning that in the 
SSL cert game, you have to trust the CAs.... whereas in PGP trust you're 
actually trusting someone you know and deciding on trust in a more 
granular fashion.

>
>
>So, I argue the two-parameter, trust-degrading system OpenPGP uses fails
>much more gracefully than SSL's PKI.  I can ultimately trust that your
>key is really yours, but I don't have to trust that you'll properly
>verify others' keys.  As we follow the transitive chain of trust, the
>trust decreases.
>  
>
And I would agree with you completely.

>People really do operate in webs like this.  Obviously verifying
>identities yourself is safer, but if your buddy tells you someone is
>legit, you will likely trust that at least a little (and with PGP, you
>can trust that referral as much or little as you like, without telling
>your buddy how much you trust him).
>  
>
Yes, they do... it's where the whole thing becomes automated and 
"submerged" (as it is with SSL) that things become flawed.  Some people 
tend to ratchet the web of trust onto SSL in an attempt to show that it 
is verifiable ("the CAs would NEVER falsely identify an organization 
because then you'd NEVER trust them", etc...) and that's where the 
mistake is made.

There's some truth to the statement that CAs want to avoid falsely 
certifying organizations... but the problem is that people assume that 
they're detectives at verifying business practice and that is not the 
case.  It's just not in the scope of what they do.  They're in the 
business of verifying identity and providing certificates for 
cryptographic usage... no more, no less. :)

>Please tell me how this is worse than all-or-nothing CA trust in SSL.
>(Besides issues with usability.)
>
>  
>
It's not at all worse... it's just that people apply the wrong level of 
consideration to certificates sometimes and this ends with the result of 
giving people a false sense of security when they see that little 
padlock at the bottom of their screen.

Don't get me wrong, there's obvious value in the certificate system.  
Because I waxed philosophical about webs of trust doesn't mean I want to 
throw the baby out with the bathwater.  :)

             -bkfsec