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.

Why would you need to try and paint the natural evolution of encryption
and security protocols as some sort of failure, when it's actually an
advantage?

> http://www.verisign.com/ssl/ssl-info...ded-validatio=
n-ssl-certificates.html
>=20
> 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.

You should have read your own cite.

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
errors/warnings we're dealing with here won't be impacted at all
because that's not the attack vector we're discussing. We're talking
about forging previously known certificates, not getting people to
install bogus certificates as trusted authorities.

> Have all the SSL-enabled sites that you visit always use HA certs?
> No. In fact, seeing the HA indicator in IE7 is unusual, not the
> norm. But then the HA cert simply has the *trusted* CA to include
> validated info in the cert (domain name, company name, address, city,
> state, country).

Irrelevant. MITM attacks aren't launched by holders of valid
certificates, even older ones issued under less secure trust models.
Logically they don't have to be. The question here isn't how secure a
good certificate is, it's how detectable an obviously bad certificate
is. SSL has been hardened against that since about forever. That's why
it exists essentially as an "extension" to plain vanilla encryption.

> As I recall, one of the improvements to IE7 was it alerts when an EV=20
> SSL cert is being proffered. I suspect that IE7 still relies on the=20
> "Trusted Root Certification Authorities" list. Is that list truly=20
> static that no one else after the list was created can become a root=20

Of course it's not static, nor does it need to be. It would break if it
were in fact.

> CA? And does an SSL cert only become accepted by the browser only=20
> where a root CA from this list is in their certs CA hierarchy? If

No, there's several methods for accepting certificates. That's
precisely what we're discussing here. Certificates with no Root CA
signature or unknown Root CA signatures are presented to the user for
approval just as they should be. Users can chose to accept, install, or
reject those certificates. If you're visiting a bank site through Tor
and see this warning, or visiting a bank site you've previously visited
at ALL and get this warning, you need to learn to not be a fool and
blindly accept things.

It really is just as simple as that...

> so, does alerts popup all over because the CA came from the
> "Third-Party Root Certificate Authority" list?

Of course it does. For a party to get on the "First Party" Root CA list
that's exactly the process that has to occur.

> Versus EV or HA certs, you have heard of low-assurance certs. "Some=20

Yes. They generate warnings and I choose to accept them or not based on
what I know about the certificate, and what I was doing at the time. IN
fact in my software even shiny new EV certs generate the same
warnings.

> CAs now issue low-assurance server certificates without
> authenticating the subscriber, thereby providing only two security
> services - confidentiality and integrity. Using current browser
> technology, it is very difficult for an Internet user to dinstinguis
> between higher- and lower-assurance server certificates"=20
> (http://www.us.kpmg.com/RutUS_prod/Do...2/DC80502.pdf). So,=20
> since 2002 when this report was issued, have these low-assurance CAs=20
> been wiped from the face of the Earth?

No need to be. You just don't trust them as you would a normal
Authority.=20

> Seems a bit odd that cybersoft.com would patent=20
> (http://www.freepatentsonline.com/20020129237.html) a process for SSL=20
> interception that you say is impossible; see=20

<chuckle>

You obviously don't understand what you're reading at all. There's
nothing about 20020129237 that says anything about intercepting SSL
encrypted passwords or anything else. Nada. It's a patent on certain
technology that identifies SSL traffic itself and segregates it, not
subverts it (although if the underlying encryption isn't strong that
could happen after a few million years of cryptanalysis).

> http://www.cybersoft.com/products/nticry.shtml. Since this was back=20
> in 2000, seems a bit odd that you don't know about SSL interception.=20

It doesn't seem odd at all that you'd confuse interception of traffic
with actually decrypting an SSL data stream, after seeing you
misrepresent things you blindly cut and paste from sources you don't
understand. Wild ass grasping at straws and guessing often do lead to
that sort of confusion.

> The company still exists. I doubt they would survive if they sold a=20
> product that didn't deliver [some of] its promises.

They're not promising anything like what you have fooled yourself into
believing they promised. You must have been oblivious to the fact that
not all SSL encrypted traffic is easily distinguishable from other
encrypted traffic, and being as secure and flexable as it is SSL often
gets abused in the corporate world as a way to bypass company imposed
limitations and restrictions.

There's much value in simply identifying SSL traffic itself and
determining it's origins without every even trying to decipher its
contents. A whole cottage industry revolves around this cat and mouse
game in fact. You've just stumbled across that industry, and mistaken
it for something it's not.

> A bit odd that NATO would waste their time describing MITM for SSL=20
> interception=20
> (http://ftp.rta.nato.int/public//PubF...ST-041/MP-IST=
-041-19.pdf)=20
> if, according to you, it were impossible.
>=20

Not one person said it was impossible, lair. In fact the specific
conditions that make it possible have already been offered for your
perusal if you had known what you're looking at. They won't exist at
Tor nodes because they can't. Tor nodes don't have direct control over
your machine. The only other options is "fooling" users into accepting
bogus certificates in spite of all the warnings.

That's what we're discussing here and now.

Ironically amusing as it is, even your NATO cite recognizes the fact
that the sort of mucking around you're claiming is possible generates
warnings in unmolested clients...

"The proxy masquerades the server=E2=80=99s certificate and presents it to =
the
client. Depending on the application service requested the client would
receive a warning concerning the server=E2=80=99s certificate. This can be
eliminated by adding the proxy=E2=80=99s certificate to the client=E2=80=99=
s trusted
Certificate Authority (CA) list."

You really SHOULD learn to read your own cites, don't you think?

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.

Why this looks like something "special" to you can only be guessed at,
and mine would be a combination of willful ignorance and laziness. You
desperately want to believe something that's not true, and you seem to
lack the motivation to even casualy browse through the stuff you're
quoting.

I see that as rather pathetic actually. =20