Why is nobody using SSL Client Certificates?
pilif.github.com
pilif.github.com
1) this is not truly two-factor authentication as the certificate is stored right there on the machine I'm using for authentication. If this would ever get widespread use, we'd have issues with malware extracting the key from the browser. Not even password-protecting the key (giving you something comparable to SSH authentication) would help much as malware presumably has access to your memory anyways.
2) With the problems inherent to the SSL protocol in conjunction with renegotiation (http://www.kb.cert.org/vuls/id/120541), this becomes a bit annoying because you can't safely have resources for which you check a client certificate on the same server as resources where you don't. Remember: The article predates the vulnerability by a year.
3) More and more people are beginning to have multiple devices they use. There's not even a "main" machine any more. Not having access to the client-side certificate is annoying though with the various browser syncing solutions out there, this might become a non-issue over time.
None the less. My personal complaint about the overly complicated UI still stands - heck, this is even annoying for me and I would (aside of point 2 above) have good use for this at times - but clicking through this jungle of dialog boxes remains annoying to this date.
I used to work at a tech firm, we used this SSL Certificates to authenticate against our internal CA. Sysadmins got it wrong, devs got it wrong, qa got it wrong and nobody else stood a chance.
The worst thing about it by far was managing keys between machines. For example, it made it impossible to work from home on an impromptu basis without someone available to help you out.
I've had this issue with the fact that I have two CACert accounts (due to not remembering I had already created one before) and I just recently moved all domains to the newest account...
Unless you're a year or so out of date on your patches, renegotiation works better than ever.
Neat to get the update from the guy I watched keynote about the problem in the first place though!
- Most developers don't understand them. - Library support for them is wonky - we've run into issues with curl, the PKI infrastructure in Windows and weird bugs up and down the stack - There is a lot of complexity around cert management - how do developers move it around machines, share with their team, etc.
We had a lot of good reasons for using it and a lot of scenarios were made much easier still. But if I had to go back and have a do over, I would probably use OAuthv2 (which didn't exist then :) ).
I think they could have caught on at least as well as BrowserID will.
Basically, even if the cost is marginal, so are the benefits for most sites — and although I haven't implemented this myself, I do not believe the cost would be marginal once you take into account all the new problems it creates.
Or owning 2 machines.
I suppose you could help that a bit. i.e. have a cert used for authentication, if it is not present then ask for the users info and offer to create a cert for next time.
This is 2 factor authentication... Validating something you have (ie the computer) and something you know(ie a password).
- UI is slick
- you don't need to remember to carry your certificate around, because while you complain about the UI do you think average joe who's scared by the preference button will actually .. copy his cert and carry it around? Please, get f. realistic for a moment, that is the real major useability issue.
- it uses certs to authenticate to sites as well
basically browserid provides a third party to store and manage certs for you and you can request them from anywhere without knowing anything about computing or security.
I'm generally not in favor of adding additional 3rd party dependencies to my websites.
For how this plays out, imagine the following combinations of native support for the BrowserID protocol:
1) BROWSER AND IDENTITY PROVIDER: Mozilla's services are left completely out of the loop.
2) BROWSER ONLY: Mozilla's services step in as a trusted third party to handle validating control over an identity and signing assertions for that user.
3) IDENTITY PROVIDER ONLY: Mozilla's shim and services step in to provide a surrogate implementation of the BrowserID protocol.
4) NEITHER: Mozilla's services step in as a trusted third party to handle validating control over an identity and signing assertions for that user, and to provide a shimmed implementation of the BrowserID protocol.
Again, the protocol was designed to be distributed from the very start, so nothing is locking it down to using Mozilla's shim and services, but they're there for you if you want to use them.
Disclaimer: I do not currently work for Mozilla, but I will be joining the Identity team later this month.
js-based auth doesn't work for the whole web. Even for other browsers you have to make a solution where everything server can get the e-mail address without javascript on the client.
And you should definitely explain protocol as simple as possible for everybody who implements it to understand what's going on and how your services can be replaced by something else. That is, if you're serious about having a real cross-browser solution.
Guess how many companies bite? Zero. None of them want to do it, and these are major nationwide banks. So much of their knowledge comes from handling browser based sessions that they can't imagine a different way.
Someone needs to do this in the browser. You'd need to put a (escrowed!) keyphrase on the cert, back it up to the cloud securely, associate it with the user's account in such a way that they can get to it. And then enough browsers need to support it to make it worthwhile. That's a tall order.
For example many banks in the US use security questions to identify a user/device on first run. In europe they use randomized keycards. Once this has been completed the device stores a nonce to identify the device across multiple sessions. If you ever kill your nonce you have to repeat first time authentication.
Now granted this works, and many people might feel this is good enough, but I agree with the author that client certs would work better for identifying users then the current solutions.
And one wonders why no one wants to do this stuff.
This is poor analysis. You're arguing from an incomplete position. The choice isn't between "some security" (mobile certs) and "best security" (forced reauthentication). It's between "bad security" (multiple accounts with shared passwords) and "better security" (single cloud account with escrowed access to the cert).
They don't use client certs, though, and I have no knowledge on the private banks.
A user moving to a new browser has to identify himself as the real user, thus requiring some sort of authentication. It's a chicken and egg thing.
At Clover (www.clover.com) we've built a payment app for iOS and Android which use client certs to great effect. Once your iOS/Android device is bound to your Clover account using the client cert, you just need a short PIN to protect against unauthorized physical access to the device.
Because we're a native app, we're able to hide all the nastiness of installing the client cert. When the app is freshly installed, we first verify control over a phone number (by sending a text or calling it with a verification code). If that checks out, we issue a new client cert to that device and associate the device with the account bound to the phone number. An account is locked to a (small) set of devices (e.g. iPad + iPhone).
Not a problem as long as you only have a fixed number of machines to use but once you start using other machines, family/friends/school/work/library you need a secure way to access the certs.
1) Synchronise the certificates automatically between every computer in the world;
2) Change user; and
3) Create multiple identities,
I think this would indeed be used on a huge scale already. Traditional accounts do all of this: you can log in to your Gmail account from any computer in the world. You can sign out of your Gmail account and sign in with a different user. If you are feeling paranoid or scared about having no backup Gmail address, you can create a secondary account.
Now you are probably able to use multiple certificates and maybe switch between them, but none of this has been made user-friendly. So that is the crux, browser builders (Microsoft, Mozilla, Apple, and--a bit later on--Google) just didn't pick this up.
Still though, the first problem would remain. But don't I remember entering a password for my self-signed SSL certificate which I created for my Apache webserver? Couldn't you do something like that and generate a certificate based on a password? Like signing up for a website, only on browser level and for every website at the same time?
Maybe there is actually future in this after all. This sounds good to me at least!
Also, I've heard mention that Monkeysphere is working on something to generate client SSL certs that are tied to your gpg key. Which would allow logging into a site with one, based on the web of trust.
You have to make sure you delete the key (securely, ideally) before leaving the machine. What is the guarantee that the machine you are trying to use is not compromised or holding on to your keys?
Even then the website is not sure if its really you. They also need to implement a password based authentication. Some one stealing your keys is more possible (given that you want to login from any machine) than some stealing your password. Of course they can guess your password but I won't get into that.
One way to do it would be to build a dongle that has keys and provides the authetication service on behalf of the user. But then we would need multiple identities, which means we need multiple certificates and the cost will multiply.
Anonymity is completely gone. Even if the CA grants you an "anonymous" certificate it can always be traced back to you based on the cert parameters.
So no.
The proposal is to automatically generate a self-signed cert for each origin. This gets rid of many of the UI problems: it eliminates the need to choose which cert to send to each site (which also means the user can't be tracked across sites via OBCs, and thus the user doesn't need to grant permission before sending his cert).
On the other hand, it doesn't solve the problem of re-authenticating on different machines. It's not proposed as a primary authentication mechanism, but instead as a means of strengthening ordinary HTTP session cookies (http://www.browserauth.net/channel-bound-cookies).
I think it is a bit of a chicken and egg problem: no-one uses them because no-one understands them, and no-one understands them because no-one uses them. The certificate management UI is also awful, which doesn't help.
I think it is probably the perceived overhead of operating your own CA, even though modern web app like interfaces exist and make doing such a thing a breeze. It could be that the less technical people like architects (that don't have to implement it themselves) just assume that it'll be too much of a conceptual thing to try and sell. It works tho! And seems like it would be in theory more secure given the features of revocation, but I guess that's the same as turning off someone's ID in the directory perhaps.
However, if you have two accounts there, logging out and logging in again causes IE9 to just re-use the same certificate instead of prompting you again.
I absolutely agree the browser interface for certs is terrible. The post is from 4 years ago, and the interface still looks just the same, and is still just as much of a pain in the rear.
I would take this over "What color was your first car?" any day, though.
I recommend using P12 as most browsers will 'just get it'. With Nginx for example, you can build in SSL support and then configure a directive to request a client cert at which point the web browser will load a relevant certificate to choose to pass along. More so, Nginx can be configured to extract information from the client certificate and use it as variables.
http://wiki.nginx.org/HttpSslModule#ssl_client_certificate http://wiki.nginx.org/HttpSslModule#Built-in_variables
So one can have ssl.awesome.io and extract info to only allow 'Joe231' to see ssl.awesome.io/Joe231. Even better is by serial or what have you.
Now my 2 cents on the problem; it confuses people, revocation and issuance. I'm guessing here DoD had certificates built into our ID cards and that was extracted with the reader at a need. Not sure, just a guess. Personally I think the cryptic nature that is command line Openssl is what slows down the mob from pushing new tech unto everyone. Think about it. Some comments present are disappointing for hacker news; you should be playing with cryptic technologies and making them work.
Want a startup idea? Plop certs into AXE body spray cans and done.
oh looky what Wikipedia cited: http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html
It's hard to know how much to blame on Windows & how much has changed since then, but they were a never ending source of pain. We had to provision & manage 1,000+ workstations, dispersed not only through Beijing, but all of China. We couldn't find a way to install the certs as part of the imaging processing, so we attempted to automate as much as we can. Only on Windows (XP, I believe) you couldn't automate the entire installation. So we had to print up instructions & try to make it understandable to bank tellers. (Olympic point of sales where located at various Bank of China branches.)
Additionally, each certificate was store with a specific window account. So either accounts had to be shared, or we had to provision each machine for the dozens of tellers who might use it. (As well as making sure the process was easy when someone new started. And that the certs were revoked when they left. Again ugh.)
BTW, did you know that Java on Windows XP w/ the Chinese language pack has a different default classpath than Chinese Window XP? One of the other joys we discovered.
Actually, maybe the morale of the story here isn't client certs, but rather that Windows does.
i) No need to enter username and password: Yes, we won't have to enter those but the real problem is keeping track of multiple usernames/passwords, not entering them. Even if we implement certificate based authentication, we will probably need multiple of them. Single identity is unlikely to happen because of (a) Privacy - You won't want to use the same identity (username or certificate) on facebook and a .xxx site. (b) Security - Sites who care about security like banks would want stronger control on identity (e.g. by expiring passwords or certificates periodically) whereas other consumer facing sites would not. Given these reasons, single identity is not going to happen anytime soon. If keeping track of multiple usernames/passwords is a problem, think how hard would it be to keep track of multiple certificates.
(ii) Two factor authentication: Well, just storing certificates in the browser/computer doesn't make it two factor authentication. The second factor in 2-factor should include something which is outside your computer such as a hardware token or your mobile phone. If you store your certificate in your laptop, the same malware which steals your password would steal it too.
(iii) Delegation and revoking: OAuth already solves this problem. You don't give your facebook username/password to a third party site for it to access your profile. And you can revoke access anytime.
Certificate based authentication is useful if you store them on some 3rd device like Smart Card or USB keys. There are a bunch of companies doing that but they mostly sell to enterprises. We don't want to carry multiple cards, right?
Half the comments on here are about moving certicates! YOU NEVER MOVE PRIVATE CRYPTOGRAPHIC CERTIFICCATES!
Random site that describes the procedure is below. What is the right way to do this?
Exporting the private key of the certificate
Enter the password of the private key, and then export the client key onto the generated client certificate using the following command:
openssl pkcs12 -export -out client.pfx -inkey client.key -in client2.pem
The only way (IMHO) to get around those attacks is to never decrypt the key on a machine with untrusted software running and accessible memory. The only device that comes close to this is a smartcard or TPM type scenario, which uses a separate CPU and protected memory to do the RSA operations.
It was slightly tricky to get the iOS/Android programmatic HTTP layers to properly format and present the cert to an auth challenge, but since we figured that out, it's been seamless.
For everything else, there are much simpler solutions.
If your system is rooted / infected with malware, you lost. The only solution is to format the drive and start over.
The alternative is to use a 2 factor authentication mechanism that uses a separate device, like your phone receiving a text message. That's a pain for the average user, and certainly not "simpler".
In one scenario even with 500 users we would get 2-3 support calls per day regarding the certificates. And having Verisign set us up as an intermediary with an ability to sign client certs was very expensive.
So client certificates are being used, even though people aren't using them in their browsers.
I tried to get other folks to use it, but people equate cert with complexity and money and their eyes roll back into their heads if you mention PKI.
I also found that the Firefox Convergence add-on (which itself is a neat concept) breaks client certificates (which I keep forgetting, so when I hit the private areas of my secure server, I keep getting denied until I remember to disable Convergence).
And in that setting not worth the time compared to Basic Auth.
Very relevant: https://en.wikipedia.org/wiki/X.509#Security
How do you respond to this criticism? Is it valid in this case?
But even in its present state I would argue that DSSID is at least as secure, and probably a great deal more secure, than any other extant authentication scheme out there. If you trust SSL, trust the DSSID server to be secure against write attacks (i.e. attacks that allow a hacker to change the content being served), and pay attention to the URL in your browser bar before entering your pass phrase, then DSSID is secure. (There's actually one other vulnerability, and that is malicious plug-ins, but no software-based security scheme can possibly be secure against that.)
By way of contrast, with passwords, you have to trust EVERY SINGLE SITE that you log in to. You have to trust the certificate chain for every single site that you log in to. (With DSSID you only have to trust the certificate chain for your DSSID server.) You have to trust that every single site that you log in to has not had malicious Javascript injected. You have to pay attention to the URL of every single site you log in to, not just one.
Most problematically, many HTTPS sites do not have valid certificates, which trains users to ignore warnings about invalid certificates, which essentially undermines ALL of the security of SSL. So having to only ever trust one certificate (which will always be valid) is a huge win.
If DSSID were be broadly adopted it would become more secure. Once the code is stable enough, I am going to open-source the DSSID server code so that anyone can run their own DSSID server if they don't trust mine. The Javascript that is served from the DSSID server is static (except for the nonce) so it can be independently audited and verified. The DSSID protocol doesn't have to implemented in Javascript. You could write a plugin that implemented it, or build the capability into a browser. It's a lot easier to plug the holes in DSSID than anything else out there.