
In defense of client certificates - zdw
http://blog.bimajority.org/2015/10/05/in-defense-of-client-certificates/
======
xorcist
The state of client side authentication is abysmal, and has been since the
90s, for a number of reasons. The UI is bad, there's no way to log out, and
the server has no control of how and when dialogs pop up.

Things started to go sideways when web developers wanted to exercise control
over login form presentation, which just makes it very hard to prevent scripts
to tamper with them, and the heavyweights that control web browser development
simply has had no interest.

I'd like to see the above implemented, it's also time to get SRP in there, and
an opportunity for servers to serve pre-filled CSRs, just like the article
describes. I just don't know how to get there. Perhaps the bigger institutions
such as CERN (they certainly have the respect required) can take a more active
part in web browser development.

In the mean time, we still have Kerberos (and HTTP Negotiate). It works well
for always online internal applications, and you don't have to mess about with
revocations.

~~~
geofft
> In the mean time, we still have Kerberos (and HTTP Negotiate).

There's also this implementation of Kerberos in client-side JavaScript:

[https://webathena.mit.edu/](https://webathena.mit.edu/)

[https://github.com/davidben/webathena](https://github.com/davidben/webathena)

HTTP Negotiate is also super messy in similar ways (For instance, I'm not sure
how to authenticate using IE if your current Windows account is a local
account instead of a domain one). It definitely works, but not well.

------
pharaohgeek
Client-side certificates are pretty much a requirement within the U.S. DoD
space. And the CAC (smartcard used for logins and ID) are widely deployed
right now and used for authentication to such sites. To say that we need to do
away with cert auth is a non-starter, given how much gov't buy-in and money
has been used to roll these out. The real solution is to fix the support and
standards in the various browsers to make all of these "issues" a moot point.

If you've got a TRUSTED certificate authority (your definition of "trust" may
vary) and secure key storage (PKCS#11 smartcard, etc.) then certificate-based
authentication gives you a tremendous amount of authentication security.

~~~
geofft
Well, the primary thing being deprecated right now is <keygen>, not
certificate auth as a whole, so if you have a CAC you don't care about
<keygen>.

But also -- why does it make sense that _any website on the public internet_
can potentially find your US-government-signed identity? That's not even a
thing the government wants. You can just do logins against a single
government-run service and limit authentication to that one origin, and have
it produce signed, encrypted statements that you can pass to other authorized
servers. And then you also get auditing, revocation, etc. through that single
service.

~~~
zrail
Typically you'd only insert your CAC on sites already trusted by your machine,
and your machine only has those DoD certs if it's been provisioned by DoD.

~~~
geofft
What does it mean to insert it "on" a site? I have two dozen tabs open; how
should Chrome know that my authentication information should go to the
government but not to Hacker News?

It seems to me like you necessarily want a custom solution and custom software
here; I'm not understanding how the removal of client-cert support from public
builds of Chrome or Firefox would be a problem.

(I've never used a CAC, so this might be a dumb question.)

~~~
zrail
When you go to a DoD CAC-enabled site, typically you'll first see a click-
wrapper page saying "This is a DoD site, blah blah perjury, prison, blah".
This page will present a certificate signed with a DoD CA that only DoD-
provisioned machines have. The DoD has a whole suite of CAs for different
departments and security levels, which keeps things compartmentalized.

When you click through, you'll be directed to a page that, via standard SSL,
requests a client certificate which triggers the browser prompt. At this
point, you insert your CAC and select the certificate it contains. After you
enter your PIN to unlock the certificate, your browser sends your client cert
back and the site verifies that your CAC was issued by the CAC CA and that it
hasn't been revoked, then HTTPS proceeds as normal.

The trick is that CAC certificates can't be used blindly, since you have to
enter your PIN every time it gets used in a new session. Public sites can't
just request a client cert without triggering the prompt and making you re-
enter your PIN, and typically the CAC isn't inserted when you're not using DoD
sites or on the DoD VPN.

------
xPaw
It's not just enterprises that use client certificates, Estonian ID cards use
them too.

[https://www.ria.ee/public-key-infrastructure/](https://www.ria.ee/public-key-
infrastructure/)

~~~
icebraining
Same here in Portugal (though they're optional), for logging in to the IRS
website and others.

------
cs02rm0
_There is a move afoot among Web browser developers to remove an
authentication mechanism that many enterprises depend on: SSL /TLS with X.509
client certificates._

I didn't know that. Worrying as, as stated, a lot of enterprises do depend on
them. Is there a suggested alternative?

~~~
geofft
If you've got a server you're comfortable typing passwords at (which you
probably are, if you're using <keygen>), you ought to be able to set up some
sort of server-based authentication like Shibboleth or OpenID Connnect (which
is really more of an OAuth than an OpenID...).

If you want something that matches X.509 client certs closely, WebCrypto +
localStorage + either an extension or a static site (to host the JS that can
get access to your localStorage and sign a site-specific token) ought to work,
though I'm not sure I know of any out-of-the-box implementations. Mozilla
Persona is essentially this, although since it's a somewhat different use case
it's probably not an out-of-the-box thing.

Google would probably encourage you to use FIDO UAF.
[https://fidoalliance.org/specifications/overview/](https://fidoalliance.org/specifications/overview/)

------
Miademora
Were also using authentication with client certificates. Even with Firefox its
a mess. We had our authentification break twice in the last 2 years with
Firefox. Chrome sometimes just doesnt work and IE seems to work pretty often.
But if it doesnt even a settings reset or IE reinstall doesnt fix it.
Installing Windows again so it works feels like the good old times with
Windows 9x.

------
richm44
It's a pity this article is based on a false premise since it could have
contributed to the discussion more usefully. What's being removed is the
keygen tag, not client certificate support - the two are independent.

------
vkjv
Even new and shiny stuff uses client certificates. RE: Kubernetes
([https://github.com/kubernetes/kubernetes/blob/master/docs/ad...](https://github.com/kubernetes/kubernetes/blob/master/docs/admin/authentication.md#authentication-
plugins))

Loading this into the browser is often desirable for access to the proxy API.

------
illumen
Both browsers take patches. If enterprises need them so much, get some of
their vast mountains of money from them to fix the problems.

------
geofft
Every single one of the purported advantages of client certs here can be done
with WebCrypto + localStorage, right?

(I've even heard of people looking at polyfilling client certs with an
implementation based on WebCrypto and localStorage.)

~~~
bensummers
Apart from the advantage that it's very easy to prevent requests which don't
have the required client certificate from even hitting your application, which
is a major security win.

~~~
geofft
Well, they're hitting your web server because you don't want a hard-required
client certificate. (I've administered a server relying on a larger deployment
of client certs than OP's; browser compatibility is a mess, and
`SSLVerifyClient require` is a mistake.)

Yes, you can set things up on the server side so that it hits a static page
instead of your web _application_. But you can do that with the JS-based
solution too: have it send you to a login page with a signed query-parameter
or similar, and verify that query parameter in the web server configuration.
If it fails / doesn't exist, deliver a static site that includes the necessary
JS to do the login.

Your web server will need to verify a signature or MAC there, but this is way
less attack surface than the usual client-cert processing code in SSL stacks
(which processes untrusted keys and signatures). Removing that code will be an
equal or greater security win.

Basically, if there is interest in engineering a good application-level
solution instead of relying on the transport-level one, it can absolutely be
done. (I do freely admit there isn't anything that can be used out-of-the-box
today, to my knowledge.)

------
edward
Debian single sign-on (SSO) recently switched to using client certificates.

See
[https://wiki.debian.org/DebianSingleSignOn](https://wiki.debian.org/DebianSingleSignOn)

