4 ms·
This question might be hilariously naive... but why don't web browsers make signed requests, just as web servers make signed responses? If I create an account
by hughes 12y ago
This question might be hilariously naive... but why don't web browsers make signed requests, just as web servers make signed responses?
If I create an account on a website, then associate a public key with my account, shouldn't the browser be able to sign each request with my key? The website then wouldn't ever even have to deal with cookies or sessions as long as I was logged in to my browser.
Or better yet, if my key is publicly known and trusted, couldn't a website know who I am before I even create an account? It could skip the signup process entirely.
- NathanKP 12y agoI'm sure that tracking services and ad companies would love signed requests.
- hughes 12y agoWell, it could maybe be an opt-in feature, like when a site requests to use your webcam or microphone. A small prompt that the server is requesting to access your identity or something.
- gergles 12y agohttps://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/ https://pilif.github.io/2008/05/why-is-nobody-using-ssl-clie...
- duncankl 12y agoThanks for the link! I added it to the article.
- scott_karana 12y agoThis idea is exactly what I've always wanted, too. As others point out, it would definitely have to be opt-in, or it would be a great way to track. (It would be nice to have ephemeral keys per-site, too, a la Bitcoin: why have a publically unified identity?)
- tomjen3 12y agoThat features has been in substantially every browser for years, I am pretty sure IE 5 had it. The problem is that the UI for client side certificates is of-putting, inconsistent and terrible in every single browser (also people expect to be able to use your web service from more than one computer).
- vertex-four 12y ago> but why don't web browsers make signed requests, just as web servers make signed responses? They can. The WebID people at the W3C are trying to make a standard out of this, that would allow for federated authentication in which you can securely share data with websites you visit. (They're not getting terribly far - huge portions of the stack are missing around the subject of "tell a server you own that another server can access <these bits of data>, where the other server is identified using a WebID".) The downsides? Basically, the UI sucks and is inconsistent between browsers, up to and including failing to let you log out or have multiple accounts on a website.
- e12e 12y agoYou can use client side (x509) certs for auth over ssl/tls (and also for ssh - in theory at least. I've never tried that). Cacert.org uses client certs for authentication in the web app/page for generating certs for example. I believe the rest of the session is handled similarly to regular ssl/tls (in essence negotiating a shared secret to use as a session key for symmetric encryption, along with some kind of signature to build an authenticated cipher -- if a symmetric authenticated cipher can't be negotiated). My bank used x509 certs for a while -- but in the end it proved too hard both on users/support and on developers (catering to all browsers - as cert management has to be integrated in the browser ui/chrome -- and so is different for every browser). Another thing people seem to miss here is tha ssh also has its own cert scheme. So you could advertise a server cert in dns - and the client would only need to trust the CA cert (a single cert for an entire organizations ssh servers).