I have loved TLS client auth since I discovered it existed. In theory it solves the password problem.
IIRC the keygen element did not send a raw public key, rather an X.509 Certificate Signing Request, which is basically the key plus some info signed with it to prove you own the private key.
In my brief unhappy tenure on the Chrome team I spent a bit of time brainstorming ways to make client certs more useable, but I didn’t really get anywhere. I did prototype showing your identity in the address bar so you could tell if and who you’re logged in as.
Ultimately I got sick of TLS as being too complex and too awful an API to integrate into code; I’m now using SecretHandshake ( from Scuttlebutt).
It was part of my brief unhappy tenure at Google, circa 2008-2010, and I actually liked it better than my first gig on the Sites team (where I discovered that I hate working on big websites, and how miserable it is trying to build reliable code in a language (JS) that has all the structural integrity of Jell-O.)
The Chrome team had about 150 engineers, and two managers. After I was hired I never again saw the manager who hired me, because there was a reorg soon after. The project had no real visible means of decision making; it appeared that you got stuff done by knowing who to talk to and getting people to support your ideas. It was all way too political and way too big and anonymous for me.
And Google in general was incredibly rigid and bureaucratic at the engineering level; there was a fanaticism about coding style and unit tests that I found infuriating. I got a sense that the company culture was rather inhuman; there was a belief that smart engineers were basically interchangeable parts — they had no idea what role people were being hired for, they’d toss you somewhere afterwards, and interviewers were chosen at random and you’d never see them again. The whole culture was designed as a machine to produce software at scale like sausage.
As mentioned in the article, TLS Origin Bound Authentication and TLS Channel ID were some attempts at ‘client certs but with better UI’. I think Chrome might even have had an implementation of one of these at some point which needed to be enabled at startup using a command line flag, but it was never deployed. The site for these standards is still up for introductory reading.
ZMTP/3.0 (which takes most of its cryptographic inspiration from CurveCP) is a pretty nice take on a TLS alternative also, at least the security parts.
It does look as though the ZMTP-CURVE auth, at least the handshake part, is very similar to SecretHandshake. “In a CurveZMQ architecture, the clients MUST know the server public key before they can connect. Servers MAY know clients’ public keys, and MAY distinguish different clients based on their keys.”
Gemini uses TLS client certs as the only available protocol-defined form of authentication. The UI varies from client to client, and not all clients implement it, but most of the ones that do provide decent (?) UI. It’s not perfect, but the problems that this article talks about with web servers and clients mostly don’t exist and there are completely different ones. Solderpunk’s rationale was that as long as we were mandating TLS in the protocol, we had best get as much utility out of it as possible in order to justify the burden of including it.
That was my intent when I wrote my Gemini server (the first Gemini server in fact). libtls/libretls made using client certificates stupid easy so I added support for them. I had to talk Solderpunk out of the whole ‘password’ thing and just rely upon client certificates.
I want this back, because WebAuthn is far to complex and adds the problem that the Website and the backend has to implement the authentication. With KEYGEN all about the keys is handled by the browser. The authentication check then can be done by the httpd.
Yes I know there are some issues with the UI and other issues on implementation side. But this is nothing conceptional and can be improved.
To your other comment about storing the credential on separate device: What stops a browser from doing the same thing with keys generated by KEYGEN?
All I’ve seen from the WebAuthn world has made it seem like an excellent way to lock yourself into either Google’s or Apple’s ecosystem as you he two companies demand to control all your online accounts. Where does the person who uses Android on their phone, macOS on their laptop and Linux on their desktop fit in to this brave new world?
If only! At $WORK, we use WebAuthn for SSO, and we use YubiKeys as the second factor. We explicitly set “usb” as the only allowed transport because we require people to use their YubiKeys to generate their WebAuthn token. However, neither Chrome nor Safari respect this and will instead try to get the user to register a passkey instead, which naturally won’t work. And the token registration UIs in both are actively hostile to using any methods other than passkeys. Firefox is at least better in this regard, but possibly only because its WebAuthn support is less extensive.
Alright but I’m not going to be using Yubikeys. So how do I sync my passkeys between my phone and desktop, so that I can log in to any account without the involvement of the other device?
Nothing in WebAuthn adds a dependency on anything other than your computer. On Windows, the private keys are stored in the TPM, on macOS they’re stored in the Secure Element, and on Android devices they’re stored in whatever the platform provides (a TrustZone enclave in the worst case, a separate hardware root of trust in the best case). All of these are defaults and, as far as I’m aware, all support using an external U2F device as well. At no point does Apple or Google have access to any my WebAuthn private keys. On other platforms, it’s up to the platform how it stores the keys, but I believe the TPM is pretty well supported on Linux.
Aaaaand by what mechanism are the keys synced between my iPhone and my Linux desktop?
I need to be able to create an account on my Linux desktop (which doesn’t have a TPM, by the way) and then log in to that account with my iPhone (without the involvement of the desktop at the time of login). I also need to be able to create an account on my iPhone and then log in to that account with my desktop (without the involvement on my phone at the time of login). This is no problem using passwords and password managers. My understanding is that it’s impossible with WebAuthn.
Aaaaand by what mechanism are the keys synced between my iPhone and my Linux desktop?
They aren’t. By design, there is no mechanism to remove the keys from secure storage. If there were, an OS compromise could exfiltrate all of your keys instantly. You create a key on one device and use that to authorise the next device. Alternatively, you use a U2F device and move it between the two machines (I believe iOS support U2F devices over NFC, your Linux machine definitely supports them over USB).
my Linux desktop (which doesn’t have a TPM, by the way)
Are you sure? Most vaguely recent motherboards have one (at least an FTPM in the CPU). Without one, there’s no good way of protecting LUKS keys, so that might be something to look for in your next upgrade.
You seem very interested in pushing this U2F device thing. I don’t know how many times I need to say I’m uninterested.
And if I can’t create an account on one device and then log in on another device without the first device involved, this is not something for me. What do I do if I make an account on my phone, happen to not log in to it on anything other than my phone, but then my phone breaks and I need to log in on my desktop? Is that just … not supported anymore?
And why should I think Apple’s implementation will even allow me to authorize my Linux machine? Is that something which falls naturally out of the standard or has Apple publicly committed to it or are you just hoping they’ll be nice?
… TPM …
Are you sure? Most vaguely recent motherboards have one
I just know my (rarely used) Windows install doesn’t let me upgrade to 11 due to missing TPM. Also, older hardware is a thing.
You seem very interested in pushing this U2F device thing. I don’t know how many times I need to say I’m uninterested.
You need to store keys somewhere. You have three choices:
In software, where anything that can compromise that software layer can exfiltrate them. Check the number of CVEs in the Linux kernel that would allow an attacker to do this before you think it’s a good idea (not particularly singling out Linux here, any kernel that is millions of lines of C is going to be compromised)l
In some hardware tied to the device (TPM, Secure Element, whatever). This is convenient for the device and gives you some security in that an OS compromise lets an attacker launch an online attack but not exfiltrate keys (these things often do some rate limiting too). The down side is that it’s tied to the device.
I’m some external hardware that you can move between devices. The standard for these to interface with computers is called U2F.
And if I can’t create an account on one device and then log in on another device without the first device involved, this is not something for me. What do I do if I make an account on my phone, happen to not log in to it on anything other than my phone, but then my phone breaks and I need to log in on my desktop? Is that just … not supported anymore?
That’s what WebAuthn recovery codes are for. Store them somewhere safe and offline.
And why should I think Apple’s implementation will even allow me to authorize my Linux machine?
I have no idea what this even means. Apple, Google, Microsoft, and Mozilla implement the client portion of WebAuthn. They have no control over which other devices any WebAuthn provider lets you use, just as a recommendation to use a strong password in Safari has no impact if you reset the password in Chrome or Edge.
You seem to think WebAuthn is something completely different to what is actually is. I can’t really help unless you explain what you think it is so that I can understand how you get to the claims you’re making.
I just know my (rarely used) Windows install doesn’t let me upgrade to 11 due to missing TPM. Also, older hardware is a thing.
I believe Windows 11 requires a TPM 2.0 implementation. TPM 1.x is fine for these uses and is 14 years old at this point.
I also don’t have a need for LUKS.
You place a lot of faith in your physical security.
I have tried to read up on WebAuthn actually, and have never found out how they intend transfer of identities between devices to work. It leads me to believe that you’re either supposed to have one device (the phone) be the device which authenticates (similar to how 2FA systems work today), or sync keys using some mechanism that’s not standardised. But it sounds like you believe there’s another mechanism; can you explain or link to some documentation on how that’s supposed to work?
Nothing stops you from having multiple keys with a single account, IIRC. You could have one device initially authorize you on another system and then make a new key for the other device.
You haven’t read that because it is out of scope for WebAuthn. WebAuthn provides a mechanism for permitting a remote device to attest to its user’s identity. It is up to the implementer of the server-side part to provide a mechanism (beyond recovery codes) to add a second device. The normal way of doing this is to use one device to enrol another. For example, you try to log in on your computer, it shows a 2-3 digit number, then you log in on your phone and approve, now both devices are authorised.
If your objection to WebAuthn is that the higher-level flows that people build on top of it have problems then you should direct your criticisms there.
Honestly, I’m not sure it would be that usable by modern standards. I don’t think anything other than RSA was widely supported, and then limited to 2048 bit key sizes, etc. It would need a lot of modernisation. I wonder if the web crypto API can provide any suitable alternatives? Not sure if it has facilities for local key storage.
The limit to RSA and 2048 bit key size is just a implementation limit. Of course this should be improved. The charming part of this is, the website don’t has to interact with the key. Yes I know there are some issues with TLS client auth, but with auth optional this can improved.
Not mentioned in this article: Client-side certs (probably using this tag) were used extensively at late Netscape for internal sites (think HR and expense reports). Never saw them used at any gig after that. But they were very cool and “obviously” what everyone would do in the post-Microsoft future. ;)
I’ve been working on various infra software that does use client certificates for a few years. The problems, unfortunately, apply there too: the UIs are awful, it’s never really clear which client cert to use for different servers, and there is no good way to scope down CAs so that they can’t just issue a client cert for any arbitrary person. So far, we manage, but it’s a corner of networking standards that is very old and in need of improvement.
I have loved TLS client auth since I discovered it existed. In theory it solves the password problem.
IIRC the keygen element did not send a raw public key, rather an X.509 Certificate Signing Request, which is basically the key plus some info signed with it to prove you own the private key.
In my brief unhappy tenure on the Chrome team I spent a bit of time brainstorming ways to make client certs more useable, but I didn’t really get anywhere. I did prototype showing your identity in the address bar so you could tell if and who you’re logged in as.
Ultimately I got sick of TLS as being too complex and too awful an API to integrate into code; I’m now using SecretHandshake ( from Scuttlebutt).
Sounds like a war story I’d be interested in hearing sometime, if you ever care to share.
It was part of my brief unhappy tenure at Google, circa 2008-2010, and I actually liked it better than my first gig on the Sites team (where I discovered that I hate working on big websites, and how miserable it is trying to build reliable code in a language (JS) that has all the structural integrity of Jell-O.)
The Chrome team had about 150 engineers, and two managers. After I was hired I never again saw the manager who hired me, because there was a reorg soon after. The project had no real visible means of decision making; it appeared that you got stuff done by knowing who to talk to and getting people to support your ideas. It was all way too political and way too big and anonymous for me.
And Google in general was incredibly rigid and bureaucratic at the engineering level; there was a fanaticism about coding style and unit tests that I found infuriating. I got a sense that the company culture was rather inhuman; there was a belief that smart engineers were basically interchangeable parts — they had no idea what role people were being hired for, they’d toss you somewhere afterwards, and interviewers were chosen at random and you’d never see them again. The whole culture was designed as a machine to produce software at scale like sausage.
As mentioned in the article, TLS Origin Bound Authentication and TLS Channel ID were some attempts at ‘client certs but with better UI’. I think Chrome might even have had an implementation of one of these at some point which needed to be enabled at startup using a command line flag, but it was never deployed. The site for these standards is still up for introductory reading.
ZMTP/3.0 (which takes most of its cryptographic inspiration from CurveCP) is a pretty nice take on a TLS alternative also, at least the security parts.
It does look as though the ZMTP-CURVE auth, at least the handshake part, is very similar to SecretHandshake. “In a CurveZMQ architecture, the clients MUST know the server public key before they can connect. Servers MAY know clients’ public keys, and MAY distinguish different clients based on their keys.”
Gemini uses TLS client certs as the only available protocol-defined form of authentication. The UI varies from client to client, and not all clients implement it, but most of the ones that do provide decent (?) UI. It’s not perfect, but the problems that this article talks about with web servers and clients mostly don’t exist and there are completely different ones. Solderpunk’s rationale was that as long as we were mandating TLS in the protocol, we had best get as much utility out of it as possible in order to justify the burden of including it.
Some of the best examples of it in use:
You’ll probably get the best experience by visiting these in either Lagrange or Elpher, since they both have good client certificate support.
That was my intent when I wrote my Gemini server (the first Gemini server in fact).
libtls/libretlsmade using client certificates stupid easy so I added support for them. I had to talk Solderpunk out of the whole ‘password’ thing and just rely upon client certificates.Ah, thanks for the correction. I remembered the mailing list discussion, but I forgot who said what.
I would like to have this back.
Very soon. WebAuthn & Passkeys
I think you complete misunderstand my comment.
I want this back, because WebAuthn is far to complex and adds the problem that the Website and the backend has to implement the authentication. With KEYGEN all about the keys is handled by the browser. The authentication check then can be done by the httpd.
Yes I know there are some issues with the UI and other issues on implementation side. But this is nothing conceptional and can be improved.
To your other comment about storing the credential on separate device: What stops a browser from doing the same thing with keys generated by KEYGEN?
Nothing, in fact browsers support that (smartcards)
All I’ve seen from the WebAuthn world has made it seem like an excellent way to lock yourself into either Google’s or Apple’s ecosystem as you he two companies demand to control all your online accounts. Where does the person who uses Android on their phone, macOS on their laptop and Linux on their desktop fit in to this brave new world?
You can store credentials on a device that speaks USB or Bluetooth pr NFC. No need to store the material on your computing device.
If only! At $WORK, we use WebAuthn for SSO, and we use YubiKeys as the second factor. We explicitly set “usb” as the only allowed transport because we require people to use their YubiKeys to generate their WebAuthn token. However, neither Chrome nor Safari respect this and will instead try to get the user to register a passkey instead, which naturally won’t work. And the token registration UIs in both are actively hostile to using any methods other than passkeys. Firefox is at least better in this regard, but possibly only because its WebAuthn support is less extensive.
Right, but that’s now what any of the big players are making, even if it’s technically possible.
And I’m not going to be bringing around a dedicated Bluetooth or USB key device. And I doubt my iPhone would support it even if I did.
The whole “let’s get rid of passwords” WebAuthN thing seems like a huge lock-in opportunity for the huge companies and nothing more IMO.
I get your scepticism, but imho it doesn’t sound too justified to me.
WebAuthn: You can already buy a Yubikey that does NFC and works for iPhone.
PassKeys I don’t have experience with, but I know there are open implementations that will help avoid lock-in.
Alright but I’m not going to be using Yubikeys. So how do I sync my passkeys between my phone and desktop, so that I can log in to any account without the involvement of the other device?
Nothing in WebAuthn adds a dependency on anything other than your computer. On Windows, the private keys are stored in the TPM, on macOS they’re stored in the Secure Element, and on Android devices they’re stored in whatever the platform provides (a TrustZone enclave in the worst case, a separate hardware root of trust in the best case). All of these are defaults and, as far as I’m aware, all support using an external U2F device as well. At no point does Apple or Google have access to any my WebAuthn private keys. On other platforms, it’s up to the platform how it stores the keys, but I believe the TPM is pretty well supported on Linux.
Aaaaand by what mechanism are the keys synced between my iPhone and my Linux desktop?
I need to be able to create an account on my Linux desktop (which doesn’t have a TPM, by the way) and then log in to that account with my iPhone (without the involvement of the desktop at the time of login). I also need to be able to create an account on my iPhone and then log in to that account with my desktop (without the involvement on my phone at the time of login). This is no problem using passwords and password managers. My understanding is that it’s impossible with WebAuthn.
They aren’t. By design, there is no mechanism to remove the keys from secure storage. If there were, an OS compromise could exfiltrate all of your keys instantly. You create a key on one device and use that to authorise the next device. Alternatively, you use a U2F device and move it between the two machines (I believe iOS support U2F devices over NFC, your Linux machine definitely supports them over USB).
Are you sure? Most vaguely recent motherboards have one (at least an FTPM in the CPU). Without one, there’s no good way of protecting LUKS keys, so that might be something to look for in your next upgrade.
You seem very interested in pushing this U2F device thing. I don’t know how many times I need to say I’m uninterested.
And if I can’t create an account on one device and then log in on another device without the first device involved, this is not something for me. What do I do if I make an account on my phone, happen to not log in to it on anything other than my phone, but then my phone breaks and I need to log in on my desktop? Is that just … not supported anymore?
And why should I think Apple’s implementation will even allow me to authorize my Linux machine? Is that something which falls naturally out of the standard or has Apple publicly committed to it or are you just hoping they’ll be nice?
I just know my (rarely used) Windows install doesn’t let me upgrade to 11 due to missing TPM. Also, older hardware is a thing.
I also don’t have a need for LUKS.
You need to store keys somewhere. You have three choices:
That’s what WebAuthn recovery codes are for. Store them somewhere safe and offline.
I have no idea what this even means. Apple, Google, Microsoft, and Mozilla implement the client portion of WebAuthn. They have no control over which other devices any WebAuthn provider lets you use, just as a recommendation to use a strong password in Safari has no impact if you reset the password in Chrome or Edge.
You seem to think WebAuthn is something completely different to what is actually is. I can’t really help unless you explain what you think it is so that I can understand how you get to the claims you’re making.
I believe Windows 11 requires a TPM 2.0 implementation. TPM 1.x is fine for these uses and is 14 years old at this point.
You place a lot of faith in your physical security.
I have tried to read up on WebAuthn actually, and have never found out how they intend transfer of identities between devices to work. It leads me to believe that you’re either supposed to have one device (the phone) be the device which authenticates (similar to how 2FA systems work today), or sync keys using some mechanism that’s not standardised. But it sounds like you believe there’s another mechanism; can you explain or link to some documentation on how that’s supposed to work?
Nothing stops you from having multiple keys with a single account, IIRC. You could have one device initially authorize you on another system and then make a new key for the other device.
You haven’t read that because it is out of scope for WebAuthn. WebAuthn provides a mechanism for permitting a remote device to attest to its user’s identity. It is up to the implementer of the server-side part to provide a mechanism (beyond recovery codes) to add a second device. The normal way of doing this is to use one device to enrol another. For example, you try to log in on your computer, it shows a 2-3 digit number, then you log in on your phone and approve, now both devices are authorised.
If your objection to WebAuthn is that the higher-level flows that people build on top of it have problems then you should direct your criticisms there.
Windows 11 requires TPM 2.0, So its possible to have a TPM without W11 supporting it
Honestly, I’m not sure it would be that usable by modern standards. I don’t think anything other than RSA was widely supported, and then limited to 2048 bit key sizes, etc. It would need a lot of modernisation. I wonder if the web crypto API can provide any suitable alternatives? Not sure if it has facilities for local key storage.
The limit to RSA and 2048 bit key size is just a implementation limit. Of course this should be improved. The charming part of this is, the website don’t has to interact with the key. Yes I know there are some issues with TLS client auth, but with auth optional this can improved.
Not mentioned in this article: Client-side certs (probably using this tag) were used extensively at late Netscape for internal sites (think HR and expense reports). Never saw them used at any gig after that. But they were very cool and “obviously” what everyone would do in the post-Microsoft future. ;)
I’ve been working on various infra software that does use client certificates for a few years. The problems, unfortunately, apply there too: the UIs are awful, it’s never really clear which client cert to use for different servers, and there is no good way to scope down CAs so that they can’t just issue a client cert for any arbitrary person. So far, we manage, but it’s a corner of networking standards that is very old and in need of improvement.