4 ms·

Fair enough! I'm comfortable with it in terms of security given that HPKP is at least a security feature that makes certain guarantees, but I fully acknowledge

by buu700 11y ago

Fair enough! I'm comfortable with it in terms of security given that HPKP is at least a security feature that makes certain guarantees, but I fully acknowledge that: 1. A future update to browser implementations and/or Web standards could hypothetically break this in terms of availability, DoSing/bricking Cyph for all of our users; and 2. If the server were to violate users' trust by not actually deleting the old TLS private keys, it wouldn't be as outwardly apparent as if it had instead needed to serve malicious code to the client, which is at least a little gross. Ultimately, I think the value of this is in making sure that initial user onboarding is as smooth and easy as possible (without being totally insecure), with the next step on our end being to offer an optional browser extension to fortify the scheme in a less experimental manner. which is a bad idea for other reasons that I hope will become clearer later this year Well, that sounds rather ominous... Are you referring to something specific, and if so is it something you would be at liberty to share (either here publicly or out of band)?

e12e 11y ago
> 1. A future update to browser implementations and/or Web standards For some reason I hadn't really considered that all modern browsers are self-updating, so in a standard setup, all web apps are fundamentally insecure. All it takes is for an agency to steal a code-signing certificate (or get one somehow) - and all efforts are defeated. While bootstrapping based off of gpg-signatures has its own problems (how do you verify the install iso, if you can't know that you have a correct version of gpg/pgp on hand, if you can't (and should not) trust the CA system (SSL/TLS is out)) -- at least you can narrow things down a lot. All of the same issues and more apply to all other software. Mozilla can backdoor your Firefox, Google can backdoor your chrome, Microsoft/Apple can backdoor your IE/Safari and your kernel ... now of course Debian can backdoor your kernel too - but with an open system, it's much easier to control updates -- even if it might be beyond most people to actually verify each and every update themselves. (And to be fair, someone could steal Debian's signing keys at least as easily as they could steal Microsoft's -- and in case of a targeted attack, I find it unlikely that a kernel backdoor in a signed Debian/RedHat/etc update sent to only a handful of machines would be discovered). [ed: I guess the reason to put less trust in browsers than other OS updates, might be a) it adds a second set of things to worry about (the browser runtime etc) beyond the kernel and other userspace, and b) Browsers are very frequently updated, so the opportunity to install a backdoor is quite frequent (assuming one wants to install it subversively, sending a custom update to a handful of clients at the same time as a general update is out) ]
- buu700 11y ago
  That isn't exactly a Web-app-specific problem. If you have native software running malicious code with user-level access (whether it's in your browser or any other random update from your package manager), you should consider the whole machine compromised.

by buu700 11y ago

e12e 11y ago

> 1. A future update to browser implementations and/or Web standards For some reason I hadn't really considered that all modern browsers are self-updating, so in a standard setup, all web apps are fundamentally insecure. All it takes is for an agency to steal a code-signing certificate (or get one somehow) - and all efforts are defeated. While bootstrapping based off of gpg-signatures has its own problems (how do you verify the install iso, if you can't know that you have a correct version of gpg/pgp on hand, if you can't (and should not) trust the CA system (SSL/TLS is out)) -- at least you can narrow things down a lot. All of the same issues and more apply to all other software. Mozilla can backdoor your Firefox, Google can backdoor your chrome, Microsoft/Apple can backdoor your IE/Safari and your kernel ... now of course Debian can backdoor your kernel too - but with an open system, it's much easier to control updates -- even if it might be beyond most people to actually verify each and every update themselves. (And to be fair, someone could steal Debian's signing keys at least as easily as they could steal Microsoft's -- and in case of a targeted attack, I find it unlikely that a kernel backdoor in a signed Debian/RedHat/etc update sent to only a handful of machines would be discovered). [ed: I guess the reason to put less trust in browsers than other OS updates, might be a) it adds a second set of things to worry about (the browser runtime etc) beyond the kernel and other userspace, and b) Browsers are very frequently updated, so the opportunity to install a backdoor is quite frequent (assuming one wants to install it subversively, sending a custom update to a handful of clients at the same time as a general update is out) ]

buu700 11y ago
That isn't exactly a Web-app-specific problem. If you have native software running malicious code with user-level access (whether it's in your browser or any other random update from your package manager), you should consider the whole machine compromised.