6 ms·

- A protocol for sites to get my public PGP key for server side use - The discontinuation of using SSL certificates for verification of website identities and

- A protocol for sites to get my public PGP key for server side use - The discontinuation of using SSL certificates for verification of website identities and a move to true fingerprinting ala SSH. - Deprecation of email or rather its insecurity. - Logins on websites with a public / private keypair ala SSH. - A resurgence in sites that let me pick my own anonymous username instead of Facebook, Google or Twitter logins and email addresses as UIDs. - Blocking of any and all forms of popups, including javascript popups, overlays, cookie banners, browser notifications. The web is rapidly becoming a place I don't want to visit anymore.

swiley 9y ago
> Deprecation of email or rather its insecurity. We would need something to replace it with, there is really nothing right now.
- fosco 9y ago
  While I agree, there is definitely movement and recent movement [0][1] , I just wish I had the knowledge to contribute. I am great and figuring out how things work, breaking them and understanding them. Building from scratch is a bit above my head, albeit I have a few ideas.... [0] https://news.ycombinator.com/item?id=14708783 https://news.ycombinator.com/item?id=14708783 [1] https://magmadaemon.org/ https://magmadaemon.org/
  - swiley 9y ago
    We already have standards for encrypting/authenticating email transfer between mail servers and between the server and user agent. This doesn't solve the problem of mail being encrypted in transit. As far as I can tell the server operator can still read the user's mail. What we need is end-to-end encryption, lack of support in MUAs (iphone mail app, thunderbird etc.) is the problem here, it has really nothing to do with the server.
    - yorwba 9y ago
      > lack of support in MUAs (iphone mail app, thunderbird etc.) Thunderbird supports S/MIME out of the box and PGP through an addon, so I'm not sure what other kinds of end-to-end encryption you'd want to see. Not sure about the iPhone mail app.
steven777400 9y ago
The login problem was attempted to be solved by Mozilla's "persona", now deprecated. I like the general idea that I strongly authenticate to my browser, which can then "vouch" for me to various sites using cryptographic tokens that are otherwise useless (so no cracking/stealing passwords, etc). The devil of course would be in the details.
- ben_jones 9y ago
  The devil is that the corporations able to influence this change directly benefit from current identity systems. Google for example has huge infrastructure in place linking its products together and includes tracking and other features that would only work with the current system.
- callahad 9y ago
  Sorry that didn't work out :(
Jtsummers 9y ago
My concept (high level) for dealing with things like server and user identities handled by key pairs: Take keybase (or its conceptual basis) and distribute it. Each domain can host its own key server. You can post proofs on other domains to link domain identities or logins. So now my phone has a key that's attached to the identity jtsummers at legoflambda.org. You have a service. I register the identity jtsummers at legoflambda.org with your service. I can log in using the key from my phone. My laptop has its own key. My yubikey stores a third key for access while I'm traveling without my laptop. Each of those I've connected via some proof mechanism to my key server so I can log into your service using any one of those keys. Google and others can also host a key server so my user at gmail.com identity can also be used or my facebook.com identity, again with multiple keys associated with them from my various devices. And possession of the private key can also be used to access the same services (perhaps paired with something like a TOTP or other shared secret if you want an extra layer of authentication). Now you want to send a message to me, you can have a service similar to what keybase offers. You send a message to any one of my public identities or keys, it gets made available to all of them. You know me here on HN, you send it to that identity. You know me by some other forum handle or by my gmail account you use those. And since my public keys are all available, you can send an encrypted message that will be available to any one of my devices (which I can re-encrypt as I add and remove devices). This also handles a lot of the problem with spam. Spammers now have to take the time to individually encrypt messages for every user. They have to publically post identities and keys so that users can authenticate them. And users can block spammers by blocking the keys associated with them and block an entire identity by blocking all the keys associated with the spamming key. You want to ensure that that email from your bank is legitimate? Your bank should have a publically visible key server that all communications from them make use of. Whether they send the message in the clear with only a signature or if they send an encrypted message to you (preferred for privacy and security anyways). This also helps with applications like signal/whatsapp which are presently tied to a single client instance. Now, I can associate my whatsapp key with multiple other keys (each on different devices, presumably). So you want to send me a whatsapp message, it can now be sent to all my devices. My phone number can still be an identity used by those services, but it's no longer the only one. This was a particularly annoying case for me as I travel internationally with a separate phone than my US phone since it's locked, I had to enable WhatsApp on my travel phone using my primary cell number for ease of friends communicating with me (I don't have to get my secondary number to all of them and remind them to switch back once I'm done). If I could have connected my secondary device to my primary one then all messages sent to my main number would have been received by both, and messages sent from either would all appear to the recipient as belonging to the same identity. ==== This is not a well structured presentation, sorry. It's more the random thoughts that have been hopping around in my head for the last couple months between other more pressing concerns.
criddell 9y ago
I love the encryption ideas. Do you know if PGP public/private key pairs can be used for ephemeral keys? I'd hate to rely on the same secret to store everything throughout time.
- dredmorbius 9y ago
  PGP allows creation of subkeys. I'm not entirely clear that that's useful here, but it might be.
