On 21/3/09 21:43, Nelson B Bolyard wrote:
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.
I'm afraid I disagree with this, too! Nor are they Mozilla's heartland.
I'm sure they do a good job 'n all, but I and most volunteers (I hope)
are concerned about Mozilla delivering product for the world.
Corporations & governments pay their sysadms to work long and hard to
get it all up and going. When they've got a real problem, they employ
programmers to fix the code and submit patches. Or they buy product
from suppliers like Microsoft.
Ordinary users do not have that luxury.
Unless we can get the mission of Mozilla changed to ditch the end-user
and concentrate on government & corporate markets, I'm of the opinion
the corps and govts of the world are big enough and ugly enough to look
after themselves. Who speaks for the rest?
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.
I don't know about these things, but I recognise that badly configured
servers are a pain. The servers I have experienced this with are
Apache. They may be misconfigured, but the sysadms aren't agreeing at
the moment, and talking about the sysadms being "bad" isn't going to
help; they are no better nor worse than the other ones I've known.
And even when the Apache config is "fixed", this is just the server-side
workaround. This only means I have to hit a pop-up once every day, it
doesn't solve the fundamental problem: I want to use cert X speaking to
server Y. And I want that written down, stuck in the browser's mind.
Fixing the server does not make that so.
...
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.
Surely that's perfect for us? If the clients cause the server that
pain, the server admins will ask around as to why their servers are so
slow, and be told the obvious: Just reconfig your server to have a
longer timeout on session, Dude!
If they can't ask around about that, then I agree that we have big
problems in server-land ... they certainly won't notice that the users
are not using client certs because of all the popups.
Any server problem is always blamed on the browser. That's the oldest
lesson of the web, bar none.
It's pre-web, and I'm afraid it's actually pre-computing. The stuff
that is closest to the user always takes the blame. It's just a truism
of all business. Mozilla could easily solve this issue by getting out
of browsers and into servers ;-)
Do you really imagine that those ideas have not already been considered by
the browser folks, many times, long ago?
Hmmm, well, many questions abound: why wasn't it done? where was this
discussed? Why didn't client certs just happen? Why are we still using
passwords?
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
