[liberationtech] SaferScript (Rough draft)
Scott Arciszewski
kobrasrealm at gmail.com
Sat Sep 28 17:30:59 PDT 2013
That is /ugly/ as heck. Sorry.
https://defuse.ca/b/MQrZXLiE <- link valid for 6 months
On Sat, Sep 28, 2013 at 8:28 PM, Scott Arciszewski <kobrasrealm at gmail.com>wrote:
> Hey LiberationTech,
>
> I was going to try to polish this idea and develop it, but it's probably
> better
> off being developed by people with experience developing Firefox addons
> and/or
> who understand PKI in-and-out. Also, due to complications in my own life,
> I do
> not have the time or energy to invest in such an undertaking.
>
> I've previously shared this with Micah Lee of the EFF and his friend
> Garrett.
>
> This is just a very rough draft. If anyone wants to take this up as a FOSS
> project, feel free; I only ask that Taylor and I be mentioned somewhere in
> the
> credits.
>
>
> ################################################################################
> _____ __ _____ _ _
> / ____| / _| / ____| (_) | |
> | (___ __ _| |_ ___ _ _| (___ ___ _ __ _ _ __ | |_
> \___ \ / _` | _/ _ \ '__\___ \ / __| '__| | '_ \| __|
> ____) | (_| | || __/ | ____) | (__| | | | |_) | |_
> |_____/ \__,_|_| \___|_| |_____/ \___|_| |_| .__/ \__|
> | |
> |_| (The name is
> negotiable)
>
> _______________________________________________________________________________
> \
> ;
> \ Making Javascript Safer, Preventing XSS
> Payloads ;
> \ @voodooKobra (Scott
> Arciszewski) ;
> \ Further suggestions by @DefuseSec (Taylor
> Hornby) ;
>
> \__________________________________________________________________________;
>
> WHAT IS IT?
> An optional way to configure only digitally signed Javascript for
> websites
> set up to use it.
>
> COMPONENTS
> o Browser plugin (Firefox at first, eventually Chrome & Opera?)
> o Netbeans plugin (for developers)
> o CLI Program (integrates with gnupg) for the server
> o Source file on the server
> o Publicly accessible whitelist file
> o Network of notaries which audit the signed whitelists to detect abuse
>
> _____________________
>
> | The Browser Plugin
> \______________________________________________________
> |
> |
> | For security-conscious users, the SaferScript browser plugin would
> request |
> | a whitelist of .js files (and their sha256 checksums), which should
> be |
> | signed by the developer's GPG private
> key. |
> |
> |
> | (Note: In case SHA-256 is ever broken it needs to be able to support
> other |
> | hash functions, such as the SHA-3 family, Whirlpool, and
> RIPEMD.) |
> |
> |
> | If we do not know the public key, we will request it from the server
> and |
> | check with notaries that the user trusts that they see the same key.
> If |
> | the website has been queried before, the notary will also compare
> the |
> | public key it received with the one
> archived. |
> |
> |
> | The code will then verify the signature of the whitelist. If it
> matches, |
> | then each .js file will be downloaded and their checksums will be
> verified |
> | before they are loaded into memory. If any of their checksums
> doesn't |
> | match, then that .js file is not loaded and the user is
> notified. |
> |
> |
> | For public key verification, The browser will then send an SHA-256
> digest |
> | of the whitelist to a notary. If the notary does not have a record of
> that |
> | whitelist, our network will request the whitelist and compare the
> digest |
> | with the one submitted by the user. If it doesn't match, the user
> is |
> | notified and they fail back to a copy that was signed and stored in
> the |
> | public
> record. |
> |
> |
> | If the signature matches but it is an updated version of the
> Javascript |
> | (and the notary has cached a copy of the same whitelist), the user will
> be |
> | notified of the change and asked if they wish to examine the
> differences |
> | between the old version and the new version. (This can be turned off
> for |
> | non-tech-savvy users; all changes that any user experiences should
> be |
> | mirrored on the notaries, assuming they have opted
> in.) |
> |
> |
> | No other Javascript will load. Even inline function calls (onClick=""
> etc) |
> | will have to be rewritten as $("#objectID").click( function() {
> }); |
> |
> |
> | If the GPG signature doesn't match, NO Javascript will load for the
> entire |
> | domain until the developer updates the signed whitelist with new
> checksums |
> | and an updated
> signature. |
> |
> |
> | Two further levels of paranoia will also be available: If a .css file
> is |
> | specified in the whitelist, no other stylesheet changes (outside of
> those |
> | made by trusted Javascript) will be registered. Additionally, if a
> .png, |
> | .jpg, .gif (etc) file is listed, all other images will be
> blacklisted. |
> | These paranoid modes are entirely optional and suited to
> self-contained |
> | apps rather than content portals that depend on user-generated
> content. |
> |
> |
> | Notaries are selected when a user first installs the addon. Trust may
> be |
> | revoked by the user at any time should they change their
> mind. |
> |____________________________________________________________________________|
>
>
> __________________
> | The CLI Program
> \_________________________________________________________
> |
> |
> | For developers who prever to SSH directly into their production
> system, |
> | the CLI program would reconstruct (calculate sha256 checksums and GPG
> sign |
> | the list) the whitelist
> textfile. |
> |
> |
> | root at server~$: saferscript /root/whitelist.src
> /var/www/white.list |
> | Calculating SHA-256
> checksums: |
> |
> /var/www/jquery.js:
> |
> |
> ea3b35ed94f9e600c29ca51d2ee1f6efb03d1389ea5455d2596ca32af1f6aadd
> |
> |
> /var/www/interface.js:
> |
> |
> f75062d19a9e56f0d002f9a93c909636e559ff16b0c8c712e84d207a434e66d8
> |
> | Enter GnuPG Password to sign the new
> whitelist: |
> | Your SaferScript whitelist is located at
> /var/www/white.list |
> | root at server~$:
> _ |
> |____________________________________________________________________________|
>
>
> _____________________
> | The Whitelist Files
> \______________________________________________________
> |
> |
> | There would be two files: One you edit that tells the CLI script which
> .js |
> | files should be checksummed and included in the GPG-signed whitelist,
> and |
> | the latter file which should be served publicly (
> http://domain/white.list) |
> |
> |
> | Source File (typically
> whitelist.src) |
> | - Line 1 should contain the document root
> folder |
> | - Lines 2-n should contain the relative path of each script to be
> included |
> |
> |
> | Public Whitelist (should be
> /white.list) |
> |
> /jquery.js:sha256:ea3b35ed94f9e600c29ca51d2ee1f6efb03d1389ea5455d2596ca...
> |
> |
> /interface.js:sha256:f75062d19a9e56f0d002f9a93c909636e559ff16b0c8c712e8...
> |
> | (Truncated here for the sake of
> formatting) |
> | (Then, the PGP signature goes
> below) |
> |
> |
> | As stated above, the source public whitelist can also contain image or
> CSS |
> | files if the developer is truly
> paranoid. |
> |____________________________________________________________________________|
>
>
> ______________________
> | The Netbeans Plugin
> \_____________________________________________________
> |
> |
> | For convenience when updating a project on a remote server, without
> having |
> | to login through SSH and run the saferscript CLI, a Netbeans plugin
> would |
> | be created that would run the command for you every time you update
> your |
> | Javascript
> files. |
> |
> |
> | The whitelist generation would take place entirely on the developer's
> box, |
> | but an option to mirror your whitelist source file would be
> available. |
> |
> |
> | (Netbeans was chosen because it's currently the best free and open
> source |
> | IDE for PHP projects on a remote
> server.) |
> |____________________________________________________________________________|
>
>
> ________________
> | Notary Network
> \___________________________________________________________
> |
> |
> | Inspired in part by the EFF's SSL Observatory and Moxie
> Marlinspike's |
> | Convergence, we would need to set up a robust network capable of
> handling |
> | three
> tasks: |
> | 1. When a user passes a hostname:SHA hash of a server's whitelist,
> the |
> | notaries will see if the hash already exists in its records. If
> it |
> | doesn't, the notary requests the white.list, records it, and
> also |
> | verifies that the copy it has on file is the same as the copy the
> user |
> | forwarded. This should prevent targeted
> attacks. |
> | 2. When a user passes the hostname:SHA hash of a server's purported
> GPG |
> | public key, the server will check to see if it's a known key for
> that |
> | particular host. It will also request the key itself and make sure
> it |
> | sees the same key, and store a publicly auditable
> copy. |
> | 3. It allows the general public to verify and audit the signed code
> on |
> | websites that use this feature, by mirroring this data on a public
> web |
> | site on a different
> network. |
> |____________________________________________________________________________|
>
>
>
> .~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~,
> { PROCESS FLOW (PROGRAM
> LOGIC) }
>
> `^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^'
> A request is sent to a webserver
> Has the user already established the credibility of the code this session?
> YES:
> > Just load whatever settings were cached to minimize overhead
> NO:
> > Do we have a cached copy of the development team's GPG key?
> > YES:
> >> Continue.
> > NO:
> >> !Fallback feature so we can support Tor Hidden Services
> >> (Make it possible to disable this feature?)
> >> Does /dev.public exist?
> >> YES:
> >>> Fetch /dev.public, which should contain the public key
> >>> SHA2/3 hash the file
> >>> Pass it to the Notaries for GPG key verification
> >>> The notaries will let you know if that's a known public key on
> >>> file for that hostname. This is a weak authentication so...
> >>> Prompt the user whether or not they trust the public key
> >>> YES:
> >>>> Save the public key to cache for the hostname
> >>> NO:
> >>>> Disable Javascript, require user to confirm a security exemption
> >>>> if they wish to still visit the page.
> >> NO:
> >>> Abort; SaferScript is not deployed on this host
> > Does /white.list exist?
> > YES:
> >> GET /white.list
> >> Verify the GPG Signature with the developer's GPG Public Key
> >> Does it match?
> >> YES:
> >>> Download the .js files
> >>> FOR EACH JS FILE:
> >>>> Calculate the hash digest
> >>>> Does it match?
> >>>> YES:
> >>>>> Do we have a cached copy that's any different than the new one?
> >>>>> YES:
> >>>>>> Alert user to the changes, allow them to review the changes
> between
> >>>>>> both versions and decide whether or not to use the new one or
> the old
> >>>>>> copy of the file
> >>>>> NO:
> >>>>>> Proceed.
> >>>> NO:
> >>>>> Blacklist that file, make sure the user knows.
> >>> IF(SEND_TO_NOTARIES):
> >>>> SHA2/3 the white.list file
> >>>> Send to a trusted notary over TLS (respect proxy
> >>>> settings so it works with Tor, etc)
> >>>> Notary will request the white.list file and SHA2/3 hash it
> >>>> Does it match?
> >>>> YES:
> >>>>> Is it an old copy or a new copy?
> >>>>> NEW:
> >>>>>> Respond affirmatively, but let the user know it's a new copy
> >>>>> OLD:
> >>>>>> Respond affirmatively
> >>>> NO:
> >>>>> The user is being signled out with different copies of the
> Javascript
> >>>>> Reply negatively, offer the user a nonce they can use to request
> >>>>> a trusted copy of the white.list if it's needed
> >> NO:
> >>> Danger, Will Robinson! Let the user know it failed.
> >>> Do we have a copy of trusted (signed) code?
> >>> YES:
> >>>> Use that instead, keeping the user notified that something is
> wrong.
> >>> NO:
> >>>> Disable Javascript, require user to confirm a security exemption
> >>>> if they wish to still visit the page.
> > NO:
> >> Abort. If a GPG key was specified, disable Javascript and require the
> user
> >> to confirm a security exemption if they wish to still visit the page.
> It's
> >> fishy if they specify a key but have no white.list file.
> And then everything else proceeds like normal.
>
> MOTIVATIONS AND DESIGN GOALS
> o Provide a feature analogous to DEP for Javascript (mitigate XSS)
> o Provide a mechanism to deliver signed Javascript code
> o Needs to function even on HTTPS and Tor Hidden Services (no special
> ports)
> o Needs to use existing cryptographic primitives (GPG, SHA2)
> o Needs to be released as free and open source software
> o All code changes need to be publicly auditable in case of attack
> o All code delivered must be neutral; you and I should see the same code
> o Users should have the option to reject "Updates" published by servers
>
> ROADMAP
> o Build a browser plugin that only allows "trusted" Javascript
> o Build a GPG signature verification feature for selecting "trusted" code
> o Build the Command Line Interface tool (C, C++)
> o Build the Netbeans plugin
> o Write the documentation
> o Publish an alpha release
> o Get peer review, code audits
> o Possibly publish an Internet Standard?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130928/cda16639/attachment.html>
More information about the liberationtech
mailing list