7 ms·

Memoirs from the old web: The KEYGEN element

191 points by pabs3 4y ago

brazzy 4y ago
Whoa. I've never heard of this, that's truly obscure. I have worked with client certificates though, they were required for all communication (not just Browsers, also server-to-server) in a government agency I worked for.
danjc 4y ago
Even today, client cert selection in the browser is really ugly. I once needed to add client cert support to an API but because the same API was used by our SPA, enabling client certs even as optional caused the browser to display a cert prompt when the SPA made its first API call. To get around this, I ended up writing a custom IIS module that turned on client cert support only when a certain request header was present.
chrismorgan 4y ago
This looks to be an interesting series; too often it’s really hard to find out what something once was. Some of the articles are about things that have been removed (like <keygen>), others are of things that are still actually there, though no one uses them any more (such as server-side image maps). I hope one is written about <ISINDEX>. That element really confused me when I was young and it was already thoroughly on the way out (though I can’t remember whether it had quite been removed yet). For something like this, remarks about the site itself can be fair game. Here’s an interesting one: the site actually uses XML syntax, something few realise is even possible these days, but which is rather interesting in its differences and incompatibilities. (Some affect authoring, e.g. whether <, & and > must or must not be entity-encoded inside <script> and <style>. Others affect runtime, e.g. many JavaScript libraries assume Element.prototype.tagName is uppercase, but it’s not in XML syntax.) Probably my favourite thing about XML syntax is that it lets you nest links (though it’s nominally invalid), which can’t be done in HTML syntax (though you can do it in a live DOM using JavaScript).
- hlandau 4y ago
  Author here - yes, ISINDEX is on my radar. ;) Taking other suggestions also - I'm sure my memory isn't exhaustive. At some point I may venture into the weird proprietary extensions IE had also.
  - chrismorgan 4y ago
    Of regular HTML features, one more immediately springs to mind: <frameset>. It’s similar to image maps as a feature that still works, but which no one uses any more. (I actually used <frameset> for fun a couple of years ago in a live-coding-completely-from-scratch demo/talk that I prepared roughly but have never actually delivered, entitled “building a fair dinkum email client in half an hour with JMAP”. I was mildly surprised to get the frameset right without looking up any docs, despite not having used it for well over a decade, and not much before that.) Hmm… maybe <plaintext> and <xmp> too, which still have fun parser implications. No idea how much actual use they ever got. (For that matter, I’m not sure how much use ISINDEX got.)
    - hlandau 4y ago
      Yeah. Of course, nowadays I believe you could replace <frameset> almost entirely with iframes and CSS layout. But it does occur to me that there was exactly one feature of frameset which you maybe can't replicate: the ability of the user to resize frames with the mouse without relying on JavaScript. ...Although, come to think of it, the CSS `resize:` property exists now, and it seems it can be used to make arbitrary elements resizeable. Might actually work for it, though the UI might differ a bit.
      - chrismorgan 4y ago
        There are differences between browsers in how they handle frames and history management (e.g. if you reload, Firefox keeps the iframe source documents as they were at the time of reload, since Firefox likes to retain stuff across page loads, and generally does an excellent job of it, but occasionally what it does messes with what the page tries to do if they aren’t aware of Firefox’s superior handling; Chromium, by contrast, does what it does so well, and throws it all away and starts afresh from what the source document specifies, which is actually a bit baffling given that frame locations are actually a part of the history entries so they could easily do better in at least most cases). But I don’t think there are differences any more within a single browser between how frameset frames and iframes are handled, for history purposes. I vaguely recall seeing some of this stuff being specified in the HTML Standard maybe last year or so. I suspect there used to be differences, but I’m not confident. As for CSS resize: for consistent support, you’d need to have the iframe fill a div, and make the div resizable. (As the spec says <https://www.w3.org/TR/css-ui-3/#resize https://www.w3.org/TR/css-ui-3/#resize>: “Applies to: elements with ‘overflow’ other than visible, and optionally replaced elements such as images, videos, and iframes”. Firefox doesn’t currently support resize on replaced elements. Fortunately the workaround is straightforward, and reliable so long as you’re not having the elements’ intrinsic sizes influencing layout.) As for its UI, current consensus gets you a grippy in… well, roughly the bottom-end corner. (It depends on direction and writing-mode, as it should, but some of the choices seem moderately arbitrary since they’ve obviously decided to anchor it to one of the bottom corners, and while Firefox’s placements all seem sensible enough, Chromium gets the position obviously wrong when you combine direction rtl with writing-mode tb, tb-rl or vertical-rl; I should probably file a bug for this, but I’m too lazy.) Anyway, just a regular corner grippy for `resize: horizontal` or `resize: vertical` is rather disappointing. Need some way of controlling it to say “make it a full interactive border”. All up, it’s nowhere near as simple as <frameset> if that’s exactly what you want, and its UI is a bit wonky, but yeah, it pretty much works, and it does give you a lot more flexibility.
opminion 4y ago
I wonder if the Client Certificates mentioned in the article are the same thing as certificates used in Spain for interaction with government agencies, the so called "certificado digital". In that case they are not "rarely used", but I would agree that they their usability is abysmal.
- AshamedCaptain 4y ago
  Yes, they are. There was an EU wide push to use these as a form of online public authentication. I think a lot more people used keygen than this article seems to claim, even without knowing it. The alternative on IE was either an activeX control or a java applet (neither feasible on a mozilla browser since the applet wont have acess to the browser certificate storage). When Mozilla deprecated keygen, these services never recovered. The proposed alternatives had even worse UI and were even less portable.
  - idndoxheo 4y ago
    ah yes, the good old bay-area-bubble. if your two friends don't use a feature, it can be dropped. that's the origin of sites only working with IE6 buttons (to keep with the age of the article) or noways things crashing unless your browser implements the latest buggy and non standard features that chrome is pushing. also, remember, even the standard stuff (w3c) was always written and worked on folks in the payroll of companies whose main business was selling advertisement.
- Avamander 4y ago
  Yes, highly likely it's mTLS like in other EU countries. Though some countries have a longer track-record and better client software (and legislative enforcement of support) than others, providing a smoother experience. Most of the stumbles seem to be from countries and the EU not cooperating with browser vendors to fix the rough edges. Unfortunate but probably a tragedy of the commons.
simonjgreen 4y ago
Client side SSL authentication, as a bit of an old school sysadmin, remains both my favourite and least favourite authentication method. Favourite because I like the decentralised model, secrets in the perimeter instead of the core, and it was also fantastic for M2M comms before OAuth etc came on the scene. Least favourite because the client side implementation was always ugly and unpleasant. In particular the shared key store between Windows world (Inc IE) and Chrome and absence of that with Firefox. Explaining to a user how to make establish with client certificates was such a pain. I still use this today in professional life for at least 2 B2B relationships that spring to mind. Both of them are with Telcos. I also use it for a couple of older OpenVPN setups. I think client side SSL still holds a strong place in the toolbelt of options for doing small scale micro service models. It handles many authentication and identity challenges "for free". EasyRSA is a great goto tool to help you get started with it.
- hlandau 4y ago
  Author here. "Secrets in the perimeter instead of the core" is an interesting point. To my mind it can just as equally be a disadvantage - I'd usually consider the core more trusted and less exposed. When deploying client certificate auth with HTTP load balancers, etc. you basically have to have the LB add a X-Client-Certificate: ... header and then trust that it's telling the truth. This means a LB compromise basically compromises everything, since it can just lie, whereas something like (for example) AWS's HMAC-based signature system (where the substance of a request is signed using a shared secret unknown to LBs) for its APIs wouldn't be. So I actually find this a compelling argument against client certificates in practice. It's actually a curious example of how the security of client certificates might be worse in practice, even though theoretically superior on the client-to-server leg, because of the backend implications it creates.
  - idndoxheo 4y ago
    why is the LB unwrapping thing it shouldn't be the authority for? it whould work on L2 then
    - 4y ago
prepend 4y ago
> Why are client certificates rarely used? There are likely several reasons, but probably the most obvious one is that the UI for handling them has been truly abysmal. While the UI is bad, I think the main reason client cents aren’t adopted is due to its cost and specifically recurring costs. For b2c stuff, users don’t want to purchase certificates just to authenticate. And they certainly don’t want to repurchase them every year or so. Imagine if a web site had an $80 annual authentication fee that didn’t even go to the site. Way back, I wished there would be some sort of government issuance that would cover the costs and negotiate with standards people to allow perpetual client certs that never expire (good enough for bitcoin wallets). Interestingly, the US government does do this for employees through the Homeland Security Presidential Directive [0] where all federal staff have a client certificate issued and stored in a physical card for use. The UI is still bad, but you can use it to authenticate to federal websites. [0] https://www.dhs.gov/homeland-security-presidential-directive-12 https://www.dhs.gov/homeland-security-presidential-directive...
- hlandau 4y ago
  Author here. There needn't be any cost for client certificates, since client certificates are frequently issued by custom in-house CAs for free. A more pertinent example of what you're talking about would be the use of S/MIME email encryption - I believe you could pay to get a proper certificate from a trusted CA for your email address to use S/MIME - I have no idea if any CA still does this or how many people do so. It's not something I've ever encountered personally, at least.
  - Avamander 4y ago
    > I believe you could pay to get a proper certificate from a trusted CA for your email address to use S/MIME - I have no idea if any CA still does this or how many people do so. There are a handful of CAs that offer S/MIME certificates, not that obscure of a service really. Actalis is the only one doing it for free though. It is a bit cumbersome but it's rather well-supported (gmail, apple mail, outlook, thunderbird etc.). Hopefully things get simpler now that the CA/B forum S/MIME workgroup is working on clear baseline requirements (so the ecosystem is still moving forward). Something like a mailbox-validated "Let's Encrypt" would be doable and I hope something like that would appear at some point.
vivegi 4y ago
It would have been great if the KEYGEN element's semantics meant - generating a fresh keypair of a certain strength and persistence of the newly generated key if a keypair is not associated with a specific domain - selection of the keypair from the persistence store using a browser's UI dialog if a keypair is already associated with the specific domain, with an option to regenerate the keypair That would have been a good declarative alternative for password-based-authentication. It would have enabled client-side id generation and simplified user registration and other authentication flows, including perhaps keyrotation. I guess we should use webauthn now.
bandrami 4y ago
20 years ago I had my blog (this was before we really called them "blogs") set up to authenticate me via a certificate to show the admin panel and anybody without that certificate (or with a different one) to just see the read-only front page. I even had a couple of friends enroll so they could leave comments. I feel like client certificates are the biggest and most depressing what-might-have-been's of the Web; a great technology that was ultimately killed by pedantic people putting up unnecessary barriers because somebody might scrape your process tree for a password or whatever. We really let the perfect be the enemy of the good here.
- jeroenhd 4y ago
  It's annoying that this technology never made it, but there's also a downside to this tech. Last time I've set up a client cert, I got constantly prompted to authenticate on random websites, and it turns out that ad tracking/fingerprinters/other cyberstalkingware abuse this process to track information about you. Another major problem is that middleboxes freak the fuck out when you don't follow TLS 1.2 to the point crappy middlebox vendors have bothered to implement the spec. Personally, I'd just accept that and let people stuck behind these crappy middleboxes get their ISPs/workplaces to get their shit together, but that's not a very business-friendly approach. To fix the tracking issue, you'd need to employ strict limitations about what service can or cannot prompt for authentication when you're on a web page, and I'm sure restricting that stuff will break the few remaining big sites that rely on client certificates today. Luckily, we have an alternative today. WebAuthn uses similar cryptographic principles to set up secure tokens and the UX is a lot better.
  - dcow 4y ago
    Meh. Is it really though? Middle boxes can't MITM the signed requests so that's still a "problem". I agree signed requests are better than bearer tokens, but webauthn only signs the auth request and then you typically are back at square 1 receiving a cookie from the server with a bearer token anyway... so no improvement for 99.999% of the requests you actually make. The tracking issues are solvable with browser UX, they're not inherent to client certs. The only way I see out of this mess is for everyone to start replacing bearer tokens with signed requests. And possibly some extension to webauthn so the browser will use your webauthn creds to sign every requests using a standard signing protocol.
doublerabbit 4y ago
awwh, I thought this was going to be about keygens and the demoscene music that came with. That was definite an era of the old web.
- agys 4y ago
  To mitigate your disappointment you could visit the “Keygen Church” by Master Boot Record (a mix of metal, chiptune and ASCII + pixel art): https://www.youtube.com/watch?v=ynVpatxQERs https://www.youtube.com/watch?v=ynVpatxQERs
  - doublerabbit 4y ago
    Good track, great band, I saw them live the other month. Such an fantastic show. CONFIG.SYS is one of my favs: https://www.youtube.com/watch?v=6CQq0jnie5U https://www.youtube.com/watch?v=6CQq0jnie5U -- they also have a BBS and IRC network which was also cool.
    - agys 4y ago
      Also a fan here, although I never had the chance to see them live. I bought a tapes (even if I don’t own a tape player) just because of the gorgeous design…! https://masterbootrecord.bandcamp.com https://masterbootrecord.bandcamp.com
    - nayuki 4y ago
      Only related by name, IOSYS is one of my favorites due to their catchy Touhou Project derivative music and funny Flash videos.
- alyssaxuu 4y ago
  Ha, I had the same thought. I recently watched this video which you might find interesting (mostly re: demoscene): https://www.youtube.com/watch?v=roBkg-iPrbw https://www.youtube.com/watch?v=roBkg-iPrbw
_8j50 4y ago
You know, this is exactly what I want webauthn and all that newer authentication stuff to do. I'll say though it isn't just client side UI but webapps just don't support the idea of a user registering and loggingg in with a client cert that well. But it is truly a shame because it is an unphishable method of authentication already on every device and doesn't cost hardware-money like a yubikey. It just isn't sexy enough for developers to care about it.
- exabrial 4y ago
  Looks like you got downvoted because you offended someone ;)
