Gov't coerced Certs thwart SSL/TLS
 

Researchers at Indiana University opine that CA-issuers may be co-opted and
coerced to improperly issue SSL certificates.

Has SSL become pointless? Researchers suspect state-sponsored CA forgery
http://www.betanews.com/article/Has-...s-Researchers-
suspect-statesponsored-CA-forgery/1269551694

Original paper here:

Certified Lies: Detecting and Defeating Government
Interception Attacks Against SSL
http://files.cloudprivacy.net/ssl-mitm.pdf

Regards,

Re: Gov't coerced Certs thwart SSL/TLS
 

>Researchers at Indiana University opine that CA-issuers may be co-opted and
>coerced to improperly issue SSL certificates.

>Has SSL become pointless? Researchers suspect state-sponsored CA forgery
>http://www.betanews.com/article/Has-...s-Researchers-
>suspect-statesponsored-CA-forgery/1269551694

>Original paper here:

>Certified Lies: Detecting and Defeating Government
>Interception Attacks Against SSL
>http://files.cloudprivacy.net/ssl-mitm.pdf

This was very interesting. And I don't doubt that the government
might be pressuring the cert companies to issue bogus certs.

I loved the statement:
'Other contributors agreed there may not be due cause to withdraw
CNNIC (China cert authority) from Firefox's root store, until
specific evidence of claims such as this one emerges.'

Do they actually think that dead men are going to be able to
make claims?

Re: Gov't coerced Certs thwart SSL/TLS
 

It would seem that the best protection against governmemt intrusion
into certs is for companies to self issue their own certs and carry
them to the cert companies.


Il mittente di questo messaggio|The sender address of this
non corrisponde ad un utente |message is not related to a real
reale ma all'indirizzo fittizio|person but to a fake address of an
di un sistema anonimizzatore |anonymous system
Per maggiori informazioni |For more info
https://www.mixmaster.it

Re: Gov't coerced Certs thwart SSL/TLS
 

In article <6ac954b277b15e7c31527e8553ac209d@mixmaster.it>,
nobody@mixmaster.it says...
> It would seem that the best protection against governmemt intrusion
> into certs is for companies to self issue their own certs and carry
> them to the cert companies.
>
>
I think the problem with that is that anyone can generate a certificate
for any company, i.e. anyone could certainly generate a certificate that
indicated they were the Bank of America. What makes it impossible to
use is that a check with a Certificate Authority such as VeriSign would
indicate it was not genuine. If Bank of America generated one of their
own they could certainly give it to VeriSign to distribute but they
would still be dependent on VeriSign to indicate that it was genuine and
actually came from Bank of America before it could be used. Given that,
what would stop a third party from generating a certificate indicating
that they also were Bank of America and forcing VeriSign under duress to
indicate that this alternate certificate was genuine as well?

The bottom line is that you have to trust the source of the certificate
regardless of who generates it. If that trust is gone the certificate
is pretty much useless.

Unfortunately I do not see a solution. As long as there are
organizations with more clout or means of persuasion than the authority
vouching for the authenticity of the certificate, the certificate is
suspect.

At least that is the way I see it but I am not an expert. If someone
sees an error in my thinking, I am willing to listen.

Re: Gov't coerced Certs thwart SSL/TLS
 

George Orwell <nobody@mixmaster.it> wrote in
news:6ac954b277b15e7c31527e8553ac209d@mixmaster.it :

> It would seem that the best protection against governmemt intrusion
> into certs is for companies to self issue their own certs and carry
> them to the cert companies.


I will answer you and afterwards I'll explain in a postscript a different
CA attack from the one in the articles that is very serious and very easy
to do!


As matters currently stand companies DO *generate* their own certs (or
call it a pre-cert if you will). The CAs (e.g., Verisign) merely
*digitally sign* those pre-certs (using as much or as little due
diligence as they see fit to confirm their provenance) thereby converting
them to "certified" certificates (to make a weak joke).

Alternatively, a company (or other entity, such as you or me) can perform
*both* the generation and certifying roles - this results in a "self-
signed" certificate. Such a certificate effectively says: "I hereby
certify that I am me."

