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?
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.
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.
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.
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.
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.
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.
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.)
WebCrypto + localStorage means the site has access to the private key if it wants to. That means that any script injection exploit can compromise everyone's keys.
I thought WebCrypto let you make non-extractable keys.
But in any case, I'm not sure I understand the threat model of that. The <keygen> service will already sign any public key that gets to it past authentication, so if you're worried about client attacks, that's already a problem. There's no distinction between compromising an existing private key and getting a new, unauthorized private key signed. You're already requiring that the site be secure against these attacks.
Obviously you don't store this in storage accessible to every relying website; you just store it in the origin of the authentication service itself, and have it generate signed messages (either client-side or server-side) that get passed to the relying websites.
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.
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.
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.
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.)
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.
Actually, the CAC is being used for desktop login into Active Directory in a lot (all?) cases, so it's reasonable to assume that the CAC is already in the reader when you fire up the web browser.
23 comments
[ 4.5 ms ] story [ 51.7 ms ] threadI didn't know that. Worrying as, as stated, a lot of enterprises do depend on them. Is there a suggested alternative?
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/
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.
There's also this implementation of Kerberos in client-side JavaScript:
https://webathena.mit.edu/
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.
https://www.ria.ee/public-key-infrastructure/
(I've even heard of people looking at polyfilling client certs with an implementation based on WebCrypto and localStorage.)
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.)
But in any case, I'm not sure I understand the threat model of that. The <keygen> service will already sign any public key that gets to it past authentication, so if you're worried about client attacks, that's already a problem. There's no distinction between compromising an existing private key and getting a new, unauthorized private key signed. You're already requiring that the site be secure against these attacks.
Obviously you don't store this in storage accessible to every relying website; you just store it in the origin of the authentication service itself, and have it generate signed messages (either client-side or server-side) that get passed to the relying websites.
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.
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.
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.)
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.
Loading this into the browser is often desirable for access to the proxy API.
See https://wiki.debian.org/DebianSingleSignOn