_joel 4y ago
Been in this game for 25+ years and this is the first I've heard of this tag :)
masswerk 4y ago
> There is no opportunity for websites to provide a message like “you have not registered yet, go here”. As I remember it, you had to buy a certificate from a CA and provide some real-world credentials along with this, and this wouldn't have been an instant process. Would this even have accepted self-signed certificates (as it seems to be suggested here)?
- Avamander 4y ago
  You don't need to, it just depends on who's your source of identity. The mTLS handshake includes exchanging which CA's are accepted, AFAIK. In some cases it's some commercial entity, in others it's a country itself, but nobody stops you from using your own CA.
  - masswerk 4y ago
    I was just mentioning this, because I had a personal email certificate back then (when this became an integrated option with the built-in Netscape Navigator email client and the like), and this was a rather convoluted process and it took about a week. And, as I remember it, there were just a few options and the process was different for each. Which may explain the "poor UI": this was something you really had to want and you had to jump through a few hoops to achieve this, the entire process wasn't exactly user friendly, and there wasn't even a standard process or standard requirements. So how could you point someone at a link, “you have not registered yet, go here”? You'd probably include an entire paragraph explaining what was required and link to several CA sites in order to obtain a valid certificate.
    - Avamander 4y ago
      > So how could you point someone at a link, “you have not registered yet, go here”? You'd probably include an entire paragraph explaining what was required and link to several CA sites in order to obtain a valid certificate. Well as I said, it will be complex if it's some enterprise CA you want your users to use. It's very easy if just everyone in your country has a certificate already. It's fairly easy if you use your own CA and just give the users the .p12 to install. E-mail certificates, S/MIME, is a bit more complex and not exactly the same - there you'd actually want some larger publicly trusted entity to be used. (Though some already-deployed multi-purpose certificates do exist in some EU countries.)
