2 ms·
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 witho
by 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 agoIt'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 agoMeh. 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.
- bandrami 4y agoThere's two different problem domains here that people keep stubbornly insisting on solving with the same technology. 1. I care about the identity of the other station. This does require a full PKI (or something like it) 2. I don't care about the identity of the other station I just don't want some third-party rando listening in. This is the majority of my web traffic, personally: I don't trust ycombinator.com any more than I would trust someone pretending to be ycombinator.com, so the verification that they are ycombinator.com doesn't actually do anything. Just encrypt opportunistically, everywhere, and leave the PKI for situations where it actually matters (like, if I were applying to ycombinator or something).
- Avamander 4y agoIt hasn't gone anywhere though, there are entire countries using it. It was just way ahead of its time and by now has regressed a bit from lack of interested parties. TLSv1.3 implementations made renegotiations to mTLS impossible for example, making for example a separate `/login` page not possible. It would be possible to improve the UX, if there'd be an interest. We already have passkeys/webauthn, client certificates aren't much more complex. I also doubt it will go anywhere any time soon for those same reasons.