4 ms·

This is really polarizing issue for a lot of people, so I'll be strong on my opinion (and it looks? like? I can't see what the author's opinion is? unless I buy

This is really polarizing issue for a lot of people, so I'll be strong on my opinion (and it looks? like? I can't see what the author's opinion is? unless I buy the book?) which is: It seems like the "everybody is doing it this way" thinking is currently about having strong server side security. But I believe that fundamentally opens/leaves-out the browser as a loophole. Yet the common criticism against end-to-end encryption in the browser (even with the native Web Crypto API) is that JS-land can never be treated seriously (and you probably shouldn't). BUT I feel like that leads to not even trying, and adding anything is better than nothing. So I/we/others are trying (for instance, see this HackerNoon article on "How to Build a P2P end-to-end encrypted Twitter" http://hackernoon.com/so-you-want-to-build-a-p2p-twitter-with-e2e-encryption-f90505b2ff8 http://hackernoon.com/so-you-want-to-build-a-p2p-twitter-wit... ). Because my philosophy is that no matter how insecure JavaScript may be, it is a whole let less secure than trusting a 3rd party corporation (Google, Facebook, whoever) with your data openly, that you then hope they keep secure -- that just seems like ignorance. Yet, I doubt people will come around to this for a long time (they'll be pushed into it because of Bitcoin and other forces), but it doesn't seem popular amongst the "this is how we've always done it" way of thinking. Shouldn't we at least push in that direction? The ideal: Hardware wallets that trusted-open-source-verified-auditied web browsers have JS APIs that pass-through to. Then JS doesn't handle it, it won't be in browser memory, and even if the OS is compromised you'd have to be at Intel-level spectre meltdowns before the hardware wallet can be cracked. Admittedly, I feel naive even hoping/thinking/believing that such security could/would/will exist given how many things could go wrong. But again, I still feel like that is better than central servers storing all our data maybe-encrypted.

tasn 9y ago
Shameless plug: I recently wrote a browser extension that verifies (using PGP) the integrity of the page, and thanks to subresource-integrity also the integrity of external scripts and css, making it possible to trust that the JavaScript application you are running is what the developers intended you to be running. Making E2E encryption in the browser much safer. Just to give a counter to your "is that JS-land can never be treated seriously" statement. Link: https://github.com/tasn/webext-signed-pages/ https://github.com/tasn/webext-signed-pages/ It's used by EteSync to secure its web client.
- twiss 9y ago
  Shameless plug #2: I've been using Service Workers to achieve something similar, without using extensions: http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Apps-using-Service-Worker http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap...
  - marknadal 9y ago
    YESSSSSSSS!!!! To both of you. This is what I want and makes me super happy there are people like you. Can you guys shoot me an email mark@gunDB.io because this is critical! Note: I do believe JS ought be taken seriously but I can't ever seriously tell that to people because nobody does. But I hope because of projects like yours that people stop having arguments against it. Great job, let's chat.
  - tasn 9y ago
    This is great, thanks for sharing! The browser extension works great with browsers, but it's lacking with PWA, and this fills in the gap. \o/
- jimktrains2 9y ago
  How does this prevent an attacker on the server from changing the page? (How is trust verified?) Also, this doesn't seem suited to dynamic applications.
  - drdaeman 9y ago
    Not an author, but each user has to manually provide an URL pattern and public key, which are meant to be verified out of band. If you don't - visiting the signed pages won't do anything. The extension would just say "no signature expected" and won't even show there is something (i.e. no "noticed an unknown untrusted signature" statuses).
- drdaeman 9y ago
  Thanks! It's very useful, but I wonder why you've decided on inline signing, in a HTML comment. I don't mean to argue about different approaches, but curious if you see something that I don't (so maybe I need to adjust what I'm doing). Just that I've also used GnuPG to sign pages, and I went with a different approach. - Do you see any issues with detached signatures? Modifying HTML file is complicated, adding a <link rel="openpgp signature" href="page.html.sig" /> (included into the signed content) is easy and doesn't require any custom tooling for signing. Just `gpg --armor --detach-sig page.html` and everything's ready. I have this (not exactly) as one step of a staging CI pipeline: [ -z "${SIGN_PRIVATE_KEY}" ] || ( gpg -v --import <(echo "${SIGN_PRIVATE_KEY}") && find ./output -type f $ -name "*.html" -o -name "*.pdf" $ -exec gpg --armor --detach-sign '{}' \; ) And it just works, no extra requirements. Very similar principle is applied to production system, but with manual signing (`make sign`) rather than CI-entrusted key. But then I don't have a browser extension, but a small watchdog daemon in Go (using golang.org/x/crypto/openpgp) that does the checks for me. - Or, why not HTTP headers? Something like "X-OpenPGP-Signature" or RFC6648-compliant "vnd.com.stosb.gpg.signature" would also work. HTTP trailers are also an option, I guess, but they're more obscure stuff so probably a worse idea (unless server has the subkey and signs dynamic content on the fly - then trailers can be useful, as opposed to buffering data). I am using GnuPG signing to verify that some pages weren't tampered with. But I've used detached signatures instead. Initially, I've had an idea of embedding signatures inline, but I found it much easier to implement, and the only downside was that both files had to be updated simultaneously, possibly complicating the deployment logic. I've just tolerated possible deploy-time warnings, keeping check that monitoring status get back to green in a second, but e.g. deploying to a different directory and atomically replacing a symlink should've worked, as well as using Docker containers and re-routing traffic.

tasn 9y ago

Shameless plug: I recently wrote a browser extension that verifies (using PGP) the integrity of the page, and thanks to subresource-integrity also the integrity of external scripts and css, making it possible to trust that the JavaScript application you are running is what the developers intended you to be running. Making E2E encryption in the browser much safer. Just to give a counter to your "is that JS-land can never be treated seriously" statement. Link: https://github.com/tasn/webext-signed-pages/ https://github.com/tasn/webext-signed-pages/ It's used by EteSync to secure its web client.

twiss 9y ago
Shameless plug #2: I've been using Service Workers to achieve something similar, without using extensions: http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Apps-using-Service-Worker http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap...
- marknadal 9y ago
  YESSSSSSSS!!!! To both of you. This is what I want and makes me super happy there are people like you. Can you guys shoot me an email mark@gunDB.io because this is critical! Note: I do believe JS ought be taken seriously but I can't ever seriously tell that to people because nobody does. But I hope because of projects like yours that people stop having arguments against it. Great job, let's chat.
- tasn 9y ago
  This is great, thanks for sharing! The browser extension works great with browsers, but it's lacking with PWA, and this fills in the gap. \o/
jimktrains2 9y ago
How does this prevent an attacker on the server from changing the page? (How is trust verified?) Also, this doesn't seem suited to dynamic applications.
- drdaeman 9y ago
  Not an author, but each user has to manually provide an URL pattern and public key, which are meant to be verified out of band. If you don't - visiting the signed pages won't do anything. The extension would just say "no signature expected" and won't even show there is something (i.e. no "noticed an unknown untrusted signature" statuses).
drdaeman 9y ago
Thanks! It's very useful, but I wonder why you've decided on inline signing, in a HTML comment. I don't mean to argue about different approaches, but curious if you see something that I don't (so maybe I need to adjust what I'm doing). Just that I've also used GnuPG to sign pages, and I went with a different approach. - Do you see any issues with detached signatures? Modifying HTML file is complicated, adding a <link rel="openpgp signature" href="page.html.sig" /> (included into the signed content) is easy and doesn't require any custom tooling for signing. Just `gpg --armor --detach-sig page.html` and everything's ready. I have this (not exactly) as one step of a staging CI pipeline: [ -z "${SIGN_PRIVATE_KEY}" ] || ( gpg -v --import <(echo "${SIGN_PRIVATE_KEY}") && find ./output -type f $ -name "*.html" -o -name "*.pdf" $ -exec gpg --armor --detach-sign '{}' \; ) And it just works, no extra requirements. Very similar principle is applied to production system, but with manual signing (`make sign`) rather than CI-entrusted key. But then I don't have a browser extension, but a small watchdog daemon in Go (using golang.org/x/crypto/openpgp) that does the checks for me. - Or, why not HTTP headers? Something like "X-OpenPGP-Signature" or RFC6648-compliant "vnd.com.stosb.gpg.signature" would also work. HTTP trailers are also an option, I guess, but they're more obscure stuff so probably a worse idea (unless server has the subkey and signs dynamic content on the fly - then trailers can be useful, as opposed to buffering data). I am using GnuPG signing to verify that some pages weren't tampered with. But I've used detached signatures instead. Initially, I've had an idea of embedding signatures inline, but I found it much easier to implement, and the only downside was that both files had to be updated simultaneously, possibly complicating the deployment logic. I've just tolerated possible deploy-time warnings, keeping check that monitoring status get back to green in a second, but e.g. deploying to a different directory and atomically replacing a symlink should've worked, as well as using Docker containers and re-routing traffic.