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