Re: Maybe It's Snake Oil All the Way Down
"James A. Donald" <jamesd@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@metzdowd.com
The problems that this creates are demonstrated by what happens when technically skilled users are required to work with certificates.
If you haven't already seen it, I highly recommend Don Davis's "compliance defects" paper (and slides!) available at http://world.std.com/~dtd. Abstract follows: Public-key cryptography has low infrastructural overhead because public-key users bear a substantial but hidden administrative burden. A public-key security system trusts its users to validate each others' public keys rigorously and to manage their own private keys securely. Both tasks are hard to do well, but public-key security systems lack a centralized infrastructure for enforcing users' discipline. A "compliance defect" in a cryptosystem is such a rule of operation that is both difficult to follow and unenforceable. This paper presents five compliance defects that are inherent in public-key cryptography; these defects make public-key cryptography more suitable for server-to-server security than for desktop applications. -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
On Wed, Jun 04, 2003 at 04:32:23PM +1200, Peter Gutmann wrote:
"James A. Donald" <jamesd@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.
It's the I part of PKI that's hard. That the assumptions built into X.509 (i.e. a rigid certificate hierarchy) don't work everywhere just makes it harder. And the obstinance of the standards organizations involved don't help. Too often people see something like Peter's statement above and say "oh, it's that nasty ASN.1 in X.509 that is the problem, so we'll just do it in XML instead and then it'll work fine" which is simply not true. The formatting of the certificates is such a minor issue that it is lost in the noise of the real problems. And Peter publishes a fine tool for printing ASN.1, so the "human readable" argument is moot. Note that there isn't a real running global PKI using SPKI or PGP either. The largest problem with X.509 is that various market/political forces have allowed Verisign to dominate the cert market and charge way too much for them. There is software operable by non-cryptographers that will generate reasonable cert reqs (it's not standard Openssl) but individuals and corporations alike balk at paying $300-700 for each cert. (yes I know about the free "individual" certs, the failure of S/MIME is a topic for another rant). This is why lne.com's STARTTLS cert is self-signed. Verisign isn't getting any more of my money. Eric --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
At 7:40 AM -0700 6/4/03, Eric Murray wrote:
Note that there isn't a real running global PKI using SPKI or PGP either.
I'm not sure SPKI was ever meant to be a global PKI. It was more meant to authorization in a "verifier-centric" system. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Due process for all | Periwinkle -- Consulting (408)356-8506 | used to be the | 16345 Englewood Ave. frantz@pwpconsult.com | American way. | Los Gatos, CA 95032, USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
Eric Murray <ericm@lne.com> writes:
Too often people see something like Peter's statement above and say "oh, it's that nasty ASN.1 in X.509 that is the problem, so we'll just do it in XML instead and then it'll work fine" which is simply not true. The formatting of the certificates is such a minor issue that it is lost in the noise of the real problems. And Peter publishes a fine tool for printing ASN.1, so the "human readable" argument is moot.
Actually, the ASN.1 part is a major factor in the X.509 interoperability problems. Different cert vendors include different extensions, or different encodings. They put different information into different parts of the certificate (or indeed the same information into different parts). Does the FQDN for a server cert belong in the DN or some extension? What about the email address for a user cert?
Note that there isn't a real running global PKI using SPKI or PGP either.
That's a different problem (namely that the "big guys" like RSA Security, Microsoft, and Verisign don't sell PGP-enabled software or PGP certificates). PGP's problem is an integration problem, making it easy to use for non-techies. That has been the barrier to entry for PGP.
The largest problem with X.509 is that various market/political forces have allowed Verisign to dominate the cert market and charge way too much for them. There is software operable by non-cryptographers that will generate reasonable cert reqs (it's not standard Openssl) but individuals and corporations alike balk at paying $300-700 for each cert. (yes I know about the free "individual" certs, the failure of S/MIME is a topic for another rant).
This is only part of the problem... It is not all of it. Indeed the cost (both in money, time, and headache) has always been a barrier to entry. I don't believe that market or political forces are the largest problem with X.509.... I will certainly agree that the cost is a major impediment. The question is: how do we convince M$ and Netscape to include something else in their software? If it's not supported in IE, then it wont be available to the vast majority of users out there. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
Eric Murray <ericm@lne.com> writes:
Too often people see something like Peter's statement above and say "oh, it's that nasty ASN.1 in X.509 that is the problem, so we'll just do it in XML instead and then it'll work fine" which is simply not true. The formatting of the certificates is such a minor issue that it is lost in the noise of the real problems. And Peter publishes a fine tool for printing ASN.1, so the "human readable" argument is moot.
Actually, the ASN.1 part is a major factor in the X.509 interoperability problems. Different cert vendors include different extensions, or different encodings. They put different information into different parts of the certificate (or indeed the same information into different parts). Does the FQDN for a server cert belong in the DN or some extension? What about the email address for a user cert? This isn't really true in the SSL case: To a first order, everyone ignores any extensions (except sometimes
Derek Atkins <derek@ihtfp.com> writes: the constraints) and uses the CN for the DNS name of the server. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/
Two million in bearer bonds stolen along with the safe that held them: http://www.timesunion.com/AspStories/story.asp?storyID=140587&category=FRONTPG&BCCode=HOME&newsdate=6/6/2003
Eric Rescorla <ekr@rtfm.com> writes:
This isn't really true in the SSL case: To a first order, everyone ignores any extensions (except sometimes the constraints) and uses the CN for the DNS name of the server.
Except some CAs make certs that can only work as an SSL server and not an SSL client, or don't work with certain verifiers, or can't be parsed right, or have the "commit-bit" set on some extensions. It's been a major pain in a problem that I'm working on -- not all vendor's certs work properly.
-Ekr
-derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
Derik asks the pertinant question:
The question is: how do we convince M$ and Netscape to include something else in their software? If it's not supported in IE, then it wont be available to the vast majority of users out there.
My view, again, IMHO: ignore Microsoft. Concentrate on the open source solutions: KDE, Mozilla, Apache. These groups will always lead in security, because they are not twisted by institutional conflicts; they can examine historical security model from the point of view of interested professionals, rather than commercial actors trying to preserve this or that revenue stream. The trick is to understand whether HTTPS as it currently is can be improved. If it can, then those above guys can do it. Once the improvements are shown to work, Microsoft will follow along. They are a follower company, not an innovator, and they need to see it work in practice before doing anything. As Derik suggests, the vast majority of users will have to wait. Along those lines, there's one piece of excellent news: Eric Rescorla wrote:
One can simply cache the certificate, exactly as one does with SSH. In fact, Mozilla at least does exactly this if you tell it to.
That's fantastic! I never knew that. How does one set that option on Mozilla? (I'm using 5.0 / 1.3.1.) -- iang
On Fri, Jun 06, 2003 at 06:08:34PM -0400, Ian Grigg wrote:
Derik asks the pertinant question:
The question is: how do we convince M$ and Netscape to include something else in their software? If it's not supported in IE, then it wont be available to the vast majority of users out there.
My view, again, IMHO: ignore Microsoft. Concentrate on the open source solutions: KDE, Mozilla, Apache.
Mozilla already has a pretty neat interface to gnupg, called Enigmail. See http://enigmail.mozdev.org/ -- Harmon Seaver CyberShamanix http://www.cybershamanix.com
participants (9)
-
Bill Frantz -
Derek Atkins -
Eric Murray -
Eric Rescorla -
Harmon Seaver -
Ian Grigg -
Peter Wayner -
pgut001＠cs.auckland.ac.nz -
Rich Salz