1. 32
  1. 25

    From time to time this seems to pop up, and they talked as if it was never tried at big scale. But it’s wrong, it has been already tried. In my country, Spain, every citizen has a digital certificate (request process is tedious, you need a Java program and a going physically to some places) but you can use it at any bureaucratic thing, including paying taxes, buying national debt, request certificates from the judge, … But also you can use it on some banks and even in my university. I, as a user, think that it has some real benefits but also some cons.

    However, in the end, most people don’t like the workflow. Administrations have put login/password systems for the most commonly used services because of the request process, how to secure the certificates, how to move them between computers and so on it’s complicated. Also, the web browser interfaces are bad and scary, and for a lot of the time, some browsers (Firefox looking at you) rejected the certificates as invalid (Chrome and IE did just fine).

    Some other people prefer the electronic ID card, which is similar but you need special hardware, but in the end people reason about that as easier than a pure digital certificate.

    1. 4

      Do you think it would be better with a USB smart-card such as a Yubikey or something similar? IMO any system that expects a user to know how to secure and use a certificate file is a bad system, but it’s a usability problem, not really a technical one.

      1. 7

        That’s basically WebAuthentication.

        1. 1

          I’m talking like a government issued USB smartcard or hardware token, not the APIs that would use those tokens.

          1. 2

            I believe this is what Estonia does with “e-Estonia”; I don’t really know of the details though.

            1. 2

              Yes – we get an ID card which is also a smartcard. You use it with something like this, and you can authenticate and sign using two different PINs on it. It uses the normal smartcard APIs so it tends to Just Work in browsers on major operating systems. They recently introduced a smartphone version that you can use alongside, but you need to register first using either the smartcard or visiting a bank.

        2. 3

          Sweden’s Bank ID makes managing certificates really easy. I use it to authenticate to everything from my bank, the tax authority, my company’s payroll software, and our kid’s school’s attendancy interface.

          The certificates are handled via my bank. The initial startup requires an personal visit with ID, after that you get a reminder every few years that it’s time to renew.


          1. 2

            Same in Luxembourg with https://www.luxtrust.lu/ it works really well and you have the start card version (mostly for corporate) and the 2FA version.

            1. 1

              Looks very similar but instead of government-issued, they’re bank-issued :)

              1. 2

                Here in Sweden, the traditional issuers of ID cards have been banks. It’s changed now since the rules around passports have tightened, so the government offers a “national ID card” in addition to a passport (which is now accepted as ID - it used not to be up to the standards of ID cards).

                You do need a bank “partnership” (usually a checking account) but these are easy to get, and free up until you’re starting to earn some money. Our kid got an account, debit card and a Bank ID at 16.

            2. 1

              Yes, the electronic ID card I was talking at the end is a SmartCard with password protection, but you need a reader and (another) Java program in the middle. If you forget your password you can go to the police office and they have machines that reset the password. It is not perfect but it feels more natural for regular users.

            3. 1

              In Poland it’s other way around - you may use your bank account as some sort of id. It works surprisingly well, some formalities may be done using your bank’s interface.

              1. 1

                It may not have worked out that well in Spain, but in Estonia it seems to be working well (from the outside, at least. Any Estonians can feel free to correct me). I don’t like how much information is stored in the ID, but the digital signature and ID verification seems to work well, at least according to Wikipedia https://en.wikipedia.org/wiki/Estonian_identity_card#Uses_for_identification

                1. 1

                  The identity card of Estonia and the one from Spain are the same model! When a security bug was discovered in Estonia they needed to invalidate a whole bunch of cards here, because they were the same :) However, the physical smartcard and the pure client-side certificate (which the post was talking about) are two related but different systems (which I think complicates more its understanding for the normal citizen). The smartcard flow is not really standard, needs a Java program in the middle.

              2. 10

                Seconding @msw’s point here that when it was tried for web apps (a long while ago), a big source of confusion in users:

                • Portability of a cert (in comparison with “just a password”, which was the only alternative back then.
                • operational security concerns with certificates as files on disk.
                • revocation is a mess (really!)

                Besides, there was no great mechanism to “prompt” for a certificate in the HTTP stack, so client certificates used to be offered for a lot of HTTPS connection which was a huge passive tracking nightmare.

                2021, however, is going to be the year of WebAuthentication. It’s way superior in terms of implementation, complexity, cryptographic properties, portability (e.g., a tiny device, an app, a software-token) and the user flow can be very similar to other multi-factor authentication that users are now more comfortable with, due to having become mandatory for banking (at least it’s been mandatory in the EU for a couple of years now)

                1. 3

                  A significant fraction of users store their passwords in a keychain managed by the OS (and stored on disk). Is there a reason that’s less scary than client certificates?

                  (I admit, I don’t trust my OS’s keychain, but that’s probably superstition.

                  1. 2

                    2021, however, is going to be the year of WebAuthentication. It’s way superior in terms of implementation, complexity, cryptographic properties, portability (e.g., a tiny device, an app, a software-token)

                    WebAuthn is a very complex over-engineered “standard” with a million foot guns. I ran into this some time ago when I was looking at supporting WebAuthn: https://webauthn.guide/. I first thought it was a parody! Algorithm -7. Absurd. Why is JS even needed in a site to use webauthn for the simple user authentication or a 2nd-factor flow? Let alone the crazy amount of boilerplate code for something that should be 1 call for registration and 1 call for using it with sane and secure defaults and certainly not support suspicious crypto primitives like RSA with PKCS#1 v1.5 padding. It is a continuation of the trash fires that are JWT and WebCrypto that now also pulls in CBOR and COSE, which honestly I didn’t look at in detail because the RFCs are HUGE which is already a bad sign. I have no words… No lessons were learned at all in the last 10 (20?) years. And this is what we’ll get in 2021? I sincerely hope not!

                    Some sources:

                  2. 4

                    I was surprised that the article didn’t talk about WebAuthn at all, given that it is effectively a standard for doing public key authentication, which addresses the same set of use cases as client certs, with a lot more flexibility: no mandatory dependence on PKI, APIs for generating site-specific certs on first use and binding them to identity as you choose. Pretty much all of our work stuff uses WebAuthn now and it’s great: local biometrics authorise the browser to talk to the TPM, the TPM signs a nonce from the site, and I’m in.

                    1. 3

                      client-side certificates are cool when the developer is in control of the client, but most people are targeting the web, where the client is instead in control of the developer. The reason Electron is popular is that the majority of developers do not know how to create a UI with anything other than the web; rather than escaping this prison, they package it into an app with a bow, carrying their prison with them. Also certificate management is annoying.

                      1. 3

                        This is an interesting idea. I think one reason it’s never been adopted is that it needs browser support to work well To do this right now, you’d need the auth page to trigger a p12 download and you’d have to load it manually, I suppose. Browsers have all dropped the old native support for things like CSRs (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen) and offering to store application/x-x509-user-cert mime types in the browser’s key store.

                        I assume the client-side certs would be short-lived, with some equivalent of OAuth’s refresh_token. More analogous to OAuth access tokens than the typical TLS client certs.

                        The big problem I see is that since the API authentication is implicit in the browser’s state when using mutual-auth TLS, wouldn’t APIs become vulnerable to CSRF attacks?

                        1. 3

                          Yes, and even if you have smartcard infrastructure and can make your users use one, browser UX is horrible. For example, in Chrome, if your certificate is expired, the browser won’t tell you that, unless you have the browser console open. Another issue is the (in theory) simple problem of “logging a user out”, so that say, they can hand their computer to another person and let them login to the same site under a different identity. Chrome caches the client certificate and does not provide an API for clearing that cache:


                          In the world where you control your user’s full desktop experience and they have to use your software, you can say, “quit the browser to logout,” but that’s not an acceptable user experience for a commercial website.

                          Of course it’s easy to imagine that Chrome would prioritize these issues if usage was more common but it’s clear that most commercials orgs in the industry are not in the mood to be the early adopters here on behalf of their users.

                        2. 2

                          I saw Estonia brought up a few times.

                          As someone who has dealt with this stuff for 20+ years in various settings, including the Estonian national ID, let me chime in and shatter your dreams a bit.

                          TL;DR: forget about it. And when at it - forget about everything that involves X.509 PKI.

                          TLS-CCA (client certificate authentication) is an extremely complex topic. How complex? See for yourself how hard it to set up correct server-side configuration in a PKI setting. And then ask yourself: can I be sure that my configuration is correct after all that dance? Inability to obtain that assurance is a prime sign of poor security solution.

                          This is one of those instances where you should remember that trusting Wikipedia on complex issues is a mistake.

                          Estonia is moving away from TLS-CCA, fast. Not the ID card or whatever is know by “e-estonia”, but specifically the TLS-CCA, because it has so many problems, especially with compatibility and stability. Changes between TLS 1.2 and 1.3 broke some use cases for good, for example. Every single major OSX update for the last 10-15 years has broken it. Multiply those problems by those of X.509 PKI and you get a horrible unmanageable monster.

                          Furthermore, TLS-CCA has certain rare cryptographic properties (more below) that make it unsuitable for today’s environment. It is not compatible with TLS inspection (firewalls, antiviruses). For those in EU, it is not compatible with the most common integration modes mandated by PSD2. Never use it for end users and if you really want something there beyonds passwords and OTP-s, go for WebAuthn (albeit that has its own set of problems).

                          Now, that said, do not forget that today’s TLS is a joke. It protects your from very little, especially in the web browser. It is not the protocol itself, which is very fine in its latest versions, but how it is used and how the necessary trust is disseminated.

                          Should your security model actually say that you need a TLS channel that is not susceptible to various forms of widespread intercept and can set up a system which you fully control (that means all the endpoints and your own small PKI), then go for it, but even in those cases you may need something like Signal protocol, instead, on top of the TLS.

                          Otherwise, it is a bad idea.

                          For end users, got for WebAuthn or TOTP or whatever suits your setup.

                          For apps, devices and back-to-back connections, go for OAuth and maybe TLS server public key pinning.

                          1. 1

                            It seems worth noting that a lot of high-security applications in the US do use client side certs stored on smart cards, especially in federal government, military, and defense contractors.

                            One problem is that it rules out doing TLS inspection with MITM devices like ZScaler or BlueCoat (which is arguably a good thing of course, but many organizations need).

                            What really made this idea unpopular was the series of high-profile attacks against smartcards (just one example linked) which could cause them to leak private keys and break the security of the whole system.

                            WebAuthn is a great idea, but it’s substantially more limited than client certs on smart cards. Hopefully that means the hardware will be more secure!

                            1. 1

                              There are also more use-cases for client-side certificates that seem rather compelling, such as an alternative to user passwords. Web browser support for client-side certificates totally sucks, but that is a solvable problem.

                              For the record, I have no intention of using this approach for the SourceHut API. This thought simply occurred to me, and I want to hear what you think. Why aren’t we using client-side certificates?

                              I have wanted some kind of public-key-crypto replacement for user passwords for years. The private key could even be stored on a hardware token, for greater security. Without shared secrets, things like haveibeenpwned wouldn’t need to exist.

                              Compared to something like SSH, TLS is pretty terrible, with lots of unfortunate complexity. I think part of the reason TLS tooling is so user-hostile is that the underlying complexity leaks into the tooling. I don’t know whether it can be helped. Maybe that’s a discussion we need to have, given wide-spread TLS adoption. How can we make this stuff approachable to people without doctorates in cryptography?

                              With SSH you have a public key and a private key, and that’s most of what you need to know. You need to have a little awareness of public key types. But you usually aren’t going to be confronted with X.509, PKCS #whatever, and all of the other stuff that leaks into TLS tooling.

                              Orthogonally to this discussion, PKI is a mess.

                              I’ve always been a bit hostile to the “HTTPS all the things” mentality. That is partially because I’m more of a “transparent society”, “information wants to be free” sort of person, rather than a cypherpunk. My other reason is that I’m not fond of TLS.

                              1. 7

                                “Information wants to be free” isn’t a hope, it’s a threat: Your medical information wants to be free in the same way the water behind a dam wants to break through and flood all the towns downstream. The dam has to be maintained lest that desire be fulfilled to everyone’s detriment.

                                1. 4

                                  “information wants to be free” sort of person

                                  Information can’t be free if your ISP can tamper with any information you receive ;) If HTTPS didn’t achieve its current “all the things” status, this bullshit would’ve gotten so much worse.

                                  1. 1

                                    Here in the US, at least, there are laws against tampering with postal mail. I don’t see a moral difference between someone tampering with snail mail and a service provider tampering with unencrypted web traffic. Perhaps the same laws should apply?

                                    And secrecy cuts both ways. The same encryption that protects my information can also prevent me from snooping on or monkeying with devices or programs on my network that I either distrust or trust minimally.

                                    We’re seeing this same argument around things like DNS over HTTPS. I have legitimate reasons for intercepting and modifying DNS traffic on my network. In my case it’s an allergy to advertising, so I’ve seeded dnsmasq with some blocklists. Behind dnsmasq, I run my own recursor (unbound), in preference to using somebody else’s recursive resolvers. My point is, I would be very upset by my browser circumventing my policies around DNS in the name of privacy or whatever.

                                    Sorry for going off on so many tangents; I’ll go back to lurking. This is a discussion worth having, but it’s not quite salient to the topic at hand.

                                2. 1

                                  Fun fact, there was a service that allowed using a client cert to authenticate with OAuth2 as your own domain.

                                  1. 1

                                    What if this was used as a mean of delegating access to a third party access, with no user interaction? As in, “not OAuth”. The login part is already purposefully not specified in RFC6749, so let’s imagine you get to keep your login mechanism “as it was”, whatever that means for you.

                                    The TLS-backed protocol is essentially equivalent, for the most part, because the user doesn’t have to do anything, either with the CSR or the signed certificate, they kind of take over the role of the bearer token. So the “OAuth dance” still happens for the most part.

                                    This is mostly about the third-party integrators. The really cool thing for people who expose APIs is that the support is baked in at many levels. AFAIK, there’s a good amount of languages you can use client certificates with, which is really what it boils down to, less than browser support. Other really really nice advantage is that you could make it really easy to revoke access. I guess “offline” renewal is a bit more weird (refresh tokens… I guess you could always have support for the same kind of deal, except, you use the certificate to request a replacement certificate?).