14 ms·

Why is nobody using SSL client certificates?

241 points by cottonseed 13y ago

joshuaellinger 13y ago
Yep -- too hard to setup. A really good browser enhancement would be 1-click client side certificate setup.
- evilpie 13y ago
  Pretty sure that you could write an Firefox addon for this.
- deleted 13y ago
  [deleted]
lmm 13y ago
The key management tools are awful. People complain about the complexity of PGP but at least there it's one-click to export a key, look at the details of it, sign someone else's key etc. But yeah, it would be nice to use this tech rather than reinventing the wheel. The underlying implementation is sound.
- area51org 13y ago
  The whole system, now close to 20 years old, needs a reboot. I know, that's easy for me to say. But it's showing its age, and could really benefit from a complete rethink.
  - lmm 13y ago
    Do you have specific criticisms? In cryptography, a system that has withstood scrutiny for that long is a rare and exceedingly valuable thing. By all means use it as the ugly foundations that you hide beneath the beautiful edifice on top, but throwing it away would be madness.
    - area51org 13y ago
      You're right, I'm being vague. I'm looking for two things, really: 1- simpler implementation — one that is easier for users to understand, and includes client certs by default 2- one with a re-engineered cryptographic implementation, one less likely to have the kind of numerous security flaws that have been uncovered in SSL/TLS over the years SSL was originally meant to serve two purposes: 1- encrypt communication 2- verify, through a trusted 3rd party, that the remote service you're contacting is actually who it says it is Most laymen, and many technologists, do not know that #2 even exists. Worse, this authentication portion has been all but destroyed by liberal certificate authorities like GoDaddy. From my experience, anyone can get a certificate for a domain without any kind of check to see if you have the right to use that domain. So, in theory, you could register "amaz0n.com" with GoDaddy, get a cert for it, and start using it, without any kind of background check. In the early days (when Verisign was the only CA in town), a business had to supply a Dunn & Bradstreet number and be subject to other background checking before being issued a CA-signed cert. If that sounds heavy-handed, it shouldn't: Verisign was supposed to have the users' backs. If you tried to get a cert for Amaz0n.com, it would have been rejected unless you could prove you actually are Amazon.com. I think that kind of authentication has a real place on the modern Internet. edit: formatting
      - lmm 13y ago
        >1- simpler implementation — one that is easier for users to understand, and includes client certs by default I'm not sure what you're suggesting. A nicer UI would definitely be a good idea, but you can do that without changing the underlying crypto implementation. >2- one with a re-engineered cryptographic implementation, one less likely to have the kind of numerous security flaws that have been uncovered in SSL/TLS over the years That's not how you get secure cryptography. You need not just a secure algorithm but a secure implementation, one resistant to timing attacks, compression attacks, and all sorts of nonobvious things. OpenSSL is far from developer-friendly, but the vulnerabilities have been hammered out over those 20 years, and there is a body of knowledge on how to use it securely. A new implementation would have to go through that all over again. >From my experience, anyone can get a certificate for a domain without any kind of check to see if you have the right to use that domain. So, in theory, you could register "amaz0n.com" with GoDaddy, get a cert for it, and start using it, without any kind of background check. In the early days (when Verisign was the only CA in town), a business had to supply a Dunn & Bradstreet number and be subject to other background checking before being issued a CA-signed cert. If that sounds heavy-handed, it shouldn't: Verisign was supposed to have the users' backs. If you tried to get a cert for Amaz0n.com, it would have been rejected unless you could prove you actually are Amazon.com. True enough, but fixing that doesn't require any changes to SSL itself - you just have to curate the list of root certificates the browser trusts more carefully.
tomgirl1 13y ago
Im at a loss, but my first instinct is to say that server certs arent validated properly AT ALL, so I fail to see how client certs would do any better. For all the hype over PFS (perfect forward secrecy) I dont see how how MITM attacks are stopped because cert validation is so bad or nonexistent I dont see applying more certs (plus diffie hellman) to be a solution.
- mtrimpe 13y ago
  They're as secure as your ability to keep the private keys private, just like with server certs. As far as MITM and PFS goes; that's handled just the same as regular SSL. Using a client cert doesn't affect that at all.
  - tomgirl1 13y ago
    Which is not secure at all. you can MITM a typical SSL connection in so many ways SSL might as well not exist. No real cert validation, forged certs, proxy replays. SSL is a joke.
    - icebraining 13y ago
      Proxy replays? How so? As for cert validation / forged certs, they're only problematic because we want to authenticate a server we have never talked to before. With clients certs, the same doesn't apply: the server just needs to ensure the client is the same as the one who registered the account, so there's no need for the whole CA enchilada.
    - xnyhps 13y ago
      Most places where you can authenticate with SSL client certs allow you to add your own self-signed certificate and authenticate using that. All the validation you need is to check wether the cert is in the user's list. You can only forge that by stealing the private key. There's really no reason to only allow CA signed client certs.
      - booyahdog 13y ago
wmil 13y ago
That's just installing it on a desktop. Try installing an SSL certificate on a mobile browser.
- aroch 13y ago
  Both iOS and Android allow you to easily provision keys to a device...
  - m_ram 13y ago
    Thanks for that. In case anyone else is interested: https://support.google.com/nexus/4/answer/2844832?hl=en https://support.google.com/nexus/4/answer/2844832?hl=en
- Spooky23 13y ago
  Much easier on a smartphone managed with MDM. Some of the MDM platforms even include a pre-configured CA.
  - danielsju6 13y ago
    I've actually started open-sourcing some of my work in this space (MDM vendor here) https://github.com/AppBlade https://github.com/AppBlade my CA/SCEP implementation for iOS devices is part of TestHub [WIP]. These protocols also work for OSX boxes and you don't need full MDM to get most of the benefits, so long as you accept the .mobileconfig prompt.
- danielsju6 13y ago
  SCEP via .mobileconfig on iPhone, it's a breeze; I use client side certificates in a lot of places and the UX is transparent so long as the device doesn't contain multiple certificates.
mgkimsal 13y ago
Yes, it's true. Not sure why it's news, other than it's a new article? This has been an abomination since .... the functionality was added. It's hard even for geeks to deal with it - it makes 0 sense for non-techies to even contemplate dealing with it. Relatedly, browser UI for dealing with cookies has been abysmal since day 1 as well. Instead of making cookie information easily visisble and manageable, browser makers resorted to shifting cookie mgt stuff around in 'preferences' a few times (is it 'privacy'? or 'advanced'? why not 'cookies'?), and people champion using specific browsers with specific plugins as an optimal solution. Client certs are even worse off - few people even bother to write plugins to deal with this stuff. It's chicken/egg as well - no point in updating browsers to be better if no servers will modify their code to deal with it.
- milkmiruku 13y ago
  Anyone know the story about where browsers actually are at with these UI bugs then?
