CloudFlare Keyless SSL WAS Re: Snowden on the Twitters
An oldie, somewhat OT. I enjoyed CF's bit of engineering here - of course CF is still a point where they are working with injectable plaintext. At least they don't have your private key material. https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/ What would be solid is if there were a browser module that did several things: Eliminated JavaScript dynamic calls (eval, new function(), setTimeout, setInterval, so on.) Eliminate 3rd party assets. Allowed web assets to be signed. Allowed sets of web assets to be versioned (and attested to by 3rd parties.) Dynamic HTML and JS (read, non-static HTML & JS) would not be supported. The combination of signing, versioning and lack of dynamic features paves the way for uninjectable, client-side in browser encryption/decryption. Something AFAIK we cannot do today. Is anyone working on it? -Travis On Wed, Sep 30, 2015 at 11:23 AM, Georgi Guninski <guninski@guninski.com> wrote:
On Wed, Sep 30, 2015 at 01:26:18AM -0400, grarpamp wrote:
How this scores on twatter:
1.03 meeelion followers for about 23 hours on twatter? (not sure about the error terms).
-- Twitter <https://twitter.com/tbiehn> | LinkedIn <http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn> | TravisBiehn.com <http://www.travisbiehn.com> | Google Plus <https://plus.google.com/+TravisBiehn>
On Thu, Oct 1, 2015, at 01:50 AM, Travis Biehn wrote:
What would be solid is if there were a browser module that did several things: Eliminated JavaScript dynamic calls (eval, new function(), setTimeout, setInterval, so on.) Eliminate 3rd party assets. Allowed web assets to be signed. Allowed sets of web assets to be versioned (and attested to by 3rd parties.)
The combination of signing, versioning and lack of dynamic features paves the way for uninjectable, client-side in browser encryption/decryption. Something AFAIK we cannot do today. Is anyone working on it?
So Nginx has a built-in module "ngx_http_gzip_module" which does the following (if "Accept-Encoding: gzip" was part of the request headers) : - Sees request for "foo.html" - Checks if "foo.html.gz" exists - If so, serves that in place of the "foo.html" - If not, gzips "foo.html" on the fly What would be nice is an Nginx module which did the same type of thing, but for hashing the body: - Sees request for "foo.html" - Checks if "foo.html.sha256" exists - If so, serves "foo.html" along with "Content-Hash: <sha256>" header, taken from contents of "foo.html.sha256" - If not, serves "foo.html" along with "Content-Hash: <sha256>" header, but calculated on the fly This would be a cheap and easy way to get some form of content hashing. Thoughts? Alfie -- Alfie John alfiej@fastmail.fm
So, one of the difficulties w/ web-apps is that the 'code' is dynamic. You cannot implement a secure system if your attacker can change the code at any point in time. As is the threat model with backends, which attest to their 'trust me' security (a la lavabit, hushmail and so on) - so is the problem with client side code. If you build a web-app which does in-browser encryption and never sends the encryption key to the backend your attacker can simply modify the static JS source, DOM inject and XSS their way to your sweet sweet encrypted keys. Even if you audit your code at one point in time, you aren't certain it doesn't change with every request to the server. SO The first hurdle here is allowing users to reason about 'versions of web-app client assets' - if any part of the 'web-app client' relies on dynamic / non static JS, the application cannot effectively be 'versioned' (unless those sub-components are similarly versionable). A subset of HTML and JS is defined (safe javascript language subsets are a fail) AND the JS VM is modified to 'lock in' its object defns after loading. So, then you can take the set of client side assets (html, js, images so on) hash each, add some version metadata and sign it. Version 1. Now, users with the browser mod / plugin can then see version 1 of the site. I can go out and post to CPunks statements like, Version 1 of el8notes never sends your plaintext password to the server and all of your communiques are encrypted before being sent to the server, and have them hold true both now and in the future. If you trust version 1 of el8notes, or you trust my assessments of el8mailer you can then tell your sweet plugin: Version 1 of el8notes, signature whatever is a-ok in my book. Of course, this might not even require the participation of content producers. Such a plugin could, in theory, create its own versioning for web assets & distribute those observations to a P2P network. -Travis On Wed, Sep 30, 2015 at 4:52 PM, Alfie John <alfiej@fastmail.fm> wrote:
On Thu, Oct 1, 2015, at 01:50 AM, Travis Biehn wrote:
What would be solid is if there were a browser module that did several things: Eliminated JavaScript dynamic calls (eval, new function(), setTimeout, setInterval, so on.) Eliminate 3rd party assets. Allowed web assets to be signed. Allowed sets of web assets to be versioned (and attested to by 3rd parties.)
The combination of signing, versioning and lack of dynamic features paves the way for uninjectable, client-side in browser encryption/decryption. Something AFAIK we cannot do today. Is anyone working on it?
So Nginx has a built-in module "ngx_http_gzip_module" which does the following (if "Accept-Encoding: gzip" was part of the request headers) :
- Sees request for "foo.html" - Checks if "foo.html.gz" exists - If so, serves that in place of the "foo.html" - If not, gzips "foo.html" on the fly
What would be nice is an Nginx module which did the same type of thing, but for hashing the body:
- Sees request for "foo.html" - Checks if "foo.html.sha256" exists - If so, serves "foo.html" along with "Content-Hash: <sha256>" header, taken from contents of "foo.html.sha256" - If not, serves "foo.html" along with "Content-Hash: <sha256>" header, but calculated on the fly
This would be a cheap and easy way to get some form of content hashing.
Thoughts?
Alfie
-- Alfie John alfiej@fastmail.fm
-- Twitter <https://twitter.com/tbiehn> | LinkedIn <http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn> | TravisBiehn.com <http://www.travisbiehn.com> | Google Plus <https://plus.google.com/+TravisBiehn>
On Thu, Oct 1, 2015, at 07:45 AM, Travis Biehn wrote:
So, one of the difficulties w/ web-apps is that the 'code' is dynamic. You cannot implement a secure system if your attacker can change the code at any point in time. As is the threat model with backends, which attest to their 'trust me' security (a la lavabit, hushmail and so on) - so is the problem with client side code. If you build a web-app which does in-browser encryption and never sends the encryption key to the backend your attacker can simply modify the static JS source, DOM inject and XSS their way to your sweet sweet encrypted keys. Even if you audit your code at one point in time, you aren't certain it doesn't change with every request to the server.
SO
The first hurdle here is allowing users to reason about 'versions of web-app client assets' - if any part of the 'web-app client' relies on dynamic / non static JS, the application cannot effectively be 'versioned' (unless those sub-components are similarly versionable). A subset of HTML and JS is defined (safe javascript language subsets are a fail) AND the JS VM is modified to 'lock in' its object defns after loading.
So, then you can take the set of client side assets (html, js, images so on) hash each, add some version metadata and sign it. Version 1.
Front page of HN: https://hacks.mozilla.org/2015/09/subresource-integrity-in-firefox-43/ Alfie -- Alfie John alfiej@fastmail.fm
On Thu, Oct 01, 2015 at 11:48:33PM +1000, Alfie John wrote:
Front page of HN:
https://hacks.mozilla.org/2015/09/subresource-integrity-in-firefox-43/
Lol, I don't trust neither mozilla nor google (in practice owner of the former). Before trying to secure ``mobile code'', they should _try_ to secure the platform (maybe they call it kernel) on which malware runs. Ever bothered to check the rates at which mozilla updates occur? Ever read a mozilla security advisory? (usually it essentially reads "multiple parties disclosed multiple vulnerabilities, check HIDDEN BUGZILLA/PRIVATE-CVE)
On Fri, Oct 2, 2015, at 12:43 AM, Georgi Guninski wrote:
On Thu, Oct 01, 2015 at 11:48:33PM +1000, Alfie John wrote:
Front page of HN:
https://hacks.mozilla.org/2015/09/subresource-integrity-in-firefox-43/
Lol, I don't trust neither mozilla nor google (in practice owner of the former).
Before trying to secure ``mobile code'', they should _try_ to secure the platform (maybe they call it kernel) on which malware runs.
Ever bothered to check the rates at which mozilla updates occur?
Ever read a mozilla security advisory? (usually it essentially reads "multiple parties disclosed multiple vulnerabilities, check HIDDEN BUGZILLA/PRIVATE-CVE)
If that's the case, how do you Internet? Alfie -- Alfie John alfiej@fastmail.fm
On Fri, Oct 02, 2015 at 01:04:58AM +1000, Alfie John wrote:
On Fri, Oct 2, 2015, at 12:43 AM, Georgi Guninski wrote:
On Thu, Oct 01, 2015 at 11:48:33PM +1000, Alfie John wrote:
Front page of HN:
https://hacks.mozilla.org/2015/09/subresource-integrity-in-firefox-43/
Lol, I don't trust neither mozilla nor google (in practice owner of the former).
Before trying to secure ``mobile code'', they should _try_ to secure the platform (maybe they call it kernel) on which malware runs.
Ever bothered to check the rates at which mozilla updates occur?
Ever read a mozilla security advisory? (usually it essentially reads "multiple parties disclosed multiple vulnerabilities, check HIDDEN BUGZILLA/PRIVATE-CVE)
If that's the case, how do you Internet?
Using as little javascript as possible, not visiting JS sites (this doesn't mean I am not pwned). btw, the link you gave made laugh, from it: <script src="https://code.jquery.com/jquery-2.1.4.min.js" integrity="sha384-R4/ztc4ZlRqWjqIuvf6RX5yb/v90qNGx6fS48N0tRxiGkqveZETq72KgDVJCp2TC" crossorigin="anonymous"></script> Observe that they are loading it from HTTPS and after that they verify, lol. Is this public admission that HTTPS is broken beyond repair? As someone already pointed out, ``mobile code'' is tricky stuff. If the quoted script had |eval(stuff)|, the signature is pointless, since the code is dynamic.
participants (3)
-
Alfie John -
Georgi Guninski -
Travis Biehn