Fortunately, there is no way to forge/spoof the company public/private
key part of either a CA-signed or self-signed certificate (without
breaching the original company's internal security); that part of the
protocol is rock-solid. The public/private keypair guarantees that an
entity, whether counterfeit or genuine, can at least be confirmed to be
the *same* entity at some later time. Any spoofing of an entity (even
one signed by a corrupt cert authority) must use different company keys
on the cert (that is, if the corrupt party expects to be able to decrypt
the SSL signon).

Surprisingly, the self-signed certificate is the *best* type of
certificate *from a security standpoint* precisely because it does appear
so weak (a paradox, a paradox, a most ingenious paradox...). All
browsers will immediately flag such a "cert" for you rather than "rubber
stamp" it as OK and such a cert obviously requires further scrutiny if
the site involves any degree of trust in your dealings with it (which,
however, *isn't* always the case).

So, how do you check out whether a self-signed cert is valid? There are
a number of methods but the short version is: By contacting the company
(or some other entity that is both trustworthy and knowledgable about the
company's cert) to confirm the validity of the company's cert.

However, as they say in the late night TV ads, "But wait! There's more!"
You should contact the company (or other trustworthy entity) either
directly (i.e., face-to-face) or at least using an "out-of-band"
communication path (i.e., not the same as the initial one where you first
encountered the cert). But in this case you could have simply got the
cert here originally and not just as confirmation after getting it by a
less trustworthy path.

Incidentally, the problem with using some "other trustworthy entity"
instead of the company itself is that that is exactly what the CA tried
to be (and failed). Except in special circumstances, why would you expect
some other entity performing a similar role (e.g., the repository in the
"perspectives" add-on) to be any better?

So, while the self-signed cert is the *best* from a security standpoint,
it *stinks* from a usability standpoint. Besides being a PITA for you to
do this, few companies, except maybe some banks, are set up to handle it
(e.g., a telephone inquiry). Moreover, the website traffic would dwindle
to near nothing because most users would be neither capable nor willing
to go to such trouble.

Probably the best from a compromise viewpoint for companies with at least
moderately skilled, privacy-conscious users (i.e, the 7 of us :-) is to
have some automated out-of-band way of checking its cert (by telephone,
or, less desirably, by email). Fancier ways could involve a company
having at least two certs, each signed by a different CA, ideally with
each in a different jurisdiction (and with both CA jurisdictions outside
the company's home one and ideally not too "cosy" with that home
jurisdiction).

Regards,

PS I have simplified some cert aspects. For instance, most large
companies will want a master cert which is only used to sign subsidiary
company certs which are then used for day-to-day matters. This makes it
much easier to, say, revoke a compromised subsidiary cert while still
keeping the (better protected) master cert valid and able to issue a new
replacement subsidiary cert.

PPS Here's the CA security compromise I promised. It's so simple as to
be laughable but the risk is still very real:

All browswers (and the OS itself) keep a list of the credentials of all
major CAs. It is child's play if one has even brief surreptitious access
(< 1 minute) to someone's computer to swap that list for a list of one's
own, a list with at least some "bogus" CA credentials. If the true user
later signs on to a compromised website (phishing or whatever attack)
those bogus CA credentials can be used to completely validate that https
connection without so much as a murmur from the browser (key symbol will
be there, etc.)

Re: Gov't coerced Certs thwart SSL/TLS
 

Nicely put and somewhat validates my origional arguement. I am
in no way knowledgable in this field, but isn't there some way
something could be put on a company website whereby you could
validate the CA? Something like validating a file with an MD5
checksum.

> It would seem that the best protection against governmemt intrusion
>> into certs is for companies to self issue their own certs and carry
>> them to the cert companies.
>
>
> I will answer you and afterwards I'll explain in a postscript a different
> CA attack from the one in the articles that is very serious and very easy
> to do!
>
>
> As matters currently stand companies DO *generate* their own certs (or
> call it a pre-cert if you will). The CAs (e.g., Verisign) merely
> *digitally sign* those pre-certs (using as much or as little due
> diligence as they see fit to confirm their provenance) thereby converting
> them to "certified" certificates (to make a weak joke).
>
> Alternatively, a company (or other entity, such as you or me) can perform
> *both* the generation and certifying roles - this results in a "self-
> signed" certificate. Such a certificate effectively says: "I hereby
> certify that I am me."
>
> Fortunately, there is no way to forge/spoof the company public/private
> key part of either a CA-signed or self-signed certificate (without
> breaching the original company's internal security); that part of the
> protocol is rock-solid. The public/private keypair guarantees that an
> entity, whether counterfeit or genuine, can at least be confirmed to be
> the *same* entity at some later time. Any spoofing of an entity (even
> one signed by a corrupt cert authority) must use different company keys
> on the cert (that is, if the corrupt party expects to be able to decrypt
> the SSL signon).
>
> Surprisingly, the self-signed certificate is the *best* type of
> certificate *from a security standpoint* precisely because it does appear
> so weak (a paradox, a paradox, a most ingenious paradox...). All
> browsers will immediately flag such a "cert" for you rather than "rubber
> stamp" it as OK and such a cert obviously requires further scrutiny if
> the site involves any degree of trust in your dealings with it (which,
> however, *isn't* always the case).
>
> So, how do you check out whether a self-signed cert is valid? There are
> a number of methods but the short version is: By contacting the company
> (or some other entity that is both trustworthy and knowledgable about the
> company's cert) to confirm the validity of the company's cert.
>
> However, as they say in the late night TV ads, "But wait! There's more!"
> You should contact the company (or other trustworthy entity) either
> directly (i.e., face-to-face) or at least using an "out-of-band"
> communication path (i.e., not the same as the initial one where you first
> encountered the cert). But in this case you could have simply got the
> cert here originally and not just as confirmation after getting it by a
> less trustworthy path.
>
> Incidentally, the problem with using some "other trustworthy entity"
> instead of the company itself is that that is exactly what the CA tried
> to be (and failed). Except in special circumstances, why would you expect
> some other entity performing a similar role (e.g., the repository in the
> "perspectives" add-on) to be any better?
>
> So, while the self-signed cert is the *best* from a security standpoint,
> it *stinks* from a usability standpoint. Besides being a PITA for you to
> do this, few companies, except maybe some banks, are set up to handle it
> (e.g., a telephone inquiry). Moreover, the website traffic would dwindle
> to near nothing because most users would be neither capable nor willing
> to go to such trouble.
>
> Probably the best from a compromise viewpoint for companies with at least
> moderately skilled, privacy-conscious users (i.e, the 7 of us :-) is to
> have some automated out-of-band way of checking its cert (by telephone,
> or, less desirably, by email). Fancier ways could involve a company
> having at least two certs, each signed by a different CA, ideally with
> each in a different jurisdiction (and with both CA jurisdictions outside
> the company's home one and ideally not too "cosy" with that home
> jurisdiction).
>
> Regards,
>
> PS I have simplified some cert aspects. For instance, most large
> companies will want a master cert which is only used to sign subsidiary
> company certs which are then used for day-to-day matters. This makes it
> much easier to, say, revoke a compromised subsidiary cert while still
> keeping the (better protected) master cert valid and able to issue a new
> replacement subsidiary cert.
>
> PPS Here's the CA security compromise I promised. It's so simple as to
> be laughable but the risk is still very real:
>
> All browswers (and the OS itself) keep a list of the credentials of all
> major CAs. It is child's play if one has even brief surreptitious access
> (< 1 minute) to someone's computer to swap that list for a list of one's
> own, a list with at least some "bogus" CA credentials. If the true user
> later signs on to a compromised website (phishing or whatever attack)
> those bogus CA credentials can be used to completely validate that https
> connection without so much as a murmur from the browser (key symbol will
> be there, etc.)

Re: Gov't coerced Certs thwart SSL/TLS
 

copy of some long-winded posts in another discussion group

Law Enforcement Appliance Subverts SSL
http://www.wired.com/threatlevel/201...ket-forensics/

from above:

.... security researcher Chris Soghoian discovered that a small company
was marketing internet spying boxes to the feds. The boxes were
designed to intercept those communications -- without breaking the
encryption -- by using forged security certificates,

.... snip ...

financial crypto blog discussion:

Why the browsers must change their old SSL security (?) model
http://financialcryptography.com/mt/...es/001232.html
Pushing the CA into taking responsibility for the MITM
https://financialcryptography.com/mt...es/001233.html

this is recent computer architecture blog (posting) discussing
connection between supercomputing and electronic commerce:
http://www.garlic.com/~lynn/2010f.html#56

i.e. two of the people mentioned in the jan92 cluster scaleup meeting
http://www.garlic.com/~lynn/95.html#13

leave and show up at small client/server startup responsible for
something called "commerce server". We are brought in as consultants
because they want to do payments transactions on the server; the startup
had also invented this technology they called "SSL" that they wanted to
use. As part of mapping "SSL" to payment operations (now frequently
called "electronic commerce"), required threat & vulnerability studies
.... which included lots of assumptions about how SSL had to be deployed
and used.

As mentioned in the financial cryptography blog ... majority of exploits
over the period since then ... have long been known.

...

one of the references are to the large number of digital certificates
for Certification Authorities that have been added to standard browser
distributions over the years. In some cases, the original
Certification Authorities have gone bankrupt and are no longer in
business (browsers have no method for differentiating business
practices of the increasing number of different Certification
Authorities that have been enabled).

one of the 20yr scenarios is criminal elements coming into some level
of influence of any of these Certification Authorities. This is
analogous to a number of situations where criminal elements were able
to influence ATM cash machine manufacturing ... with skimming
compromises installed at the time the machine was being built.

A compromised Certification Authority is able to issue a digital
certificate that is acceptable by every browser in the world ... for
any business ... even for businesses that have digital certificates
issued from totally different Certificate Authority.

This is the old adage that the security trust chain is only as strong
as the weakest link ... the criminal elements are likely to go after
the weakest link not the strongest link ... (picking some clerk at a
Certification Authority ... or a Certification Authority that has some
other kind of weakness/vulnerability).

From failure mode analysis ... having also done some number of
high-availability products ... a high availability infrastructure is
built so that the probability of infrastructure failure is the
probability of all redundant components failing at the same time (the
product/multiplication of the failure probabilities of the individual
redundant components ... as the number of redundant components go up
the probability of system failure decreases).

However, the Certification Authority infrastructure is not a
high-availability infrastructure .... its characteristic is the chain
analogy ... the system fails if there is any failure in any component
(basically adding the failure probability of each individual
component) ... as the number of acceptable Certification Authorities
increase ... the probability that there is an overall system failure
increases (the inverse of high-availability operation where adding
redundant components lowers the system failure risk).

There is old post about jan92 meeting in ellisons conference room that
draws a thread between high-availability cluster scaleup and current
SSL "electronic commerce"
http://www.garlic.com/~lynn/95.html#13

Now, two of the people named in the above meeting, leave and show up
at a small client/server startup responsible for something called
"commerce server". As mentioned above ... we were then called in to
consult because they wanted to do payment transactions on their
server; the startup had also invented this technology they called
"SSL" they wanted to use.

another weak link in SSL domain name digital certificate infrastructure
is the domain name system. When I apply for SSL digital certificate, I
provide some information about who I am ... then the Certification
Authority validates with the domain name infrastructure that I am also
the true owner of the corresponding domain name.

An exploit is domain name hijacking at the domain name system ... and
then going to Certification Authority (that does the weakest validation)
.... and apply for a valid SSL digital certificate.

Countermeasures to domain name hijacking are using various technologies
to improve the integrity of the domain name system. However, there is
possibility that some of the technologies can also eliminate the need
for SSL domain name certificates. I've pontificated about this catch-22
in the past
http://www.garlic.com/~lynn/subpubkey.html#catch22

another article:

Sneaking Into the Transport Layer With a Fake ID
http://www.ecommercetimes.com/story/...wlc=1269788312

If crooks can get into compromising POS terminal and ATM cash machines
during manufacturing (with built in skimming devices, at one point there
was an estimate that as many as 1/3rd of POS terminals being sold in
particular market had built in skimming devices at manufacturing)
.... what so unthinkable about crooks being able to obtain (valid) SSL
digital certificates using forged identification.

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Re: Gov't coerced Certs thwart SSL/TLS
 

Nomen Nescio <nobody@dizum.com> wrote in
news:520a0e98ac3f57f33ad03006ff231018@dizum.com:

> Nicely put and somewhat validates my origional arguement. I am
> in no way knowledgable in this field, but isn't there some way
> something could be put on a company website whereby you could
> validate the CA? Something like validating a file with an MD5
> checksum.

Ah, but you forgot catch-22 :-) How do you know you're looking at the
*real* company website. After all, that's what the CA-signed certificate
was supposed to ensure.

If you're looking at a bogus counterfeit of the real site, it doesn't do
much good if the bogus site has a page which says (complete with hashes,
celebrity endorsements, whatever :-) that its bogus certificate is OK.

***********

However, here's another reason why self-signed certificates are not just
"equivalent to" but actually "superior to" CA-signed certificates:

Say, the first time you go to a site, you get its self-signed certificate
and add it *permanently* to your browser store (Most browsers give you
the option of adding it permanently or using it temporarily just one
time). Your browser will have bitched and alerted you so it's your
decision (and responsibility!) to have checked it out (or not) at that
time. Let's pretend you were satisified that the site was legit (either
because you really did do a separate telephone confirmation of its
certificate - unlikely - or because the content and internal consistency
of the site seemed satisfactory - pretty weak but by far the more likely
case for all but the most diligent users). OK, you now have the site's
self-signed cert in your browser store. And let's assume this really was
the legit site.

You are now in pretty good shape against some *subsequent* attempt to
pass off a bogus site as that real site - your browser will alert you
again if some other self-signed cert is used (such a bogus cert must
*necessarily* have a *different key* even if all the other cert data
(company name, etc.) is spoofed to appear correct.) [See PS for caveat]

On the other hand, if the legit site had instead used a CA-signed cert,
the first time you went to the site your browser would have (internally,
no user interaction) checked that the company cert was indeed valid by
checking it against the CA signing data the browser keeps in its store.
The company cert would check out and so your browser would (seamlessly)
let you access the site in https mode. However, the browser would NOT
store the actual company cert. And there's the rub!

The next time you go to (what is ostensibly) that site the browser will
internally again perform the exact same checking routine to see if the
CA-signed cert is valid (i.e., checks the cert out against the CA signing
data the browser keeps in its internal store). But this time the
(phised, etc.) site's CA-signed cert might be a bogus one (let's say
government coerced). The false cert will pass muster - even if the new
bogus cert has been signed by a different CA than the first time (even a
CA in a different country). In other words, when a browser checks out a
CA-signed cert, every time is the same as the first time - the browser
has *no memory* of earlier approvals or on what they were based. And
because it has no memory your browser will not "notice" that the signing
CA has changed or that the company's key on the certificate has changed!

In short, self-signed certs force the browser to "remember" them and so
it is much easier to detect any subsequent changes (e.g., passing off
attempts by a bogus site).

However, the downside is that all this comes at the cost of convenience
and usability. Sadly, faced with that tradeoff, most folks will sell
their privacy and security for the mess of potage that is CA-signing.

Regards,


PS The caveat referred to above is this: I haven't checked what happens
(i.e., what particular browsers do) if a site which originally used a
self-signed certificate is found to use a CA-signed certificate on a
subsequent visit. In principle the prowser has enough information to
alert you to the change (which would save your ass in the unlikely but
possible event that the new CA-signed cert is bogus). However, I
strongly suspect (although I am too lazy and unmotivated to check) that
most browsers would happily accept the new CA-signed cert without
alerting you (after all, this is what the browser expects to be the
common vanilla situation). In which case you're hooped!

Unless... Maybe....

The following depends on how particular browsers handle the case where a
company cert is signed by a CA that is NOT in the browser's internal
store (e.g., CACERT). (I haven't checked. I have the soul of a
consultant: I theorize and report but leave actual implementation to
others :-)

In such a case a browser WILL alert you - the question is what the
browser does when you "approve" it using that site. What you (well, I
:-) want it to do is add the site's certificate to its internal store
(just as for a self-signed cert). What you DON'T want the browser to do
is to instead add the new CA to the internal browser store of valid CAs
(where it could then be used to validate approve other sites, etc.) while
not storing the site cert.

If your browser handles things the "right" way then for maximum security
you should purge your browser's internal store of *ALL* CA credentials
(i.e., the internal list of valid CAs is the null set). This would force
the browser to follow the self-signed drill (i.e., store the cert) for
ALL sites, whether they use self-signed or CA-signed certs. A PITA but
very secure.

Re: Gov't coerced Certs thwart SSL/TLS
 

"nemo_outis" <abc@xyz.com> writes:
> However, here's another reason why self-signed certificates are not just
> "equivalent to" but actually "superior to" CA-signed certificates:

re:
http://www.garlic.com/~lynn/2010g.html#10 Gov't coerced Certs thwart SSL/TLS

lots of past posts discussing SSL domain name certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

note that Certification Authority digital certificate ... is simply a
"self-signed" digital certificate that has been loaded into the browser
cache of self-signed Certification Authority digital certificates (the
primary difference between any random self-signed digital certificate
and a Certification Authority self-signed digital certificate ... is
whether or not the self-signed digital certificate has been loaded into
the browser cache of Certification Authority self-signed digital
certificates).

the PKI-based digital certificate infrastructure is a chain of digital
certificates that is rooted at the Certification Authority digital
certification ... and it is a "root" because if is self-signed and
loaded into browser Certification Authority digital certificate cache.

As previously mentioned, the browser Certification Authority self-signed
digital certificate caches have accumulated a large number of "root"
certificates ... and browsers make no differentiation between the
"roots". A compromised root could bring down the whole infrastructure by
issuing "valid" certificates for any and all comers (even for entities
that already have digital certificates from other roots).

However, the nature of URLs have gotten quite obfuscated for a large
percentage of the population ... so an attacker doesn't even necessarily
have to even get a SSL digital certificate (for the original domain
name) ... they can obtain a similar domain name (using a valid front
company) and then obtain a valid SSL digital certificate. Then they send
spam email asking people to click-on their URL (which has a valid
SSL). They then set up their website to operate as a MITM (potentially
using slightly modified standard proxy code) ... where they run two
paird sessions ... one between the end-user and their proxy (using their
SSL digital certificate) and a 2nd session with the "real" site (using
that organization's SSL digital certificate). They are then able to
evesdrop/skim all traffic and/or even modify traffic as necessary. This
is slightly less privileged level than getting a valid SSL digital
certificate for the original domain name (as opposed to just a similar
domain name).

Remember ... with the clicking convention and people paying little
attention to the actual URL ... SSL primarily operates to validate that
the webserver being talked to is the webserver (aka domain name) that it
claims to be (not that the webserver that the user thinks they are
talking to is the actual webserver that they are actually talking to).

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Re: Gov't coerced Certs thwart SSL/TLS
 

Nomen Nescio wrote:

> Nicely put and somewhat validates my origional arguement. I am in no
> way knowledgable in this field, but isn't there some way something could
> be put on a company website whereby you could validate the CA?
> Something like validating a file with an MD5 checksum.
>

That would just be adding complexity. Duplicating what's already in place
with the certs themselves (the CA is essentially validating it's clients
with an "MD5 hash").

The solution to all this, as Nemo said, is self signed certs *and*
education. Admins need to be educated with respect to *being* their own
CA, and users need to learn to manage SSL certs more like they would a
set of work keys.






>> It would seem that the best protection against governmemt intrusion
>>> into certs is for companies to self issue their own certs and carry
>>> them to the cert companies.
>>
>>
>> I will answer you and afterwards I'll explain in a postscript a
>> different CA attack from the one in the articles that is very serious
>> and very easy to do!
>>
>>
>> As matters currently stand companies DO *generate* their own certs (or
>> call it a pre-cert if you will). The CAs (e.g., Verisign) merely
>> *digitally sign* those pre-certs (using as much or as little due
>> diligence as they see fit to confirm their provenance) thereby
>> converting them to "certified" certificates (to make a weak joke).
>>
>> Alternatively, a company (or other entity, such as you or me) can
>> perform *both* the generation and certifying roles - this results in a
>> "self- signed" certificate. Such a certificate effectively says: "I
>> hereby certify that I am me."
>>
>> Fortunately, there is no way to forge/spoof the company public/private
>> key part of either a CA-signed or self-signed certificate (without
>> breaching the original company's internal security); that part of the
>> protocol is rock-solid. The public/private keypair guarantees that an
>> entity, whether counterfeit or genuine, can at least be confirmed to be
>> the *same* entity at some later time. Any spoofing of an entity (even
>> one signed by a corrupt cert authority) must use different company keys
>> on the cert (that is, if the corrupt party expects to be able to
>> decrypt the SSL signon).
>>
>> Surprisingly, the self-signed certificate is the *best* type of
>> certificate *from a security standpoint* precisely because it does
>> appear so weak (a paradox, a paradox, a most ingenious paradox...).
>> All browsers will immediately flag such a "cert" for you rather than
>> "rubber stamp" it as OK and such a cert obviously requires further
>> scrutiny if the site involves any degree of trust in your dealings with
>> it (which, however, *isn't* always the case).
>>
>> So, how do you check out whether a self-signed cert is valid? There
>> are a number of methods but the short version is: By contacting the
>> company (or some other entity that is both trustworthy and knowledgable
>> about the company's cert) to confirm the validity of the company's
>> cert.
>>
>> However, as they say in the late night TV ads, "But wait! There's
>> more!" You should contact the company (or other trustworthy entity)
>> either directly (i.e., face-to-face) or at least using an "out-of-band"
>> communication path (i.e., not the same as the initial one where you
>> first encountered the cert). But in this case you could have simply
>> got the cert here originally and not just as confirmation after getting
>> it by a less trustworthy path.
>>
>> Incidentally, the problem with using some "other trustworthy entity"
>> instead of the company itself is that that is exactly what the CA tried
>> to be (and failed). Except in special circumstances, why would you
>> expect some other entity performing a similar role (e.g., the
>> repository in the "perspectives" add-on) to be any better?
>>
>> So, while the self-signed cert is the *best* from a security
>> standpoint, it *stinks* from a usability standpoint. Besides being a
>> PITA for you to do this, few companies, except maybe some banks, are
>> set up to handle it (e.g., a telephone inquiry). Moreover, the website
>> traffic would dwindle to near nothing because most users would be
>> neither capable nor willing to go to such trouble.
>>
>> Probably the best from a compromise viewpoint for companies with at
>> least moderately skilled, privacy-conscious users (i.e, the 7 of us :-)
>> is to have some automated out-of-band way of checking its cert (by
>> telephone, or, less desirably, by email). Fancier ways could involve a
>> company having at least two certs, each signed by a different CA,
>> ideally with each in a different jurisdiction (and with both CA
>> jurisdictions outside the company's home one and ideally not too "cosy"
>> with that home jurisdiction).
>>
>> Regards,
>>
>> PS I have simplified some cert aspects. For instance, most large
>> companies will want a master cert which is only used to sign subsidiary
>> company certs which are then used for day-to-day matters. This makes
>> it much easier to, say, revoke a compromised subsidiary cert while
>> still keeping the (better protected) master cert valid and able to
>> issue a new replacement subsidiary cert.
>>
>> PPS Here's the CA security compromise I promised. It's so simple as
>> to be laughable but the risk is still very real:
>>
>> All browswers (and the OS itself) keep a list of the credentials of all
>> major CAs. It is child's play if one has even brief surreptitious
>> access (< 1 minute) to someone's computer to swap that list for a list
>> of one's own, a list with at least some "bogus" CA credentials. If the
>> true user later signs on to a compromised website (phishing or whatever
>> attack) those bogus CA credentials can be used to completely validate
>> that https connection without so much as a murmur from the browser (key
>> symbol will be there, etc.)