- girvo 9y ago
  I haven't had my morning coffee, but I believe that lack of forward-secrecy is exactly the main drawback with PGP as a protocol; but it's been a while since I looked at it
gruez 9y ago
>The discontinuation of using SSL certificates for verification of website identities and a move to true fingerprinting ala SSH. You do realize that's trust-on-first-connect aka self signed certigicates, right? Especially with LE, thats worse in every way to the CA model. >Logins on websites with a public / private keypair ala SSH. Pretty much client certificates minus PKI.
- thaumasiotes 9y ago
  SSH is only trust-on-first-connect if you choose to behave that way. Whenever you connect to a new machine, it prompts you "I don't recognize this machine, and its fingerprint is XXXX. Do you trust that?" I don't see how the option to trust websites is worse than having a bunch of certificate authorities choose who I'll trust for me.
  - conorgil145 9y ago
    How would you possibly know which fingerprints to trust? Also, do you honestly think there is any hope for the average user to understand what that means and know what to trust and what not to trust? IMO, that is a massive step backwards in usability, which directly impacts the overall security of a given solution. If something is not usable, then people will figure out a way around it and security then goes out the window. For example, if users were responsible for knowing which fingerprints to trust for a given website, they would most likely just click "ok, trust it" for everything. Then, you're overall security goes way down because now people are conditioned to click "accept" to everything, regardless of the impact.
    - dredmorbius 9y ago
      Signed archives of trusted or untrusted fingerprints, distributed by various and independent authorities is one option. Trust is, by definition, an extention of solidity or support. CA is a trust model, which has proved both brittle and unworkable. http://www.etymonline.com/index.php?term=trust&allowed_in_frame=0 http://www.etymonline.com/index.php?term=trust&allowed_in_fr... Google and other services presently provide extended trust and validity assessments for websites: pinned certificates, malware scans, and the like. A limited number of such reliable schemes would scale reasonably well, and should prove useful. I'm not saying "perfect", I'm saying "useful".