machina_ex_deus 4y ago
I wish it was easier to just do authentication based on self-signed client certificates instead of passwords. Instead of cookies saving your login, do key-exchange of temporary client certificate. If it was done properly, it has the bonus security that it's completely immune to XSS stealing your authentication on the website - even if the website was subject to some XSS, they can't steal your authentication cookies, and the client certificate is inaccessible to JavaScript.
nayuki 4y ago
My only time ever seeing and using client-side certificates was when I used StartSSL's service to get a free server certificate. It was an interesting experience and radically different from the usual experience of registering on a website with a username/email and password. Looks like the author says quite a few things about StartSSL's practices too. Just like the article laments, the UI for managing client-side certificates was very basic and not user-friendly; I was using Firefox. I do wish this technology was explored deeper by both webmasters and browsers; I prefer to have one or a few private keys instead of hundreds of different passwords for each website. I want to be immune to password keylogging and server-side database leaks.
peanut-walrus 4y ago
If client certificate UX had not been so completely terrible, there would be whole cybercrime operations and classes of attacks that wouldn't exist. Phishing, cred stuffing, session hijacking, etc - all of these would never have even become an issue. Probably the biggest missed opportunity ever, the cost of not developing a usable UX for client certs is likely in tens or hundreds of billions by now.
amatecha 4y ago
Just as an aside I love this guy's website. No shenanigans, it just works, and probably works on any browser going back at least 10 years. Kudos 100%.
dcow 4y ago
Makes me wonder how WebAuthN will fare. As long as the browser is in control of the UX for managing keypairs, I don't see strong browser crypto ever succeeding, because it will fail in the same way <keygen> did: horrible browser UX. Also nobody wants all their keys stuck in one browser. You need a software layer to help you manage your keys and share them across devices. That is unless every website adopts a "device registration" pattern where a user is just a collection of trusted "devices".
- zrail 4y ago
  That's the entire point of passkeys. They're natively multi-device.