- Shish2k 13y ago
  > Instead of making cookie information easily visisble and manageable How do /you/ suggest making base64 encoded blobs of context-less ID numbers understandable to the average browser user, assuming that they could be persuaded to care in the first place? Even as a geek who knows where to look, I look at the cookies from most sites and have no idea what they mean :P
  - mgkimsal 13y ago
    doesn't particular matter if you know what they mean. A sidepanel that can open up at the click of an icon which tells me that 9 cookies were used, and they're set by google and yahoo and bing and 5 sites I've never heard of... that would give a lot of visibility immediately to people. Giving them an option of deleting/removing/blocking right from that sidepanel would empower people to be able to deal with it themselves without having to wade through scary and non-standard menus. Instead, we get a decade of ignoring this and then EU legislation that forces people to put stupid bars at the top ('we track you with cookies, click here to accept') but does pretty much nothing with respect to user education and empowerment. We have 'home' and 'reload' and 'back' and 'forward' buttons. Actually, no, my safari doesn't even have a 'home' right now, but a 'share'. Why not a 'cookie' button. Again, doesn't particularly matter whether you can decipher base64-encoded stuff or not - the average person has no clear way to even understand the number and type of cookie data being tracked, nor an easy way to block/unblock without wading through multiple levels of menus which take them away from the site they're on. Doing this on smartphones would present a challenge, but is not impossible. Doing this is desktop browsers shouldn't be all that hard. We see the data in firebug - parsing out request headers and showing the cookie data (with block/delete/allow options) in a sidebar panel would not be hard. But it won't have any real impact unless it's something built-in to multiple browsers and we have an education period. The late 90's was full of "ban cookies! reject cookies! they're evil!" hype, then we all forgot about it for a while, endured the rise of doubleclick and the like, and got legal solutions vs good UI solutions. :/ EDIT: I hit save too quick. I don't think this will ever happen - at least 2 major browser makers have a vested interest in keeping the ad-based tracking economy moving along - any built-in browser functionality which would interfere with that will never fly. I'm talking about Google and Firefox (which relies a lot on Google's wellbeing re: ad revenue). I imagine MS is in a similar boat, but maybe not to the same degree as Google. I can't speaker for Apple's potential for this, but given the webkit tie between chrome and safari, it's probably unlikely as well.
enricopulatzo 13y ago
While the UX side of things could be made quite simpler, but I think a significant hurdle for client certificates is authentication through proxies.
count 13y ago
The whole DOD is using it, but they're on crypto smart cards, so many folks don't realize that's what they're doing. Email, single sign on, web site auth, etc. Works great!
- akama 13y ago
  I would love to hear more about this. I've been looking for a good sso solution that uses crypto cards.
  - lcampbell 13y ago
    My understanding is that the private key is on a CAC card[1,2], which is issued to all DoD employees and contractors who need access to DoD resources. Readers are usually built into the keyboard, and I'm guessing that there's something similar to ssh-agent running to maintain the key until you're AFK. -- [1] http://en.wikipedia.org/wiki/Common_Access_Card http://en.wikipedia.org/wiki/Common_Access_Card [2] http://www.cac.mil/ http://www.cac.mil/
    - jleehey 13y ago
      As a DoD CAC user and developer, this is correct (although the card readers at my company are built into the laptop or inserted via a USB adapter). I don't think there is a background agent that maintains the key though, I just think the card reader is queried when the certificate is needed. After the cert has been verified, you're free to pull the card out.
      - gknoy 13y ago
        The key never leaves the smartcard: the card hardware will not allow it to be retrieved. Rather, your system has drivers which ask the card to do all of the signing operations which your system would normally do if it had access to a key.
      - snuxoll 13y ago
        > After the cert has been verified, you're free to pull the card out. Last time I checked DoD systems are configured to automatically log you out of your session upon removal of your CAC.
chrisfarms 13y ago
I think this would need a total re-think before the masses could use. I'd love to see browsers implement it by forcing people to store client certs on a USB-key or a phone by default. I think some kind of physical item that contains your keychain would be much more intuitive to many. Everyone is familiar with mechanical keys, they know not to leave them around, they know that they need them to unlock things and they know if they lose them they need to replace them.
- Cyranix 13y ago
  The analogy to mechanical keys doesn't hold up under closer scrutiny, though, right? House keys don't serve as an identity, just an access mechanism. You don't lose all future access to your house if you lose your keys; a locksmith can independently verify (with reasonable certainty) that it's okay for you to obtain a new set of keys which give access to the same house. I feel like the human predisposition to risk aversion is even more of a factor preventing adoption among average users than poor UX (not to mention lack of awareness). What do I tell my parents when they ask "What if my computer crashes? Would I not be able to log in to the website and see my stuff? What good is using a website if I can't access it from any computer?" Until something as securely portable and loss-resistant as one's own memory is achieved, I don't see passwords being less popular than any other access mechanism for the average user, no matter how significant the other downsides.
andyhmltn 13y ago
Correct me if I'm wrong, but unless they can be password protected (which defeats the object...) aren't they less secure than passwords in practice? I have a password on my phone, because I don't want people with access to it to be able to login and look at my stuff. What's to stop my friend Joe Blogs coming over my house and being able to read my email because I have one of these things installed that allows for a one-click login?
- mtrimpe 13y ago
  I don't know what browsers do, but it's fairly easy to password protect these keys. If you then keep the key accessible until some timeout (whether maximum or idle time) occurs then you've got pretty good security. That's what you already get if you use LastPass e.a.
- icebraining 13y ago
  Correct me if I'm wrong, but unless they can be password protected (which defeats the object...) aren't they less secure than passwords in practice? The most important difference is that attackers can't get it from the server and re-use it on others, since the server only needs to see the public key of the cert. Attackers can no longer break into a single server and get thousands of badly-secured passwords. Of course, secure password hashing mitigates this issue, but that means we need to trust each and every server out there to implement that correctly (not likely), while this only requires a correct implementation from the browsers.
- jlgaddis 13y ago
  > What's to stop my friend Joe Blogs coming over my house and being able to read my email ... The PIN. X.509 certificates are protected by a PIN in the same way that an SSH key pair is protected by a passphrase. Even if you "physically" obtain the private key, you still need the PIN that protects it before you can use it. (side note: you can use an X.509 certificate for SSH authentication)
enricopulatzo 13y ago
My suggestion for fixing the client cert problem is to task the browser with certificate generation upon profile creation. There are significant security implications of course, but sites aren't really incentivized to support client certificates. If 50% of my traffic already tried offering me a client cert the decision to allow them would be an easy one to make.
tptacek 13y ago
Try having two client certificates and seeing the browser UX for selecting which one to present to which site. You'll see why they aren't used. Client certificates should be much more popular in backend applications, where they're straightforward to use, flexible, and fairly trustworthy. But they're not a good end-user technology.
- jgrahamc 13y ago
  I agree that for machine to machine communication client certificates work well. Especially if you implement your own CA so you don't worry about the public infrastructure.
  - tptacek 13y ago
    If you're writing your own code for both sides, an approach that I've seen work just as well is to keep whitelists of certificate fingerprints.
- dllthomas 13y ago
  To your mind, is this more a matter of the particular UI that currently exists, or are the UX issues more fundamental to the technology?
  - tptacek 13y ago
    You can imagine a UX that would abstract certificates and their generation into a notion of accounts or personas, but the binding of those accounts to actual websites would be tricky and might involve new protocol, which is something you don't want to be doing with TLS certificates.
- makmanalp 13y ago
  Relevant classic: http://www.gaudior.net/alma/johnny.pdf http://www.gaudior.net/alma/johnny.pdf
- lotsofcows 13y ago
  Not too bad on the Mac: prompts you to pick one when required. If you use more than one cert on a single site then you need to go into Keychain Access to delete the favoured cert for site thingy to make it prompt you each time. Move client certs to their own keychain to password protect them.
arnehormann 13y ago
In theory, it's a little simpler - at least for new keys... See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke... and http://www.w3.org/TR/html5/forms.html#the-keygen-element http://www.w3.org/TR/html5/forms.html#the-keygen-element
616c 13y ago
I use it for StartSSL. It allows me to use SSL client cert auth for their OpenID instance.[0] I use it to log into StackOverflow and a few prominent sites. I like the idea of my cert provider being a trusted party for auth for other sites. However, trusting anyone other than himself in this post-PRISM era is probably a mistake. [0] http://www.startssl.com/?app=14 http://www.startssl.com/?app=14
- icebraining 13y ago
  It's so annoying that OpenID providers either support client certs or using your own domain, but never both!
  - 616c 13y ago
    I have not tried both, so I did not experience this problem. I do know SSL client certs do not work well, and wanted to work on building my own solution that does what StartSSL (an OpenID endpoint with SSL-cert based authentication). Does anyone know of ways to do this?
    - icebraining 13y ago
      Nginx supports client certs[1], so I'd say the easiest way to get started is to get some free OpenID server (SimpleID[2] seems maintaned) and configure nginx to require cert authentication to access the login path. I'd do it myself, if I used OpenID more than once every two months or so. [1]: http://nategood.com/client-side-certificate-authentication-in-ngi http://nategood.com/client-side-certificate-authentication-i... [2]: http://simpleid.koinic.net/ http://simpleid.koinic.net/
rmoriz 13y ago
Same goes for S/MIME which uses X.509, too. But S/MIME recently got traction and usability again because of OSX Mail.app and iOS mail support. People should really consider S/MIME for mail encryption as nearly every MUA (mail client) can deal with it and large institutions already use it (e.g. for SSO) https://gist.github.com/rmoriz/5945400 https://gist.github.com/rmoriz/5945400
7952 13y ago
I find it hard to believe that client certs offer much advantage over cookies for most normal web sites. Even if it was common practice you would still need some way to recover an account after loosing a certificate, at which point an email will be sent out with a password equivalent reset token, so why not just use a password? Storing certs client side just creates another target for malware, even if the certificate is password protected. You could move the certificate to a key fob, but at that point why not just use a separate second factor token? You would either have a full sense of security, or have to trust that the client machine is fully secure (impossible). It is much more sense to focus on making cookies as secure as possible by setting secure headers, and invalidating cookies that come from a machine that is different than expected.
- wmf 13y ago
  an email will be sent out with a password equivalent reset token This is not the only way to do resets and is arguably now the weakest link in authentication (just ask Matt Honan). Sometimes I imagine a world where authentication enrollment and resets are done in person.
  - 7952 13y ago
    Agreed. Although sending an SMS goes a long way to solving this.
D9u 13y ago
I love the graphics... The user responses to the settings screens are hilarious!
coda_ 13y ago
I haven't been able to get a client certificate working on Android at all (stock 4.2.2 with Chrome and Chrome Beta). Perhaps someone here has gotten them to work? I've posted in several forums and haven't found anyone that's gotten them to work.
- nicolas314 13y ago
  It definitely works with recent Chrome versions. I use this daily to check my professional webmail on an Android 4.2.2. Once you have provisioned a PKCS#12 into your keystore, open Chrome onto an HTTPS web site that requires certificates from your issuer and the certificate choice dialog pops up.
sweis 13y ago
I've seen client-side certificates work in large organizations (e.g. MIT). However, this was in the pre-smartphone era. They just had to support IE, Safari, and Firefox. That was still a pain. Today, it's much harder to support every browser and OS.
dedward 13y ago
Short answer: it's a pain in the butt.
lwf 13y ago
MIT uses it, https://ca.mit.edu/ https://ca.mit.edu/, but its a constant source of helpdesk headaches. Managing renewals and revocation is hard.
mike-cardwell 13y ago
I think the main problem is the effort of having to maintain a client certificate. I.e, backing it up and copying it on to other devices. It's so much easier to just remember a password, or write it down if you can't do that.
dclowd9901 13y ago
This is the kind of tech Bump needs to get on -- auth and identity management. They showed a way a while back to upload an image by "bumping" your phone on your keyboard. Since phones are singular and ubiquitous and have their own identifiers, your phone could essentially become a makeshift physical key. You could log into any machine, public or private, with a simple "bump" of the keyboard. So Bump, if you're listening, create a Bump Auth. Of course if you lost your phone or someone stole it, that would be problematic, but I don't anticipate you'd use this as a way to log into your bank account.
pilif 13y ago
I'm the author of this post which I have written in 2008. Since then my views have changed a bit: for one, the added security is debatable as the client cert is easily accessible to malware and thus could easily be stolen. The other thing is that renegotiation is somewhat broken since that related security flaw in 2010ish, so you can't have parts of a site accessible without client certs and other parts requiring a cert. This has been fixed since, but I don't know how well it's supported by clients. Finally, compared to 2008, we're using many more devices for accessing various web applications now. Having the client cert bound to one browser on one machine is annoying and synchronizing it truly securely is probably impossible. I do stand by the horrendous UI though. Even if the other issues weren't there, the UI certainly kills client certificates for normal users. Then again, crypto UI is hard and I'm afraid the incentive for redesigning this is pretty much zero because nobody is using it to begin with and because it's flawed anyways.
- jlgaddis 13y ago
  The U.S. government is a very large user of PKI. One is issued an identification card which is really a smart card ("common access card"[0]) with certificates on it and that is used for authentication. PKI works but "it's too {hard|much trouble}" is a frequent excuse. [0]: https://en.wikipedia.org/wiki/Common_Access_Card https://en.wikipedia.org/wiki/Common_Access_Card
- danielsju6 13y ago
  The UX on iPhone isn't so bad if you are using .mobileconfig's and there aren't conflicting certificates. I'm actually starting to open source some of my work in this space. OSX will still prompt for the certificate even if there is only one matching, but again it isn't too bad. Though in iOS 7 / Mavericks I'll probably switch to using Keberos, which will be seamlessly integrated into the Objective-C's networking APIs.
- gcb0 13y ago
  the malware point is moot. malware can steals passwords saved, which are optionally saved encrypted. the cert at least in the one browser i checked is always encrypted. and even then, if you have malware in your box, any and all security measures are worthless at this point. decent Renegotiation and mobile client support will come if people using that on the desktop request the feature. it's like that for everything for a while now. Managing the devices and revokation is also trivial. most sites does that very easily with API keys and cookies (e.g. google 2step auth, you can control which cookies are still valids for the 'remember this device' feature). the same logic could be used for client certs.
revaaron 13y ago
They're used extensively in a lot of industry- just because it isn't used for logging onto Gmail doesn't mean it isn't used elsewhere. I work in utilities and client certificates are used for all or nearly all web clients and APIs.
ninjakeyboard 13y ago
Buddy, why is nobody using SSL certs anywhere AT ALL?? Plain text passwords are sent on the login forms from sites like Hackathon.io - sites used where hundreds of people meet in a room on the same damn wifi network. RIDICULOUS!! what the hell!
NDizzle 13y ago
I used SSL client certificates with a Lotus system from 2000 to ~2011. They're still in use today, I just no longer work there. It's pretty easy maintenance once you set up systems for account managers to generate and issue new certificates for people. Then again, this was small time. Few thousand active users. Niche bio/pharma web application. Large scale it could very well be a bitch and/or unnecessary at this point in time. The system was designed/created between '96 and '98 and has used certificates the entire time.
wmf 13y ago
I see Persona as the next generation of client certs with usable UX. People are working on this problem, just not within SSL/TLS this time.
- h8trswana8 13y ago
  Sure, if you like your password going through Mozilla's server unencrypted.
  - wmf 13y ago
    Then don't use Mozilla's server. (There's a tough choice here: Persona's crutches make it much easier to deploy incrementally, but there's no incentive to ever get off the crutches and people think that the crutches are Persona.)
  - steveklabnik 13y ago
    BrowserID requires nothing from Mozilla. They of course offer a public server so that you don't have to run your own server if you don't want to, but it's entirely, 100% optional.
throw7 13y ago
I would think getting your cert signed by a CA is a significant barrier to entry also.
conexions 13y ago
I always wished we could use SSL the way we use phisycal keys. They are a very good example encapsulization and easy user interface. When you use the key for your house, you look for a certian color or shape of the key. Most users don't know or care how the lock works. Why can't SSL be this way. Instead of having the end user chose a password have the browser automaticaly generate a public/private pair. For the user interface make a key with a random or user generated design. When the user goes to the website again present the user with a list of their keys and have them chose the correct one.
- keeperofdakeys 13y ago
  The first part, moving authentication from the user to the browser, is exactly what Mozilla's Persona is about. However, the whole "multiple device" thing kind of kills browser-level authentication (persona gets around this by allowing email accounts).
njharman 13y ago
> basic authentication (nobody uses this one) Huh? I use that all the time.
nstielau 13y ago
We are using client-side SSL certificates extensively for API as well as browser-based single-sign-on for 20+ employees on a smattering of Mac/Linux/iPhone/Android devices. Definitely some ramp-up and wonkiness, but it's working well. Also worth noting that infrastructure components like Cassandra [1] and RabbitMQ [2] leverage PKI as well. Checkout our Jenkins client-side SSL cert auth plugin: https://github.com/pantheon-systems/certificate-authentication-for-jenkins https://github.com/pantheon-systems/certificate-authenticati... [1] http://www.datastax.com/documentation/cassandra/1.2/index.html#cassandra/security/secureSSLCertificates_t.html http://www.datastax.com/documentation/cassandra/1.2/index.ht... [2] http://www.rabbitmq.com/ssl.html http://www.rabbitmq.com/ssl.html
joshuaellinger 13y ago
The reason I would like a client certificate solution that worked (even if it was a malware target) is that I could reject all web traffic to my applications if they came in without a cert. It would decrease my public footprint dramatically. I don't mind approving a user once per device. We've got to set them up anyway.
- marshray 13y ago
  Use client certs then? Why do you feel current solutions don't work?
  - joshuaellinger 13y ago
    Setup is still too painful even with direct support.
bonaldi 13y ago
We use these at work, and once set up they're a breeze. But that's a big "once". It also makes life needlessly difficult if you want to log in to something from a new/borrowed/etc PC and don't have the keys handy. Where needlessly = near-impossible.
rpug 13y ago
The guys at CryoKey (https://www.cryokey.com/ https://www.cryokey.com/) are basically trying to do this. I haven't personally used it, though.
davidu 13y ago
We use client-side PKI and certs, not just with employees, but with customers, at OpenDNS. Works well, is a very strong added factor, and is easy to manage and deploy these days.
- clarkevans 13y ago
  What tool(s) do you use to manage your CA? Overall, this is one of the bigger challenges... I don't know of any open source project (or even SaaS) that implements a full CA workflow including signup, approval, revocation, etc.
superuser2 13y ago
It's worth noting that MIT uses these. New students are provisioned client certs, which are accepted for login to institutional websites and even Apple's MIT student discount page. Not sure if any other universities are using this.
- vabmit 13y ago
  Yes. But, it's worth adding that MIT also uses a Shibboleth implementation (locally called Touchstone). On many core sites Touchstone handles authentication to the specific web servers. Touchstone itself can be authenticated to with either the individual X509 client cert or their password. Many people use password authentication to with the Touchstone server even though MIT has a website that (usually successfully)auto generates and installs the certificate in the user's browser.
  - krilnon 13y ago
    Any idea how many people primarily use passwords? Personally, I've always found it really convenient to use certs for MIT and CSAIL stuff.
AsymetricCom 13y ago
No or insignificant economic incentives.
hpagey 13y ago
Client certificates won't work well if you are trying to authenticated against services inside the corporate network (sharepoint, microsoft exchange, AD) and your connection passes through proxies such as Microsoft TMG. Your SSL connection will be terminated at such a proxy and you will have to setup kerberos or impersonation. It is doable just tricky to setup.
jpalomaki 13y ago
Using the TPM to store the client certificates would prevent malware from stealing them. I have no experience on this, but quick search revealed something[1]. Maybe one use for securely stored client side certs would to mark the computer as trusted. For example now Google is probably using cookies to determine that my desktop is trusted and thus I don't need the two-factor authentication to log in. TPM and client side certs could provide more secure alternative for this. [1] http://blog.habets.pp.se/2012/02/TPM-backed-SSL http://blog.habets.pp.se/2012/02/TPM-backed-SSL
lessnonymous 13y ago
Anyone know of a good tutorial for using client certificates for (2nd factor) authentication? A quick Google search brings up nothing useful.
contingencies 13y ago
Had to deal with this once or twice for some integrations. It's a PITA for little additional security. Often you can just use a VPN or IP restriction instead.
deleted 13y ago
[deleted]
captainmuon 13y ago
CERN (and other research facilities) use these a lot, to manage access to their internal websites and to the grid (the distributed computing platform). IIRC, you have a cern account, and generate a short-term certificate with which you work. You can use it to submit jobs into the grid, but you can also import it into the browser to access e.g. grid monitoring software, or internal wikis. The idea is that in the worst case that you lose the certificate to a hacker, it can be revoked quickly without having to block your whole account. The last time I checked (haven't worked with CERN's computers or the grid for a while), it was pretty user-unfriendly. Obscure shell scripts for everything. It hopefully improved since then. OTOH, it's probably good enough for programmers and researchers.
deleted 13y ago
[deleted]
christefano 13y ago
I'm surprised no one has mentioned WebID yet: > http://webid.info/ http://webid.info/ WebID works (I saw it demoed at a meetup earlier this year), though I'm not sure how popular — or unpopular — it is.

241 points by cottonseed 13y ago

joshuaellinger 13y ago

Yep -- too hard to setup. A really good browser enhancement would be 1-click client side certificate setup.

evilpie 13y ago
Pretty sure that you could write an Firefox addon for this.
deleted 13y ago
[deleted]

lmm 13y ago

The key management tools are awful. People complain about the complexity of PGP but at least there it's one-click to export a key, look at the details of it, sign someone else's key etc. But yeah, it would be nice to use this tech rather than reinventing the wheel. The underlying implementation is sound.

area51org 13y ago
The whole system, now close to 20 years old, needs a reboot. I know, that's easy for me to say. But it's showing its age, and could really benefit from a complete rethink.
- lmm 13y ago
  Do you have specific criticisms? In cryptography, a system that has withstood scrutiny for that long is a rare and exceedingly valuable thing. By all means use it as the ugly foundations that you hide beneath the beautiful edifice on top, but throwing it away would be madness.
  - area51org 13y ago
    You're right, I'm being vague. I'm looking for two things, really: 1- simpler implementation — one that is easier for users to understand, and includes client certs by default 2- one with a re-engineered cryptographic implementation, one less likely to have the kind of numerous security flaws that have been uncovered in SSL/TLS over the years SSL was originally meant to serve two purposes: 1- encrypt communication 2- verify, through a trusted 3rd party, that the remote service you're contacting is actually who it says it is Most laymen, and many technologists, do not know that #2 even exists. Worse, this authentication portion has been all but destroyed by liberal certificate authorities like GoDaddy. From my experience, anyone can get a certificate for a domain without any kind of check to see if you have the right to use that domain. So, in theory, you could register "amaz0n.com" with GoDaddy, get a cert for it, and start using it, without any kind of background check. In the early days (when Verisign was the only CA in town), a business had to supply a Dunn & Bradstreet number and be subject to other background checking before being issued a CA-signed cert. If that sounds heavy-handed, it shouldn't: Verisign was supposed to have the users' backs. If you tried to get a cert for Amaz0n.com, it would have been rejected unless you could prove you actually are Amazon.com. I think that kind of authentication has a real place on the modern Internet. edit: formatting
    - lmm 13y ago
      >1- simpler implementation — one that is easier for users to understand, and includes client certs by default I'm not sure what you're suggesting. A nicer UI would definitely be a good idea, but you can do that without changing the underlying crypto implementation. >2- one with a re-engineered cryptographic implementation, one less likely to have the kind of numerous security flaws that have been uncovered in SSL/TLS over the years That's not how you get secure cryptography. You need not just a secure algorithm but a secure implementation, one resistant to timing attacks, compression attacks, and all sorts of nonobvious things. OpenSSL is far from developer-friendly, but the vulnerabilities have been hammered out over those 20 years, and there is a body of knowledge on how to use it securely. A new implementation would have to go through that all over again. >From my experience, anyone can get a certificate for a domain without any kind of check to see if you have the right to use that domain. So, in theory, you could register "amaz0n.com" with GoDaddy, get a cert for it, and start using it, without any kind of background check. In the early days (when Verisign was the only CA in town), a business had to supply a Dunn & Bradstreet number and be subject to other background checking before being issued a CA-signed cert. If that sounds heavy-handed, it shouldn't: Verisign was supposed to have the users' backs. If you tried to get a cert for Amaz0n.com, it would have been rejected unless you could prove you actually are Amazon.com. True enough, but fixing that doesn't require any changes to SSL itself - you just have to curate the list of root certificates the browser trusts more carefully.

tomgirl1 13y ago

Im at a loss, but my first instinct is to say that server certs arent validated properly AT ALL, so I fail to see how client certs would do any better. For all the hype over PFS (perfect forward secrecy) I dont see how how MITM attacks are stopped because cert validation is so bad or nonexistent I dont see applying more certs (plus diffie hellman) to be a solution.

mtrimpe 13y ago
They're as secure as your ability to keep the private keys private, just like with server certs. As far as MITM and PFS goes; that's handled just the same as regular SSL. Using a client cert doesn't affect that at all.
- tomgirl1 13y ago
  Which is not secure at all. you can MITM a typical SSL connection in so many ways SSL might as well not exist. No real cert validation, forged certs, proxy replays. SSL is a joke.
  - icebraining 13y ago
    Proxy replays? How so? As for cert validation / forged certs, they're only problematic because we want to authenticate a server we have never talked to before. With clients certs, the same doesn't apply: the server just needs to ensure the client is the same as the one who registered the account, so there's no need for the whole CA enchilada.
  - xnyhps 13y ago
    Most places where you can authenticate with SSL client certs allow you to add your own self-signed certificate and authenticate using that. All the validation you need is to check wether the cert is in the user's list. You can only forge that by stealing the private key. There's really no reason to only allow CA signed client certs.
    - booyahdog 13y ago

wmil 13y ago

That's just installing it on a desktop. Try installing an SSL certificate on a mobile browser.

aroch 13y ago
Both iOS and Android allow you to easily provision keys to a device...
- m_ram 13y ago
  Thanks for that. In case anyone else is interested: https://support.google.com/nexus/4/answer/2844832?hl=en https://support.google.com/nexus/4/answer/2844832?hl=en
Spooky23 13y ago
Much easier on a smartphone managed with MDM. Some of the MDM platforms even include a pre-configured CA.
- danielsju6 13y ago
  I've actually started open-sourcing some of my work in this space (MDM vendor here) https://github.com/AppBlade https://github.com/AppBlade my CA/SCEP implementation for iOS devices is part of TestHub [WIP]. These protocols also work for OSX boxes and you don't need full MDM to get most of the benefits, so long as you accept the .mobileconfig prompt.
danielsju6 13y ago
SCEP via .mobileconfig on iPhone, it's a breeze; I use client side certificates in a lot of places and the UX is transparent so long as the device doesn't contain multiple certificates.

mgkimsal 13y ago

Yes, it's true. Not sure why it's news, other than it's a new article? This has been an abomination since .... the functionality was added. It's hard even for geeks to deal with it - it makes 0 sense for non-techies to even contemplate dealing with it. Relatedly, browser UI for dealing with cookies has been abysmal since day 1 as well. Instead of making cookie information easily visisble and manageable, browser makers resorted to shifting cookie mgt stuff around in 'preferences' a few times (is it 'privacy'? or 'advanced'? why not 'cookies'?), and people champion using specific browsers with specific plugins as an optimal solution. Client certs are even worse off - few people even bother to write plugins to deal with this stuff. It's chicken/egg as well - no point in updating browsers to be better if no servers will modify their code to deal with it.

milkmiruku 13y ago
Anyone know the story about where browsers actually are at with these UI bugs then?
Shish2k 13y ago
> Instead of making cookie information easily visisble and manageable How do /you/ suggest making base64 encoded blobs of context-less ID numbers understandable to the average browser user, assuming that they could be persuaded to care in the first place? Even as a geek who knows where to look, I look at the cookies from most sites and have no idea what they mean :P
- mgkimsal 13y ago
  doesn't particular matter if you know what they mean. A sidepanel that can open up at the click of an icon which tells me that 9 cookies were used, and they're set by google and yahoo and bing and 5 sites I've never heard of... that would give a lot of visibility immediately to people. Giving them an option of deleting/removing/blocking right from that sidepanel would empower people to be able to deal with it themselves without having to wade through scary and non-standard menus. Instead, we get a decade of ignoring this and then EU legislation that forces people to put stupid bars at the top ('we track you with cookies, click here to accept') but does pretty much nothing with respect to user education and empowerment. We have 'home' and 'reload' and 'back' and 'forward' buttons. Actually, no, my safari doesn't even have a 'home' right now, but a 'share'. Why not a 'cookie' button. Again, doesn't particularly matter whether you can decipher base64-encoded stuff or not - the average person has no clear way to even understand the number and type of cookie data being tracked, nor an easy way to block/unblock without wading through multiple levels of menus which take them away from the site they're on. Doing this on smartphones would present a challenge, but is not impossible. Doing this is desktop browsers shouldn't be all that hard. We see the data in firebug - parsing out request headers and showing the cookie data (with block/delete/allow options) in a sidebar panel would not be hard. But it won't have any real impact unless it's something built-in to multiple browsers and we have an education period. The late 90's was full of "ban cookies! reject cookies! they're evil!" hype, then we all forgot about it for a while, endured the rise of doubleclick and the like, and got legal solutions vs good UI solutions. :/ EDIT: I hit save too quick. I don't think this will ever happen - at least 2 major browser makers have a vested interest in keeping the ad-based tracking economy moving along - any built-in browser functionality which would interfere with that will never fly. I'm talking about Google and Firefox (which relies a lot on Google's wellbeing re: ad revenue). I imagine MS is in a similar boat, but maybe not to the same degree as Google. I can't speaker for Apple's potential for this, but given the webkit tie between chrome and safari, it's probably unlikely as well.

enricopulatzo 13y ago

While the UX side of things could be made quite simpler, but I think a significant hurdle for client certificates is authentication through proxies.

count 13y ago

The whole DOD is using it, but they're on crypto smart cards, so many folks don't realize that's what they're doing. Email, single sign on, web site auth, etc. Works great!

akama 13y ago
I would love to hear more about this. I've been looking for a good sso solution that uses crypto cards.
- lcampbell 13y ago
  My understanding is that the private key is on a CAC card[1,2], which is issued to all DoD employees and contractors who need access to DoD resources. Readers are usually built into the keyboard, and I'm guessing that there's something similar to ssh-agent running to maintain the key until you're AFK. -- [1] http://en.wikipedia.org/wiki/Common_Access_Card http://en.wikipedia.org/wiki/Common_Access_Card [2] http://www.cac.mil/ http://www.cac.mil/
  - jleehey 13y ago
    As a DoD CAC user and developer, this is correct (although the card readers at my company are built into the laptop or inserted via a USB adapter). I don't think there is a background agent that maintains the key though, I just think the card reader is queried when the certificate is needed. After the cert has been verified, you're free to pull the card out.
    - gknoy 13y ago
      The key never leaves the smartcard: the card hardware will not allow it to be retrieved. Rather, your system has drivers which ask the card to do all of the signing operations which your system would normally do if it had access to a key.
    - snuxoll 13y ago
      > After the cert has been verified, you're free to pull the card out. Last time I checked DoD systems are configured to automatically log you out of your session upon removal of your CAC.

chrisfarms 13y ago

I think this would need a total re-think before the masses could use. I'd love to see browsers implement it by forcing people to store client certs on a USB-key or a phone by default. I think some kind of physical item that contains your keychain would be much more intuitive to many. Everyone is familiar with mechanical keys, they know not to leave them around, they know that they need them to unlock things and they know if they lose them they need to replace them.

Cyranix 13y ago
The analogy to mechanical keys doesn't hold up under closer scrutiny, though, right? House keys don't serve as an identity, just an access mechanism. You don't lose all future access to your house if you lose your keys; a locksmith can independently verify (with reasonable certainty) that it's okay for you to obtain a new set of keys which give access to the same house. I feel like the human predisposition to risk aversion is even more of a factor preventing adoption among average users than poor UX (not to mention lack of awareness). What do I tell my parents when they ask "What if my computer crashes? Would I not be able to log in to the website and see my stuff? What good is using a website if I can't access it from any computer?" Until something as securely portable and loss-resistant as one's own memory is achieved, I don't see passwords being less popular than any other access mechanism for the average user, no matter how significant the other downsides.

andyhmltn 13y ago

Correct me if I'm wrong, but unless they can be password protected (which defeats the object...) aren't they less secure than passwords in practice? I have a password on my phone, because I don't want people with access to it to be able to login and look at my stuff. What's to stop my friend Joe Blogs coming over my house and being able to read my email because I have one of these things installed that allows for a one-click login?

mtrimpe 13y ago
I don't know what browsers do, but it's fairly easy to password protect these keys. If you then keep the key accessible until some timeout (whether maximum or idle time) occurs then you've got pretty good security. That's what you already get if you use LastPass e.a.
icebraining 13y ago
Correct me if I'm wrong, but unless they can be password protected (which defeats the object...) aren't they less secure than passwords in practice? The most important difference is that attackers can't get it from the server and re-use it on others, since the server only needs to see the public key of the cert. Attackers can no longer break into a single server and get thousands of badly-secured passwords. Of course, secure password hashing mitigates this issue, but that means we need to trust each and every server out there to implement that correctly (not likely), while this only requires a correct implementation from the browsers.
jlgaddis 13y ago
> What's to stop my friend Joe Blogs coming over my house and being able to read my email ... The PIN. X.509 certificates are protected by a PIN in the same way that an SSH key pair is protected by a passphrase. Even if you "physically" obtain the private key, you still need the PIN that protects it before you can use it. (side note: you can use an X.509 certificate for SSH authentication)

enricopulatzo 13y ago

My suggestion for fixing the client cert problem is to task the browser with certificate generation upon profile creation. There are significant security implications of course, but sites aren't really incentivized to support client certificates. If 50% of my traffic already tried offering me a client cert the decision to allow them would be an easy one to make.

tptacek 13y ago

Try having two client certificates and seeing the browser UX for selecting which one to present to which site. You'll see why they aren't used. Client certificates should be much more popular in backend applications, where they're straightforward to use, flexible, and fairly trustworthy. But they're not a good end-user technology.

jgrahamc 13y ago
I agree that for machine to machine communication client certificates work well. Especially if you implement your own CA so you don't worry about the public infrastructure.
- tptacek 13y ago
  If you're writing your own code for both sides, an approach that I've seen work just as well is to keep whitelists of certificate fingerprints.
dllthomas 13y ago
To your mind, is this more a matter of the particular UI that currently exists, or are the UX issues more fundamental to the technology?
- tptacek 13y ago
  You can imagine a UX that would abstract certificates and their generation into a notion of accounts or personas, but the binding of those accounts to actual websites would be tricky and might involve new protocol, which is something you don't want to be doing with TLS certificates.
makmanalp 13y ago
Relevant classic: http://www.gaudior.net/alma/johnny.pdf http://www.gaudior.net/alma/johnny.pdf
lotsofcows 13y ago
Not too bad on the Mac: prompts you to pick one when required. If you use more than one cert on a single site then you need to go into Keychain Access to delete the favoured cert for site thingy to make it prompt you each time. Move client certs to their own keychain to password protect them.

arnehormann 13y ago

In theory, it's a little simpler - at least for new keys... See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke... and http://www.w3.org/TR/html5/forms.html#the-keygen-element http://www.w3.org/TR/html5/forms.html#the-keygen-element

616c 13y ago

I use it for StartSSL. It allows me to use SSL client cert auth for their OpenID instance.[0] I use it to log into StackOverflow and a few prominent sites. I like the idea of my cert provider being a trusted party for auth for other sites. However, trusting anyone other than himself in this post-PRISM era is probably a mistake. [0] http://www.startssl.com/?app=14 http://www.startssl.com/?app=14

icebraining 13y ago
It's so annoying that OpenID providers either support client certs or using your own domain, but never both!
- 616c 13y ago
  I have not tried both, so I did not experience this problem. I do know SSL client certs do not work well, and wanted to work on building my own solution that does what StartSSL (an OpenID endpoint with SSL-cert based authentication). Does anyone know of ways to do this?
  - icebraining 13y ago
    Nginx supports client certs[1], so I'd say the easiest way to get started is to get some free OpenID server (SimpleID[2] seems maintaned) and configure nginx to require cert authentication to access the login path. I'd do it myself, if I used OpenID more than once every two months or so. [1]: http://nategood.com/client-side-certificate-authentication-in-ngi http://nategood.com/client-side-certificate-authentication-i... [2]: http://simpleid.koinic.net/ http://simpleid.koinic.net/

rmoriz 13y ago

Same goes for S/MIME which uses X.509, too. But S/MIME recently got traction and usability again because of OSX Mail.app and iOS mail support. People should really consider S/MIME for mail encryption as nearly every MUA (mail client) can deal with it and large institutions already use it (e.g. for SSO) https://gist.github.com/rmoriz/5945400 https://gist.github.com/rmoriz/5945400

7952 13y ago

I find it hard to believe that client certs offer much advantage over cookies for most normal web sites. Even if it was common practice you would still need some way to recover an account after loosing a certificate, at which point an email will be sent out with a password equivalent reset token, so why not just use a password? Storing certs client side just creates another target for malware, even if the certificate is password protected. You could move the certificate to a key fob, but at that point why not just use a separate second factor token? You would either have a full sense of security, or have to trust that the client machine is fully secure (impossible). It is much more sense to focus on making cookies as secure as possible by setting secure headers, and invalidating cookies that come from a machine that is different than expected.

wmf 13y ago
an email will be sent out with a password equivalent reset token This is not the only way to do resets and is arguably now the weakest link in authentication (just ask Matt Honan). Sometimes I imagine a world where authentication enrollment and resets are done in person.
- 7952 13y ago
  Agreed. Although sending an SMS goes a long way to solving this.

D9u 13y ago

I love the graphics... The user responses to the settings screens are hilarious!

coda_ 13y ago

I haven't been able to get a client certificate working on Android at all (stock 4.2.2 with Chrome and Chrome Beta). Perhaps someone here has gotten them to work? I've posted in several forums and haven't found anyone that's gotten them to work.

nicolas314 13y ago
It definitely works with recent Chrome versions. I use this daily to check my professional webmail on an Android 4.2.2. Once you have provisioned a PKCS#12 into your keystore, open Chrome onto an HTTPS web site that requires certificates from your issuer and the certificate choice dialog pops up.

sweis 13y ago

I've seen client-side certificates work in large organizations (e.g. MIT). However, this was in the pre-smartphone era. They just had to support IE, Safari, and Firefox. That was still a pain. Today, it's much harder to support every browser and OS.

dedward 13y ago

Short answer: it's a pain in the butt.

lwf 13y ago

MIT uses it, https://ca.mit.edu/ https://ca.mit.edu/, but its a constant source of helpdesk headaches. Managing renewals and revocation is hard.

mike-cardwell 13y ago

I think the main problem is the effort of having to maintain a client certificate. I.e, backing it up and copying it on to other devices. It's so much easier to just remember a password, or write it down if you can't do that.

dclowd9901 13y ago

This is the kind of tech Bump needs to get on -- auth and identity management. They showed a way a while back to upload an image by "bumping" your phone on your keyboard. Since phones are singular and ubiquitous and have their own identifiers, your phone could essentially become a makeshift physical key. You could log into any machine, public or private, with a simple "bump" of the keyboard. So Bump, if you're listening, create a Bump Auth. Of course if you lost your phone or someone stole it, that would be problematic, but I don't anticipate you'd use this as a way to log into your bank account.

pilif 13y ago

I'm the author of this post which I have written in 2008. Since then my views have changed a bit: for one, the added security is debatable as the client cert is easily accessible to malware and thus could easily be stolen. The other thing is that renegotiation is somewhat broken since that related security flaw in 2010ish, so you can't have parts of a site accessible without client certs and other parts requiring a cert. This has been fixed since, but I don't know how well it's supported by clients. Finally, compared to 2008, we're using many more devices for accessing various web applications now. Having the client cert bound to one browser on one machine is annoying and synchronizing it truly securely is probably impossible. I do stand by the horrendous UI though. Even if the other issues weren't there, the UI certainly kills client certificates for normal users. Then again, crypto UI is hard and I'm afraid the incentive for redesigning this is pretty much zero because nobody is using it to begin with and because it's flawed anyways.

jlgaddis 13y ago
The U.S. government is a very large user of PKI. One is issued an identification card which is really a smart card ("common access card"[0]) with certificates on it and that is used for authentication. PKI works but "it's too {hard|much trouble}" is a frequent excuse. [0]: https://en.wikipedia.org/wiki/Common_Access_Card https://en.wikipedia.org/wiki/Common_Access_Card
danielsju6 13y ago
The UX on iPhone isn't so bad if you are using .mobileconfig's and there aren't conflicting certificates. I'm actually starting to open source some of my work in this space. OSX will still prompt for the certificate even if there is only one matching, but again it isn't too bad. Though in iOS 7 / Mavericks I'll probably switch to using Keberos, which will be seamlessly integrated into the Objective-C's networking APIs.
gcb0 13y ago
the malware point is moot. malware can steals passwords saved, which are optionally saved encrypted. the cert at least in the one browser i checked is always encrypted. and even then, if you have malware in your box, any and all security measures are worthless at this point. decent Renegotiation and mobile client support will come if people using that on the desktop request the feature. it's like that for everything for a while now. Managing the devices and revokation is also trivial. most sites does that very easily with API keys and cookies (e.g. google 2step auth, you can control which cookies are still valids for the 'remember this device' feature). the same logic could be used for client certs.

revaaron 13y ago

They're used extensively in a lot of industry- just because it isn't used for logging onto Gmail doesn't mean it isn't used elsewhere. I work in utilities and client certificates are used for all or nearly all web clients and APIs.

ninjakeyboard 13y ago

Buddy, why is nobody using SSL certs anywhere AT ALL?? Plain text passwords are sent on the login forms from sites like Hackathon.io - sites used where hundreds of people meet in a room on the same damn wifi network. RIDICULOUS!! what the hell!

NDizzle 13y ago

I used SSL client certificates with a Lotus system from 2000 to ~2011. They're still in use today, I just no longer work there. It's pretty easy maintenance once you set up systems for account managers to generate and issue new certificates for people. Then again, this was small time. Few thousand active users. Niche bio/pharma web application. Large scale it could very well be a bitch and/or unnecessary at this point in time. The system was designed/created between '96 and '98 and has used certificates the entire time.

wmf 13y ago

I see Persona as the next generation of client certs with usable UX. People are working on this problem, just not within SSL/TLS this time.

h8trswana8 13y ago
Sure, if you like your password going through Mozilla's server unencrypted.
- wmf 13y ago
  Then don't use Mozilla's server. (There's a tough choice here: Persona's crutches make it much easier to deploy incrementally, but there's no incentive to ever get off the crutches and people think that the crutches are Persona.)
- steveklabnik 13y ago
  BrowserID requires nothing from Mozilla. They of course offer a public server so that you don't have to run your own server if you don't want to, but it's entirely, 100% optional.

throw7 13y ago

I would think getting your cert signed by a CA is a significant barrier to entry also.

conexions 13y ago

I always wished we could use SSL the way we use phisycal keys. They are a very good example encapsulization and easy user interface. When you use the key for your house, you look for a certian color or shape of the key. Most users don't know or care how the lock works. Why can't SSL be this way. Instead of having the end user chose a password have the browser automaticaly generate a public/private pair. For the user interface make a key with a random or user generated design. When the user goes to the website again present the user with a list of their keys and have them chose the correct one.

keeperofdakeys 13y ago
The first part, moving authentication from the user to the browser, is exactly what Mozilla's Persona is about. However, the whole "multiple device" thing kind of kills browser-level authentication (persona gets around this by allowing email accounts).

njharman 13y ago

> basic authentication (nobody uses this one) Huh? I use that all the time.

nstielau 13y ago

We are using client-side SSL certificates extensively for API as well as browser-based single-sign-on for 20+ employees on a smattering of Mac/Linux/iPhone/Android devices. Definitely some ramp-up and wonkiness, but it's working well. Also worth noting that infrastructure components like Cassandra [1] and RabbitMQ [2] leverage PKI as well. Checkout our Jenkins client-side SSL cert auth plugin: https://github.com/pantheon-systems/certificate-authentication-for-jenkins https://github.com/pantheon-systems/certificate-authenticati... [1] http://www.datastax.com/documentation/cassandra/1.2/index.html#cassandra/security/secureSSLCertificates_t.html http://www.datastax.com/documentation/cassandra/1.2/index.ht... [2] http://www.rabbitmq.com/ssl.html http://www.rabbitmq.com/ssl.html

joshuaellinger 13y ago

The reason I would like a client certificate solution that worked (even if it was a malware target) is that I could reject all web traffic to my applications if they came in without a cert. It would decrease my public footprint dramatically. I don't mind approving a user once per device. We've got to set them up anyway.

marshray 13y ago
Use client certs then? Why do you feel current solutions don't work?
- joshuaellinger 13y ago
  Setup is still too painful even with direct support.

bonaldi 13y ago

We use these at work, and once set up they're a breeze. But that's a big "once". It also makes life needlessly difficult if you want to log in to something from a new/borrowed/etc PC and don't have the keys handy. Where needlessly = near-impossible.

rpug 13y ago

The guys at CryoKey (https://www.cryokey.com/ https://www.cryokey.com/) are basically trying to do this. I haven't personally used it, though.

davidu 13y ago

We use client-side PKI and certs, not just with employees, but with customers, at OpenDNS. Works well, is a very strong added factor, and is easy to manage and deploy these days.

clarkevans 13y ago
What tool(s) do you use to manage your CA? Overall, this is one of the bigger challenges... I don't know of any open source project (or even SaaS) that implements a full CA workflow including signup, approval, revocation, etc.

superuser2 13y ago

It's worth noting that MIT uses these. New students are provisioned client certs, which are accepted for login to institutional websites and even Apple's MIT student discount page. Not sure if any other universities are using this.

vabmit 13y ago
Yes. But, it's worth adding that MIT also uses a Shibboleth implementation (locally called Touchstone). On many core sites Touchstone handles authentication to the specific web servers. Touchstone itself can be authenticated to with either the individual X509 client cert or their password. Many people use password authentication to with the Touchstone server even though MIT has a website that (usually successfully)auto generates and installs the certificate in the user's browser.
- krilnon 13y ago
  Any idea how many people primarily use passwords? Personally, I've always found it really convenient to use certs for MIT and CSAIL stuff.

AsymetricCom 13y ago

No or insignificant economic incentives.

hpagey 13y ago

Client certificates won't work well if you are trying to authenticated against services inside the corporate network (sharepoint, microsoft exchange, AD) and your connection passes through proxies such as Microsoft TMG. Your SSL connection will be terminated at such a proxy and you will have to setup kerberos or impersonation. It is doable just tricky to setup.

jpalomaki 13y ago

Using the TPM to store the client certificates would prevent malware from stealing them. I have no experience on this, but quick search revealed something[1]. Maybe one use for securely stored client side certs would to mark the computer as trusted. For example now Google is probably using cookies to determine that my desktop is trusted and thus I don't need the two-factor authentication to log in. TPM and client side certs could provide more secure alternative for this. [1] http://blog.habets.pp.se/2012/02/TPM-backed-SSL http://blog.habets.pp.se/2012/02/TPM-backed-SSL

lessnonymous 13y ago

Anyone know of a good tutorial for using client certificates for (2nd factor) authentication? A quick Google search brings up nothing useful.

contingencies 13y ago

Had to deal with this once or twice for some integrations. It's a PITA for little additional security. Often you can just use a VPN or IP restriction instead.

deleted 13y ago

[deleted]

captainmuon 13y ago

CERN (and other research facilities) use these a lot, to manage access to their internal websites and to the grid (the distributed computing platform). IIRC, you have a cern account, and generate a short-term certificate with which you work. You can use it to submit jobs into the grid, but you can also import it into the browser to access e.g. grid monitoring software, or internal wikis. The idea is that in the worst case that you lose the certificate to a hacker, it can be revoked quickly without having to block your whole account. The last time I checked (haven't worked with CERN's computers or the grid for a while), it was pretty user-unfriendly. Obscure shell scripts for everything. It hopefully improved since then. OTOH, it's probably good enough for programmers and researchers.

deleted 13y ago

[deleted]

christefano 13y ago

I'm surprised no one has mentioned WebID yet: > http://webid.info/ http://webid.info/ WebID works (I saw it demoed at a meetup earlier this year), though I'm not sure how popular — or unpopular — it is.