Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[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