slondr 4y ago
Gemini uses ssl client certificates as its primary method of authenticating users and keeping track of user sessions. It works really well; a major benefit is that the user is in charge of how long their session exists for.

191 points by pabs3 4y ago

Whoa. I've never heard of this, that's truly obscure. I have worked with client certificates though, they were required for all communication (not just Browsers, also server-to-server) in a government agency I worked for.

danjc 4y ago

Even today, client cert selection in the browser is really ugly. I once needed to add client cert support to an API but because the same API was used by our SPA, enabling client certs even as optional caused the browser to display a cert prompt when the SPA made its first API call. To get around this, I ended up writing a custom IIS module that turned on client cert support only when a certain request header was present.

chrismorgan 4y ago

This looks to be an interesting series; too often it’s really hard to find out what something once was. Some of the articles are about things that have been removed (like <keygen>), others are of things that are still actually there, though no one uses them any more (such as server-side image maps). I hope one is written about <ISINDEX>. That element really confused me when I was young and it was already thoroughly on the way out (though I can’t remember whether it had quite been removed yet). For something like this, remarks about the site itself can be fair game. Here’s an interesting one: the site actually uses XML syntax, something few realise is even possible these days, but which is rather interesting in its differences and incompatibilities. (Some affect authoring, e.g. whether <, & and > must or must not be entity-encoded inside <script> and <style>. Others affect runtime, e.g. many JavaScript libraries assume Element.prototype.tagName is uppercase, but it’s not in XML syntax.) Probably my favourite thing about XML syntax is that it lets you nest links (though it’s nominally invalid), which can’t be done in HTML syntax (though you can do it in a live DOM using JavaScript).

