Anonymous Sender wrote:

> VanguardLH wrote:
>
> It might help the flow of things if you'd quote some of what you're
> replying to....
>
>
> > Please explain why, if the old SSL model was so secure and could not=20
> > be corrupted by MITM attacks or spoofing, that now Verisign offers=20
> > "high assurance" or "extended verification" certs. If the previous=20
> > and still existing SSL model was/is so great, gee, now why would
> > there be a need to improve it.
>
> Technology advances. Leaps forward are made in various areas and the
> people who are involved in projects which secure data both respond
> proactively, and re-actively. Most often proactively, and/or in
> response to perceived demands regardless of how valid they are. EV is
> an example of the latter. They even market it as such quite plainly.

Indeed. It's essentially a marketing gimmick response to users who
really don't know what to believe in not feeling "safe" doing their
shopping on line. Mostly because of the same misinterpretation and
misrepresentation of fact that we're seeing right here in this group.

It's a story as old as the net. Rumors get started, people demand
solutions to problems that don't really exist, the industry responds,
and people end up being less safe because they're relying on flash and
fluff rather than common sense and applied IQ.

People like Vanguard and Andrew are part of the problem, not the
solution.

> > Are all current sites that implement SSL certs required to migrate to=20
> > EV certs? No, but they can *optionally* upgrade. Will users know
> > the difference? No. They see the padlock in the browser for the
> > cert proffered by an SSL-enabled site but whose CA is not a root CA.
>
> EV certs are easily distinguishable from "standard" certs.

Indeed again. IE7 supports them and distinguishes then visually, as does
Firefox 3 (and 2 with the proper plugin). as well as Opera. Not sure
about "lesser" browsers, or how console based browsers like Lynx
support or handle them, but the general pattern is to turn things green
and display the EV trusted certificate owners identification.

> In any case, this has little or nothing at all to do with MITM attacks.
> EV certifications add trust to the CA signature, not the certificate
> itself in this trusted/untrusted context. The problems and

Indeed again. There's nothign about EV certificates that make them
significantly more suitable for detecting completely bogus certificates
swapped for good ones. SSL has had this ability built into it for about
as long as I can remember.

<snipped for brevity>

> If someone owns your box they can do anything they damned well please
> with it. That includes installing their own cert as a Trusted CA and/or
> configuring away any warnings and dialogs they please.

That's the skinny. And by owning your box you have to include owning the
operator. If they can fool you into accepting bogus certs then they
have you too.

Fortunately it's child's play to avoid being fooled as long as you have
some basic and ACCURATE information.