7 ms·

Shameless plug: I recently wrote a browser extension that verifies (using PGP) the integrity of the page, and thanks to subresource-integrity also the integrit

by 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.

by tasn 9y ago

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.