hlandau 4y ago
Author here - yes, ISINDEX is on my radar. ;) Taking other suggestions also - I'm sure my memory isn't exhaustive. At some point I may venture into the weird proprietary extensions IE had also.
- chrismorgan 4y ago
  Of regular HTML features, one more immediately springs to mind: <frameset>. It’s similar to image maps as a feature that still works, but which no one uses any more. (I actually used <frameset> for fun a couple of years ago in a live-coding-completely-from-scratch demo/talk that I prepared roughly but have never actually delivered, entitled “building a fair dinkum email client in half an hour with JMAP”. I was mildly surprised to get the frameset right without looking up any docs, despite not having used it for well over a decade, and not much before that.) Hmm… maybe <plaintext> and <xmp> too, which still have fun parser implications. No idea how much actual use they ever got. (For that matter, I’m not sure how much use ISINDEX got.)
  - hlandau 4y ago
    Yeah. Of course, nowadays I believe you could replace <frameset> almost entirely with iframes and CSS layout. But it does occur to me that there was exactly one feature of frameset which you maybe can't replicate: the ability of the user to resize frames with the mouse without relying on JavaScript. ...Although, come to think of it, the CSS `resize:` property exists now, and it seems it can be used to make arbitrary elements resizeable. Might actually work for it, though the UI might differ a bit.
    - chrismorgan 4y ago
      There are differences between browsers in how they handle frames and history management (e.g. if you reload, Firefox keeps the iframe source documents as they were at the time of reload, since Firefox likes to retain stuff across page loads, and generally does an excellent job of it, but occasionally what it does messes with what the page tries to do if they aren’t aware of Firefox’s superior handling; Chromium, by contrast, does what it does so well, and throws it all away and starts afresh from what the source document specifies, which is actually a bit baffling given that frame locations are actually a part of the history entries so they could easily do better in at least most cases). But I don’t think there are differences any more within a single browser between how frameset frames and iframes are handled, for history purposes. I vaguely recall seeing some of this stuff being specified in the HTML Standard maybe last year or so. I suspect there used to be differences, but I’m not confident. As for CSS resize: for consistent support, you’d need to have the iframe fill a div, and make the div resizable. (As the spec says <https://www.w3.org/TR/css-ui-3/#resize https://www.w3.org/TR/css-ui-3/#resize>: “Applies to: elements with ‘overflow’ other than visible, and optionally replaced elements such as images, videos, and iframes”. Firefox doesn’t currently support resize on replaced elements. Fortunately the workaround is straightforward, and reliable so long as you’re not having the elements’ intrinsic sizes influencing layout.) As for its UI, current consensus gets you a grippy in… well, roughly the bottom-end corner. (It depends on direction and writing-mode, as it should, but some of the choices seem moderately arbitrary since they’ve obviously decided to anchor it to one of the bottom corners, and while Firefox’s placements all seem sensible enough, Chromium gets the position obviously wrong when you combine direction rtl with writing-mode tb, tb-rl or vertical-rl; I should probably file a bug for this, but I’m too lazy.) Anyway, just a regular corner grippy for `resize: horizontal` or `resize: vertical` is rather disappointing. Need some way of controlling it to say “make it a full interactive border”. All up, it’s nowhere near as simple as <frameset> if that’s exactly what you want, and its UI is a bit wonky, but yeah, it pretty much works, and it does give you a lot more flexibility.

opminion 4y ago

I wonder if the Client Certificates mentioned in the article are the same thing as certificates used in Spain for interaction with government agencies, the so called "certificado digital". In that case they are not "rarely used", but I would agree that they their usability is abysmal.

AshamedCaptain 4y ago
Yes, they are. There was an EU wide push to use these as a form of online public authentication. I think a lot more people used keygen than this article seems to claim, even without knowing it. The alternative on IE was either an activeX control or a java applet (neither feasible on a mozilla browser since the applet wont have acess to the browser certificate storage). When Mozilla deprecated keygen, these services never recovered. The proposed alternatives had even worse UI and were even less portable.
- idndoxheo 4y ago
  ah yes, the good old bay-area-bubble. if your two friends don't use a feature, it can be dropped. that's the origin of sites only working with IE6 buttons (to keep with the age of the article) or noways things crashing unless your browser implements the latest buggy and non standard features that chrome is pushing. also, remember, even the standard stuff (w3c) was always written and worked on folks in the payroll of companies whose main business was selling advertisement.
Avamander 4y ago
Yes, highly likely it's mTLS like in other EU countries. Though some countries have a longer track-record and better client software (and legislative enforcement of support) than others, providing a smoother experience. Most of the stumbles seem to be from countries and the EU not cooperating with browser vendors to fix the rough edges. Unfortunate but probably a tragedy of the commons.

simonjgreen 4y ago

Client side SSL authentication, as a bit of an old school sysadmin, remains both my favourite and least favourite authentication method. Favourite because I like the decentralised model, secrets in the perimeter instead of the core, and it was also fantastic for M2M comms before OAuth etc came on the scene. Least favourite because the client side implementation was always ugly and unpleasant. In particular the shared key store between Windows world (Inc IE) and Chrome and absence of that with Firefox. Explaining to a user how to make establish with client certificates was such a pain. I still use this today in professional life for at least 2 B2B relationships that spring to mind. Both of them are with Telcos. I also use it for a couple of older OpenVPN setups. I think client side SSL still holds a strong place in the toolbelt of options for doing small scale micro service models. It handles many authentication and identity challenges "for free". EasyRSA is a great goto tool to help you get started with it.

hlandau 4y ago
Author here. "Secrets in the perimeter instead of the core" is an interesting point. To my mind it can just as equally be a disadvantage - I'd usually consider the core more trusted and less exposed. When deploying client certificate auth with HTTP load balancers, etc. you basically have to have the LB add a X-Client-Certificate: ... header and then trust that it's telling the truth. This means a LB compromise basically compromises everything, since it can just lie, whereas something like (for example) AWS's HMAC-based signature system (where the substance of a request is signed using a shared secret unknown to LBs) for its APIs wouldn't be. So I actually find this a compelling argument against client certificates in practice. It's actually a curious example of how the security of client certificates might be worse in practice, even though theoretically superior on the client-to-server leg, because of the backend implications it creates.
- idndoxheo 4y ago
  why is the LB unwrapping thing it shouldn't be the authority for? it whould work on L2 then
  - 4y ago

prepend 4y ago

> Why are client certificates rarely used? There are likely several reasons, but probably the most obvious one is that the UI for handling them has been truly abysmal. While the UI is bad, I think the main reason client cents aren’t adopted is due to its cost and specifically recurring costs. For b2c stuff, users don’t want to purchase certificates just to authenticate. And they certainly don’t want to repurchase them every year or so. Imagine if a web site had an $80 annual authentication fee that didn’t even go to the site. Way back, I wished there would be some sort of government issuance that would cover the costs and negotiate with standards people to allow perpetual client certs that never expire (good enough for bitcoin wallets). Interestingly, the US government does do this for employees through the Homeland Security Presidential Directive [0] where all federal staff have a client certificate issued and stored in a physical card for use. The UI is still bad, but you can use it to authenticate to federal websites. [0] https://www.dhs.gov/homeland-security-presidential-directive-12 https://www.dhs.gov/homeland-security-presidential-directive...

hlandau 4y ago
Author here. There needn't be any cost for client certificates, since client certificates are frequently issued by custom in-house CAs for free. A more pertinent example of what you're talking about would be the use of S/MIME email encryption - I believe you could pay to get a proper certificate from a trusted CA for your email address to use S/MIME - I have no idea if any CA still does this or how many people do so. It's not something I've ever encountered personally, at least.
- Avamander 4y ago
  > I believe you could pay to get a proper certificate from a trusted CA for your email address to use S/MIME - I have no idea if any CA still does this or how many people do so. There are a handful of CAs that offer S/MIME certificates, not that obscure of a service really. Actalis is the only one doing it for free though. It is a bit cumbersome but it's rather well-supported (gmail, apple mail, outlook, thunderbird etc.). Hopefully things get simpler now that the CA/B forum S/MIME workgroup is working on clear baseline requirements (so the ecosystem is still moving forward). Something like a mailbox-validated "Let's Encrypt" would be doable and I hope something like that would appear at some point.

vivegi 4y ago

It would have been great if the KEYGEN element's semantics meant - generating a fresh keypair of a certain strength and persistence of the newly generated key if a keypair is not associated with a specific domain - selection of the keypair from the persistence store using a browser's UI dialog if a keypair is already associated with the specific domain, with an option to regenerate the keypair That would have been a good declarative alternative for password-based-authentication. It would have enabled client-side id generation and simplified user registration and other authentication flows, including perhaps keyrotation. I guess we should use webauthn now.

bandrami 4y ago

20 years ago I had my blog (this was before we really called them "blogs") set up to authenticate me via a certificate to show the admin panel and anybody without that certificate (or with a different one) to just see the read-only front page. I even had a couple of friends enroll so they could leave comments. I feel like client certificates are the biggest and most depressing what-might-have-been's of the Web; a great technology that was ultimately killed by pedantic people putting up unnecessary barriers because somebody might scrape your process tree for a password or whatever. We really let the perfect be the enemy of the good here.

jeroenhd 4y ago
It's annoying that this technology never made it, but there's also a downside to this tech. Last time I've set up a client cert, I got constantly prompted to authenticate on random websites, and it turns out that ad tracking/fingerprinters/other cyberstalkingware abuse this process to track information about you. Another major problem is that middleboxes freak the fuck out when you don't follow TLS 1.2 to the point crappy middlebox vendors have bothered to implement the spec. Personally, I'd just accept that and let people stuck behind these crappy middleboxes get their ISPs/workplaces to get their shit together, but that's not a very business-friendly approach. To fix the tracking issue, you'd need to employ strict limitations about what service can or cannot prompt for authentication when you're on a web page, and I'm sure restricting that stuff will break the few remaining big sites that rely on client certificates today. Luckily, we have an alternative today. WebAuthn uses similar cryptographic principles to set up secure tokens and the UX is a lot better.
- dcow 4y ago
  Meh. Is it really though? Middle boxes can't MITM the signed requests so that's still a "problem". I agree signed requests are better than bearer tokens, but webauthn only signs the auth request and then you typically are back at square 1 receiving a cookie from the server with a bearer token anyway... so no improvement for 99.999% of the requests you actually make. The tracking issues are solvable with browser UX, they're not inherent to client certs. The only way I see out of this mess is for everyone to start replacing bearer tokens with signed requests. And possibly some extension to webauthn so the browser will use your webauthn creds to sign every requests using a standard signing protocol.

doublerabbit 4y ago

awwh, I thought this was going to be about keygens and the demoscene music that came with. That was definite an era of the old web.

agys 4y ago
To mitigate your disappointment you could visit the “Keygen Church” by Master Boot Record (a mix of metal, chiptune and ASCII + pixel art): https://www.youtube.com/watch?v=ynVpatxQERs https://www.youtube.com/watch?v=ynVpatxQERs
- doublerabbit 4y ago
  Good track, great band, I saw them live the other month. Such an fantastic show. CONFIG.SYS is one of my favs: https://www.youtube.com/watch?v=6CQq0jnie5U https://www.youtube.com/watch?v=6CQq0jnie5U -- they also have a BBS and IRC network which was also cool.
  - agys 4y ago
    Also a fan here, although I never had the chance to see them live. I bought a tapes (even if I don’t own a tape player) just because of the gorgeous design…! https://masterbootrecord.bandcamp.com https://masterbootrecord.bandcamp.com
  - nayuki 4y ago
    Only related by name, IOSYS is one of my favorites due to their catchy Touhou Project derivative music and funny Flash videos.
alyssaxuu 4y ago
Ha, I had the same thought. I recently watched this video which you might find interesting (mostly re: demoscene): https://www.youtube.com/watch?v=roBkg-iPrbw https://www.youtube.com/watch?v=roBkg-iPrbw

_8j50 4y ago

You know, this is exactly what I want webauthn and all that newer authentication stuff to do. I'll say though it isn't just client side UI but webapps just don't support the idea of a user registering and loggingg in with a client cert that well. But it is truly a shame because it is an unphishable method of authentication already on every device and doesn't cost hardware-money like a yubikey. It just isn't sexy enough for developers to care about it.

exabrial 4y ago
Looks like you got downvoted because you offended someone ;)