kstrauser 9y ago
> The discontinuation of using SSL certificates for verification of website identities and a move to true fingerprinting ala SSH. Would HPKP (https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key...) cover that for you?
antjanus 9y ago
SSH-style login is still something I'd really fucking love. Much more secure way of logging in, easy protocol for storing multiple passwords, and easy authorization/deauthirzation of passwords/keys.
- StavrosK 9y ago
  Client TLS certs already exist, and they are a massive pain for the average user.
  - vacri 9y ago
    I remember StartCom used client TLS certs, the only place where I ever saw them in use, and the browser workflow was certainly clunky. I'd hate to see a non-techie have to deal with it.
    - BenjiWiebe 9y ago
      They worked quite smoothly for me. I actually liked StartCom's login process.
  - adrianratnapala 9y ago
    So I have heard of client TLS authentication, but does it exist for the web (I mean just in principle, not whether it is really used). That is, do browsers support it? The thing is, if it is a massive pain for average users, then that is an own-goal. Look at SSH: there is no certification chain there. All you do is generate a keypair and then (here's the awkward bit) magic the pubkey over to the server. It would be easy enough for a website to make pubkey installation a seamless part of the sign-on workflow.
    - tptacek 9y ago
      Yes, browsers have supported client certificates for decades and continue to today.
    - fragmede 9y ago

swiley 9y ago

> Deprecation of email or rather its insecurity. We would need something to replace it with, there is really nothing right now.

fosco 9y ago
While I agree, there is definitely movement and recent movement [0][1] , I just wish I had the knowledge to contribute. I am great and figuring out how things work, breaking them and understanding them. Building from scratch is a bit above my head, albeit I have a few ideas.... [0] https://news.ycombinator.com/item?id=14708783 https://news.ycombinator.com/item?id=14708783 [1] https://magmadaemon.org/ https://magmadaemon.org/
- swiley 9y ago
  We already have standards for encrypting/authenticating email transfer between mail servers and between the server and user agent. This doesn't solve the problem of mail being encrypted in transit. As far as I can tell the server operator can still read the user's mail. What we need is end-to-end encryption, lack of support in MUAs (iphone mail app, thunderbird etc.) is the problem here, it has really nothing to do with the server.
  - yorwba 9y ago
    > lack of support in MUAs (iphone mail app, thunderbird etc.) Thunderbird supports S/MIME out of the box and PGP through an addon, so I'm not sure what other kinds of end-to-end encryption you'd want to see. Not sure about the iPhone mail app.

steven777400 9y ago

The login problem was attempted to be solved by Mozilla's "persona", now deprecated. I like the general idea that I strongly authenticate to my browser, which can then "vouch" for me to various sites using cryptographic tokens that are otherwise useless (so no cracking/stealing passwords, etc). The devil of course would be in the details.

ben_jones 9y ago
The devil is that the corporations able to influence this change directly benefit from current identity systems. Google for example has huge infrastructure in place linking its products together and includes tracking and other features that would only work with the current system.
callahad 9y ago
Sorry that didn't work out :(

Jtsummers 9y ago

My concept (high level) for dealing with things like server and user identities handled by key pairs: Take keybase (or its conceptual basis) and distribute it. Each domain can host its own key server. You can post proofs on other domains to link domain identities or logins. So now my phone has a key that's attached to the identity jtsummers at legoflambda.org. You have a service. I register the identity jtsummers at legoflambda.org with your service. I can log in using the key from my phone. My laptop has its own key. My yubikey stores a third key for access while I'm traveling without my laptop. Each of those I've connected via some proof mechanism to my key server so I can log into your service using any one of those keys. Google and others can also host a key server so my user at gmail.com identity can also be used or my facebook.com identity, again with multiple keys associated with them from my various devices. And possession of the private key can also be used to access the same services (perhaps paired with something like a TOTP or other shared secret if you want an extra layer of authentication). Now you want to send a message to me, you can have a service similar to what keybase offers. You send a message to any one of my public identities or keys, it gets made available to all of them. You know me here on HN, you send it to that identity. You know me by some other forum handle or by my gmail account you use those. And since my public keys are all available, you can send an encrypted message that will be available to any one of my devices (which I can re-encrypt as I add and remove devices). This also handles a lot of the problem with spam. Spammers now have to take the time to individually encrypt messages for every user. They have to publically post identities and keys so that users can authenticate them. And users can block spammers by blocking the keys associated with them and block an entire identity by blocking all the keys associated with the spamming key. You want to ensure that that email from your bank is legitimate? Your bank should have a publically visible key server that all communications from them make use of. Whether they send the message in the clear with only a signature or if they send an encrypted message to you (preferred for privacy and security anyways). This also helps with applications like signal/whatsapp which are presently tied to a single client instance. Now, I can associate my whatsapp key with multiple other keys (each on different devices, presumably). So you want to send me a whatsapp message, it can now be sent to all my devices. My phone number can still be an identity used by those services, but it's no longer the only one. This was a particularly annoying case for me as I travel internationally with a separate phone than my US phone since it's locked, I had to enable WhatsApp on my travel phone using my primary cell number for ease of friends communicating with me (I don't have to get my secondary number to all of them and remind them to switch back once I'm done). If I could have connected my secondary device to my primary one then all messages sent to my main number would have been received by both, and messages sent from either would all appear to the recipient as belonging to the same identity. ==== This is not a well structured presentation, sorry. It's more the random thoughts that have been hopping around in my head for the last couple months between other more pressing concerns.

criddell 9y ago

I love the encryption ideas. Do you know if PGP public/private key pairs can be used for ephemeral keys? I'd hate to rely on the same secret to store everything throughout time.

dredmorbius 9y ago
PGP allows creation of subkeys. I'm not entirely clear that that's useful here, but it might be.
girvo 9y ago
I haven't had my morning coffee, but I believe that lack of forward-secrecy is exactly the main drawback with PGP as a protocol; but it's been a while since I looked at it

gruez 9y ago

>The discontinuation of using SSL certificates for verification of website identities and a move to true fingerprinting ala SSH. You do realize that's trust-on-first-connect aka self signed certigicates, right? Especially with LE, thats worse in every way to the CA model. >Logins on websites with a public / private keypair ala SSH. Pretty much client certificates minus PKI.

thaumasiotes 9y ago
SSH is only trust-on-first-connect if you choose to behave that way. Whenever you connect to a new machine, it prompts you "I don't recognize this machine, and its fingerprint is XXXX. Do you trust that?" I don't see how the option to trust websites is worse than having a bunch of certificate authorities choose who I'll trust for me.
- conorgil145 9y ago
  How would you possibly know which fingerprints to trust? Also, do you honestly think there is any hope for the average user to understand what that means and know what to trust and what not to trust? IMO, that is a massive step backwards in usability, which directly impacts the overall security of a given solution. If something is not usable, then people will figure out a way around it and security then goes out the window. For example, if users were responsible for knowing which fingerprints to trust for a given website, they would most likely just click "ok, trust it" for everything. Then, you're overall security goes way down because now people are conditioned to click "accept" to everything, regardless of the impact.
  - dredmorbius 9y ago
    Signed archives of trusted or untrusted fingerprints, distributed by various and independent authorities is one option. Trust is, by definition, an extention of solidity or support. CA is a trust model, which has proved both brittle and unworkable. http://www.etymonline.com/index.php?term=trust&allowed_in_frame=0 http://www.etymonline.com/index.php?term=trust&allowed_in_fr... Google and other services presently provide extended trust and validity assessments for websites: pinned certificates, malware scans, and the like. A limited number of such reliable schemes would scale reasonably well, and should prove useful. I'm not saying "perfect", I'm saying "useful".

kstrauser 9y ago

> The discontinuation of using SSL certificates for verification of website identities and a move to true fingerprinting ala SSH. Would HPKP (https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key...) cover that for you?

antjanus 9y ago

SSH-style login is still something I'd really fucking love. Much more secure way of logging in, easy protocol for storing multiple passwords, and easy authorization/deauthirzation of passwords/keys.

StavrosK 9y ago
Client TLS certs already exist, and they are a massive pain for the average user.
- vacri 9y ago
  I remember StartCom used client TLS certs, the only place where I ever saw them in use, and the browser workflow was certainly clunky. I'd hate to see a non-techie have to deal with it.
  - BenjiWiebe 9y ago
    They worked quite smoothly for me. I actually liked StartCom's login process.
- adrianratnapala 9y ago
  So I have heard of client TLS authentication, but does it exist for the web (I mean just in principle, not whether it is really used). That is, do browsers support it? The thing is, if it is a massive pain for average users, then that is an own-goal. Look at SSH: there is no certification chain there. All you do is generate a keypair and then (here's the awkward bit) magic the pubkey over to the server. It would be easy enough for a website to make pubkey installation a seamless part of the sign-on workflow.
  - tptacek 9y ago
    Yes, browsers have supported client certificates for decades and continue to today.
  - fragmede 9y ago