"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
>The obvious protection is for users to check the certificate. Most users, of
>course, don't even know what a certificate is, let alone what the grounds are
>for accepting one. It would also help if servers used client-side
>certificates for authentication, since the man-in-the-middle can't spoof
>the user's certificate. But almost no servers do that.
This isn't really a problem with the servers though, the problem lies in the
fact that client-side certs are (effectively) unworkable. I know of a number
of organisations who wanted to use them and ran into so many problems just
with pilots involving small numbers of (presumably) experienced users that
they gave up on trying to deploy them to the masses. If we had an all-
encompassing PKI (ie.if cert management was easy) and if we could assume
technically clueful users and if those users really cared about security
(rather than seeing it as an impediment to getting their work done, which it
often is), then client-side certs would be feasible. At the moment they're
just not workable except within closed communities where you can control a lot
of the parameters (you run the PKI, you vet the users, and you tell them you
won't talk to them unless they take the appropriate security precautions and
hope you don't have competitors who'll let them in without this).
The ideal interface for this sort of thing would be a magic box (which could
be shaped like a smart card, but could be something else) with pre-generated
certificates which the user can't delete, mangle, or lose (a number of
European countries are aready going down this path), with a "Press button to
authenticate yourself" sign which lights up when client-side authentication
is needed. Smart cards with thumbprint readers are one step in this
direction, although they're currently prohibitively expensive.
Peter.