_joel 4y ago

Been in this game for 25+ years and this is the first I've heard of this tag :)

masswerk 4y ago

> There is no opportunity for websites to provide a message like “you have not registered yet, go here”. As I remember it, you had to buy a certificate from a CA and provide some real-world credentials along with this, and this wouldn't have been an instant process. Would this even have accepted self-signed certificates (as it seems to be suggested here)?

Avamander 4y ago
You don't need to, it just depends on who's your source of identity. The mTLS handshake includes exchanging which CA's are accepted, AFAIK. In some cases it's some commercial entity, in others it's a country itself, but nobody stops you from using your own CA.
- masswerk 4y ago
  I was just mentioning this, because I had a personal email certificate back then (when this became an integrated option with the built-in Netscape Navigator email client and the like), and this was a rather convoluted process and it took about a week. And, as I remember it, there were just a few options and the process was different for each. Which may explain the "poor UI": this was something you really had to want and you had to jump through a few hoops to achieve this, the entire process wasn't exactly user friendly, and there wasn't even a standard process or standard requirements. So how could you point someone at a link, “you have not registered yet, go here”? You'd probably include an entire paragraph explaining what was required and link to several CA sites in order to obtain a valid certificate.
  - Avamander 4y ago
    > So how could you point someone at a link, “you have not registered yet, go here”? You'd probably include an entire paragraph explaining what was required and link to several CA sites in order to obtain a valid certificate. Well as I said, it will be complex if it's some enterprise CA you want your users to use. It's very easy if just everyone in your country has a certificate already. It's fairly easy if you use your own CA and just give the users the .p12 to install. E-mail certificates, S/MIME, is a bit more complex and not exactly the same - there you'd actually want some larger publicly trusted entity to be used. (Though some already-deployed multi-purpose certificates do exist in some EU countries.)

