Ian G wrote, On 2009-03-21 12:32: > It seems that we have a consensus that client > certificates (in a client authentication role at least) are unusable > with the current system. Approximately, for many reasons.
Sorry, I disagree. There are many places (companies, governments) that use client auth every day for most of their SSL connections without any problem. They would not agree that it is unusable. They do not file bugs and they do not participate in this newsgroup. Then, there are a set of server products that have misunderstood and misused TLS client auth, and with those products, client auth is unusable. Those are (mostly) freebies, so they tend to be used by amateur web site (and mail server) admins. Having no experience with any other products, those folks tend to assume that the problems they have are fundamental problems with TLS client auth, rather than bugs or poor design in the particular free server products they've chosen to use. The consensus of which you speak is actually a consensus among users of those crappy servers that, with those servers, client auth is unusable. I am part of that consensus. But I do not agree that changing the client to reward crappy servers is any part of the solution. And I "vote with my wallet" on all those crappy servers. I won't use them. > And, the way forward is more UI support [1], as suggested by Johnathan. And regardless of the real cause, most browser users want the browser to change to accommodate them. They don't want to fix the problem, they want to "fix" the browser. The browser is always the problem, in their opinion. Servers that do not reuse TLS sessions, and force doing client auth the hard (expensive, in CPU cost) way on every connection will never take off. You'll recall that, for many years, the complaint about SSL/TLS was that it was too slow, too CPU intensive, and that a server using SSL/TLS would reach saturation at a lower transaction rate than servers that don't use SSL/TLS. That perception is now much less widely held, in part due to intelligent use of SSL/TLS session caches. Doing client auth the hard way on every connection is MUCH WORSE in CPU cost than ordinary SSL/TLS without session reuse. If people perceive (as some do now) that using SSL/TLS client auth means doing a full handshake with TWO RSA computations on every connection, they will never adopt it. And that what some STUPID CRAPPY servers do now. But it's unnecessary. If the clients go along and make this crap invisible, silently causing the servers to spend that extra CPU cost, that will GUARANTEE that SSL/TLS client auth is forever branded as too slow and too expensive. BTW, as I've documented before, many of these flawed servers request that client's authenticate with a cert, but then ALWAYS drop the connection abruptly if the client actually does try to authenticate with any cert. It's actually impossible to use them if you attempt client auth. So, for them, having the client automatically and silently do client auth will merely assure that users cannot access those crappy servers at all. That will lead to more user complaints against the browser. Any server problem is always blamed on the browser. That's the oldest lesson of the web, bar none. But that doesn't mean that the browser should change for every crappy server that comes along. It's fine for Darwinian selection to let those servers die out. There's no need for browsers to try to keep those crappy servers live longer. > [ big design proposal snipped ] > How does that sound? Do you really imagine that those ideas have not already been considered by the browser folks, many times, long ago? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
