Maybe It's Snake Oil All the Way Down
Peter Gutmann
pgut001 at cs.auckland.ac.nz
Wed Jun 4 00:32:23 EDT 2003
"James A. Donald" <jamesd at echeque.com> writes:
>I never figured out how to use a certificate to authenticate a client to a
>web server, how to make a web form available to one client and not another.
>Where do I start?
There's a two-level answer to this problem. At an abstract level, doing
client certs isn't hard, there are various HOWTOs around for Apache, Microsoft
have Technet/MSDN papers on it for IIS, etc etc. At a practical level, it's
almost never used because it's just Too Hard. That's not the SSL client-cert
part, it's the using-X.509 part. To save having to type in a long
explanation, I'll lift a representative paragraph from a (not-yet-published,
don't ask :-) paper on PKI usability:
There is considerable evidence from mailing lists, Usenet newsgroups and web
forums, and directly from the users themselves, that acquiring a certificate
is the single biggest hurdle faced by users [1]. For example various user
comments indicate that it takes a skilled technical user between 30 minutes
and 4 hours work to obtain a certificate from a public CA that performs
little to no verification, depending on the CA and the procedure being
followed. Obtaining one from non-public CAs that carry out various levels
of verification before issuing the certificate can take as long as a month.
A representative non-technical user who tried to obtain an (unverified)
certificate from a public CA took well over an hour for the process, which
involved [...] eventually the user gave up.
and that doesn't even get into the mess of managing private keys, handling
revocation, etc etc etc ad nauseum:
The problems that this creates are demonstrated by what happens when
technically skilled users are required to work with certificates. The
OpenSSL toolkit [2][3] includes a Perl script CA.pl that allows users to
quickly generate so-called clown suit certificates (ones that 'have all the
validity of a clown suit' when used for identification purposes [4]), which
is widely-used in practice. The cryptlib toolkit [5][6] contains a similar
feature in the form of Xyzzy certificates (added with some resistance and
only after the author grew tired of endless requests for it), ones with
dummy X.500 names, an effectively infinite lifetime, and no restrictions on
usage. Most commercial toolkits include similar capabilities, usually
disguised as 'test certificates' for development purposes only, which end up
being deployed in live environments because it.s too difficult to do it the
way X.509 says it should be done. Certificates used with mailers that
support the STARTTLS option consist of ones that are 'self-signed, signed-by
the default Snake Oil CA, signed by an unknown test CA, expired, or have the
wrong DN' [7]. The producer of one widely-used Windows MUA reports that in
their experience 90% of the STARTTLS-enabled servers that they encounter use
self-signed certificates [8]. This reduces the overall security of the
system to that of unauthenticated Diffie-Hellman key exchange, circa 1976.
In all of these cases, the entire purpose of certificates has been
completely short-circuited by users because it.s just too difficult to do
the job properly. The problematic nature of X.509 is echoed in publications
both technical and non-technical, with conference papers and product
descriptions making a feature of the fact that their design or product works
without requiring a PKI. For example, one recent review of email security
gateways made a requirement for consideration in the review that the product
'have no reliance on PKI' [9]. As an extreme example of this, the inaugural
PKI Research Workshop, attended by expert PKI users, required that
submitters authenticate themselves with plaintext passwords because of the
lack of a PKI to handle the task [10][11].
>As a result we each have a large number of shared secret passwords, whereby
>we each log into a large number of webservers. Was this what the people who
>created this protocol intended?
The assumption of the protocol's creators was that someone would figure out
how to make X.509 PKI work by the time SSL took off, and everyone would have
their own certificates and whatnot.
At least they got *most* of the design right :-).
Peter.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list