"Anonymous" <nobody@remailer.paranoici.org> wrote in message
news:6045421bc866304696ca70701e0b9631@remailer.par anoici.org...
> VanguardLH wrote:
>
>> To shorten the arguments, just which CA is used to verify a signed
>> certificate?
>
> That depends on which CA is used to sign that verified certificate.
>
>
> There's a number of trusted authorities. Most (all?) browsers ship
> with
> a standard set, and the checking is done automatically unless you
> examine certificates manually. That's what the errors and warnings
> are
> suppose to prompt you to do... manually verify the certificate and
> accept it or reject it based on your own trust model rather than
> Verisign's, or Thawtes's.


So the CA hierarchy listed in the cert is used. The trusted root CA
list is not static and can be updated or modified, or the cert simply
accepted despite not including an already listed root CA without
updating the root CA list.

The point of SSL was so users would know they were using encrypted
communications but to the expected target site. Watch users. How
many go researching whether the root CA listed in the hierarchy in a
cert is a validly authorized root CA. Say you have never heard of
geoTrust but that's the root CA for a cert from the site you THINK you
visited. You find geoTrust's web site. Looks legit but how are you
going to verify it isn't another web site dedicated to the spoofing of
the MITM site that you actually ended up visiting? Remember that even
root CAs self-sign their own certs. It is required because, well,
they are the root. While some users, not all, have heard of Verisign
and would probably trust those rooted certs without further
investigation, how many that are even moderately aware of using SSL
certs would've heard of CA 1, C&W, Comodo, SIA, etc?

SSL was supposed to *enable* trust, not engender distrust in having to
do all the research to investigate the cert. For users to have the
wherewithall to do that investigation, they would already have the
expertise needed to determine whether the route they took actually
ended at the target site and the intervening hops in that route were
trustworthy.

Since you mentioned the paranoid clearing out the root CA list and
always manually intervening to select which ones to trust (provided
they have previously thoroughly investigated them), and of your boss
or other malcontent adding a root CA, then obviously malware could do
the same by adding a root CA so your browser trusts it and won't alert
when that malware redirects you from the intended target site to the
spoofed site.

All this work expected (by you) on the user to validate SSL certs goes
against the intented purpose of those certs. The normal user expects
to trust a site they think they are visiting because it gave them an
SSL cert that is *supposed* to be validated by someone other than that
site. SSL works on trusted 3rd parties. Normal users don't go
investigating WHO are those trusted 3rd parties. Yes, you could do
all the investigating or checking that you mention. Distrusting SSL
certs what not why this scheme was created.