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.)