machina_ex_deus 4y ago

I wish it was easier to just do authentication based on self-signed client certificates instead of passwords. Instead of cookies saving your login, do key-exchange of temporary client certificate. If it was done properly, it has the bonus security that it's completely immune to XSS stealing your authentication on the website - even if the website was subject to some XSS, they can't steal your authentication cookies, and the client certificate is inaccessible to JavaScript.

nayuki 4y ago

My only time ever seeing and using client-side certificates was when I used StartSSL's service to get a free server certificate. It was an interesting experience and radically different from the usual experience of registering on a website with a username/email and password. Looks like the author says quite a few things about StartSSL's practices too. Just like the article laments, the UI for managing client-side certificates was very basic and not user-friendly; I was using Firefox. I do wish this technology was explored deeper by both webmasters and browsers; I prefer to have one or a few private keys instead of hundreds of different passwords for each website. I want to be immune to password keylogging and server-side database leaks.

peanut-walrus 4y ago

If client certificate UX had not been so completely terrible, there would be whole cybercrime operations and classes of attacks that wouldn't exist. Phishing, cred stuffing, session hijacking, etc - all of these would never have even become an issue. Probably the biggest missed opportunity ever, the cost of not developing a usable UX for client certs is likely in tens or hundreds of billions by now.

amatecha 4y ago

Just as an aside I love this guy's website. No shenanigans, it just works, and probably works on any browser going back at least 10 years. Kudos 100%.

dcow 4y ago

Makes me wonder how WebAuthN will fare. As long as the browser is in control of the UX for managing keypairs, I don't see strong browser crypto ever succeeding, because it will fail in the same way <keygen> did: horrible browser UX. Also nobody wants all their keys stuck in one browser. You need a software layer to help you manage your keys and share them across devices. That is unless every website adopts a "device registration" pattern where a user is just a collection of trusted "devices".

zrail 4y ago
That's the entire point of passkeys. They're natively multi-device.

slondr 4y ago

Gemini uses ssl client certificates as its primary method of authenticating users and keeping track of user sessions. It works really well; a major benefit is that the user is in charge of how long their session exists for.