diff options
22 files changed, 398 insertions, 839 deletions
diff --git a/amber/menu.txt b/amber/menu.txt index f183e10..56c2295 100644 --- a/amber/menu.txt +++ b/amber/menu.txt @@ -1,7 +1,4 @@ -services - eip - email - chat +download about-us donate vision @@ -44,6 +41,14 @@ docs quick-start single-node-vpn single-node-email + services + couchdb + openvpn + monitor + mx + soledad + tor + webapp troubleshooting tests where-to-look diff --git a/pages/docs/platform/details/faq.md b/pages/docs/platform/details/faq.md index 10cdbe0..7ee20f4 100644 --- a/pages/docs/platform/details/faq.md +++ b/pages/docs/platform/details/faq.md @@ -3,29 +3,6 @@ @summary = "Frequently Asked Questions" @toc = true -Webapp -====== - -How do I set the admins? ------------------------- - -Edit your services/webapp.json (or create it, if it doesn't exist) and place something like the following in it: - - { - "webapp": { - "admins": ["joe"] - } - } - - -Nagios -====== - -How do I find the login information for nagios? ------------------------------------------------ - -The login information is in the secrets.json file, under "nagios_admin" (please note: the login name is 'nagiosadmin', not 'nagios_admin'). - APT =============== @@ -40,7 +17,13 @@ Puppet Where do i find the time a server was last deployed ? ----------------------------------------------------- -The puppet state file on the node indicates the last puppetrun: +Run: + + leap history FILTER + +This will tail the log file `/var/log/leap/deploy-summary.log`. + +If that command fails, you can manually check the puppet state file on the node indicates the last puppetrun: ls -la /var/lib/puppet/state/state.yaml diff --git a/pages/docs/platform/details/webapp.md b/pages/docs/platform/details/webapp.md deleted file mode 100644 index 2b078af..0000000 --- a/pages/docs/platform/details/webapp.md +++ /dev/null @@ -1,282 +0,0 @@ -@title = 'LEAP Web' -@summary = 'The web component of the LEAP Platform, providing user management, support desk, documentation and more.' -@toc = true - -Introduction -=================== - -"LEAP Web" is the webapp component of the LEAP Platform, providing the following services: - -* REST API for user registration. -* Admin interface to manage users. -* Client certificate distribution and renewal. -* User support help tickets. -* Billing -* Customizable and Localized user documentation - -This web application is written in Ruby on Rails 3, using CouchDB as the backend data store. - -It is licensed under the GNU Affero General Public License (version 3.0 or higher). See http://www.gnu.org/licenses/agpl-3.0.html for more information. - -Known problems -==================== - -* Client certificates are generated without a CSR. The problem is that this makes the web - application extremely vulnerable to denial of service attacks. This was not an issue until we - started to allow the possibility of anonymously fetching a client certificate without - authenticating first. - -* By its very nature, the user database is vulnerable to enumeration attacks. These are - very hard to prevent, because our protocol is designed to allow query of a user database via - proxy in order to provide network perspective. - -Integration -=========== - -LEAP web is part of the leap platform. Most of the time it will be customized and deployed in that context. This section describes the integration of LEAP web in the wider framework. The Development section focusses on development of LEAP web itself. - -Configuration & Customization ------------------------------- - -The customization of the webapp for a leap provider happens via two means: - * configuration settings in services/webapp.json - * custom files in files/webapp - -### Configuration Settings - -The webapp ships with a fairly large set of default settings for all environments. They are stored in config/defaults.yml. During deploy the platform creates config/config.yml from the settings in services/webapp.json. These settings will overwrite the defaults. - -### Custom Files - -Any file placed in files/webapp in the providers repository will overwrite the content of config/customization in the webapp. These files will override files of the same name. - -This mechanism allows customizing basically all aspects of the webapp. -See files/webapp/README.md in the providers repository for more. - -### Provider Information ### - -The leap client fetches provider information via json files from the server. The platform prepares that information and stores it in the webapp in public/1/config/*.json. (1 being the current API version). - -Provider Documentation -------------- - -LEAP web already comes with a bit of user documentation. It mostly resides in app/views/pages and thus can be overwritten by adding files to files/webapp/views/pages in the provider repository. You probably want to add your own Terms of Services and Privacy Policy here. -The webapp will render haml, erb and markdown templates and pick translated content from localized files such as privacy_policy.es.md. In order to add or remove languages you have to modify the available_locales setting in the config. (See Configuration Settings above) - -Development -=========== - -Installation ---------------------------- - -Typically, this application is installed automatically as part of the LEAP Platform. To install it manually for testing or development, follow these instructions: - -### TL;DR ### - -Install git, ruby 1.9, rubygems and couchdb on your system. Then run - - gem install bundler - git clone https://leap.se/git/leap_web - cd leap_web - git submodule update --init - bundle install --binstubs - bin/rails server - -### Install system requirements - -First of all you need to install ruby, git and couchdb. On debian based systems this would be achieved by something like - - sudo apt-get install git ruby1.9.3 rubygems couchdb - -We install most gems we depend upon through [bundler](http://gembundler.com). So first install bundler - - sudo gem install bundler - -On Debian Wheezy or later, there is a Debian package for bundler, so you can alternately run ``sudo apt-get install bundler``. - -### Download source - -Simply clone the git repository: - - git clone git://leap.se/leap_web - cd leap_web - -### SRP Submodule - -We currently use a git submodule to include srp-js. This will soon be replaced by a ruby gem. but for now you need to run - - git submodule update --init - -### Install required ruby libraries - - cd leap_web - bundle - -Typically, you run ``bundle`` as a normal user and it will ask you for a sudo password when it is time to install the required gems. If you don't have sudo, run ``bundle`` as root. - -Configuration ----------------------------- - -The configuration file `config/defaults.yml` providers good defaults for most -values. You can override these defaults by creating a file `config/config.yml`. - -There are a few values you should make sure to modify: - - production: - admins: ["myusername","otherusername"] - domain: example.net - force_ssl: true - secret_token: "4be2f60fafaf615bd4a13b96bfccf2c2c905898dad34..." - client_ca_key: "/etc/ssl/ca.key" - client_ca_cert: "/etc/ssl/ca.crt" - ca_key_password: nil - -* `admins` is an array of usernames that are granted special admin privilege. -* `domain` is your fully qualified domain name. -* `force_ssl`, if set to true, will require secure cookies and turn on HSTS. Don't do this if you are using a self-signed server certificate. -* `secret_token`, used for cookie security, you can create one with `rake secret`. Should be at least 30 characters. -* `client_ca_key`, the private key of the CA used to generate client certificates. -* `client_ca_cert`, the public certificate the CA used to generate client certificates. -* `ca_key_password`, used to unlock the client_ca_key, if needed. - -### Provider Settings - -The leap client fetches provider information via json files from the server. -If you want to use that functionality please add your provider files the public/1/config directory. (1 being the current API version). - -Running ------------------------------ - - cd leap_web - bin/rails server - -You will find Leap Web running on `localhost:3000` - -Testing --------------------------------- - -To run all tests - - rake test - -To run an individual test: - - rake test TEST=certs/test/unit/client_certificate_test.rb - or - ruby -Itest certs/test/unit/client_certificate_test.rb - -Engines ---------------------- - -Leap Web includes some Engines. All things in `app` will overwrite the engine behaviour. You can clone the leap web repository and add your customizations to the `app` directory. Including leap_web as a gem is currently not supported. It should not require too much work though and we would be happy to include the changes required. - -If you have no use for one of the engines you can remove it from the Gemfile. Engines should really be plugins - no other engines should depend upon them. If you need functionality in different engines it should probably go into the toplevel. - -# Deployment # - -We strongly recommend using the LEAP platform for deploy. Most of the things documented here are automated as part of the platform. If you want to research how the platform deploys or work on your own mechanism this section is for you. - -These instructions are targeting a Debian GNU/Linux system. You might need to change the commands to match your own needs. - -## Server Preperation ## - -### Dependencies ## - -The following packages need to be installed: - -* git -* ruby1.9 -* rubygems1.9 -* couchdb (if you want to use a local couch) - -### Setup Capistrano ### - -We use puppet to deploy. But we also ship an untested config/deploy.rb.example. Edit it to match your needs if you want to use capistrano. - -run `cap deploy:setup` to create the directory structure. - -run `cap deploy` to deploy to the server. - -## Customized Files ## - -Please make sure your deploy includes the following files: - -* public/1/config/*.json (see Provider Settings section) -* config/couchdb.yml - -## Couch Security ## - -We recommend against using an admin user for running the webapp. To avoid this couch design documents need to be created ahead of time and the auto update mechanism needs to be disabled. -Take a look at test/setup_couch.sh for an example of securing the couch. - -## Design Documents ## - -After securing the couch design documents need to be deployed with admin permissions. There are two ways of doing this: - * rake couchrest:migrate_with_proxies - * dump the documents as files with `rake couchrest:dump` and deploy them - to the couch by hand or with the platform. - -### CouchRest::Migrate ### - -The before_script block in .travis.yml illustrates how to do this: - - mv test/config/couchdb.yml.admin config/couchdb.yml # use admin privileges - bundle exec rake couchrest:migrate_with_proxies # run the migrations - bundle exec rake couchrest:migrate_with_proxies # looks like this needs to run twice - mv test/config/couchdb.yml.user config/couchdb.yml # drop admin privileges - -### Deploy design docs from CouchRest::Dump ### - -First of all we get the design docs as files: - - # put design docs in /tmp/design - bundle exec rake couchrest:dump - -Then we add them to files/design in the site_couchdb module in leap_platform so they get deployed with the couch. You could also upload them using curl or sth. similar. - -# Troubleshooting # - -Here are some less common issues you might run into when installing Leap Web. - -## Cannot find Bundler ## - -### Error Messages ### - -`bundle: command not found` - -### Solution ### - -Make sure bundler is installed. `gem list bundler` should list `bundler`. -You also need to be able to access the `bundler` executable in your PATH. - -## Outdated version of rubygems ## - -### Error Messages ### - -`bundler requires rubygems >= 1.3.6` - -### Solution ### - -`gem update --system` will install the latest rubygems - -## Missing development tools ## - -Some required gems will compile C extensions. They need a bunch of utils for this. - -### Error Messages ### - -`make: Command not found` - -### Solution ### - -Install the required tools. For linux the `build-essential` package provides most of them. For Mac OS you probably want the XCode Commandline tools. - -## Missing libraries and headers ## - -Some gem dependencies might not compile because they lack the needed c libraries. - -### Solution ### - -Install the libraries in question including their development files. - - diff --git a/pages/docs/platform/guide/nodes.md b/pages/docs/platform/guide/nodes.md index cf22544..5135f3b 100644 --- a/pages/docs/platform/guide/nodes.md +++ b/pages/docs/platform/guide/nodes.md @@ -1,106 +1,6 @@ @title = "Nodes" @summary = "Working with nodes, services, tags, and locations." -Node types -================================ - -Every node has one or more services that determines the node's function within your provider's infrastructure. - -When adding a new node to your provider, you should ask yourself four questions: - -* **many or few?** Some services benefit from having many nodes, while some services are best run on only one or two nodes. -* **required or optional?** Some services are required, while others can be left out. -* **who does the node communicate with?** Some services communicate very heavily with other particular services. Nodes running these services should be close together. -* **public or private?** Some services communicate with the public internet, while others only need to communicate with other nodes in the infrastructure. - -Brief overview of the services: - -* **webapp**: The web application. Runs both webapp control panel for users and admins as well as the REST API that the client uses. Needs to communicate heavily with `couchdb` nodes. You need at least one, good to have two for redundancy. The webapp does not get a lot of traffic, so you will not need many. -* **couchdb**: The database for users and user data. You can get away with just one, but for proper redundancy you should have at least three. Communicates heavily with `webapp`, `mx`, and `soledad` nodes. -* **soledad**: Handles the data syncing with clients. Typically combined with `couchdb` service, since it communicates heavily with couchdb. -* **mx**: Incoming and outgoing MX servers. Communicates with the public internet, clients, and `couchdb` nodes. -* **openvpn**: OpenVPN gateway for clients. You need at least one, but want as many as needed to support the bandwidth your users are doing. The `openvpn` nodes are autonomous and don't need to communicate with any other nodes. Often combined with `tor` service. -* **monitor**: Internal service to monitor all the other nodes. Currently, you can have zero or one `monitor` service defined. It is required that the monitor be on the webapp node. It was not designed to be run as a separate node service. -* **tor**: Sets up a tor exit node, unconnected to any other service. -* **dns**: Not yet implemented. - -Webapp ------------------------------------ - -The webapp node is responsible for both the user face web application and the API that the client interacts with. - -Some users can be "admins" with special powers to answer tickets and close accounts. To make an account into an administrator, you need to configure the `webapp.admins` property with an array of user names. - -For example, to make users `alice` and `bob` into admins, create a file `services/webapp.json` with the following content: - - { - "webapp": { - "admins": ["bob", "alice"] - } - } - -And then redeploy to all webapp nodes: - - leap deploy webapp - -By putting this in `services/webapp.json`, you will ensure that all webapp nodes inherit the value for `webapp.admins`. - -Services -================================ - -What nodes do you need for a provider that offers particular services? - -<table class="table table-striped"> -<tr> - <th>Node Type</th> - <th>VPN Service</th> - <th>Email Service</th> - <th>Notes</th> -</tr> -<tr> - <td>webapp</td> - <td>required</td> - <td>required</td> - <td></td> -</tr> -<tr> - <td>couchdb</td> - <td>required</td> - <td>required</td> -<td></td> -</tr> -<tr> - <td>soledad</td> - <td>not used</td> - <td>required</td> -<td></td> -</tr> -<tr> - <td>mx</td> - <td>not used</td> - <td>required</td> - <td></td> -</tr> -<tr> - <td>openvpn</td> - <td>required</td> - <td>not used</td> - <td></td> -</tr> -<tr> - <td>monitor</td> - <td>optional</td> - <td>optional</td> - <td>This service must be on the webapp node</td> -</tr> -<tr> - <td>tor</td> - <td>optional</td> - <td>optional</td> - <td></td> -</tr> -</table> - Locations ================================ diff --git a/pages/docs/platform/details/couchdb.md b/pages/docs/platform/services/couchdb.md index 276bfdc..7bf4e7c 100644 --- a/pages/docs/platform/details/couchdb.md +++ b/pages/docs/platform/services/couchdb.md @@ -1,7 +1,24 @@ -@title = "CouchDB" +@title = "couchdb" +@summary = "Data storage for all user data." -Rebalance Cluster -================= +Topology +------------------------ + +`couchdb` nodes communicate heavily with `webapp`, `mx`, and `soledad` nodes. Typically, `couchdb` nodes will also have the `soledad` service. + +`couchdb` nodes do not need to be reachable from the public internet, although the `soledad` service does require this. + +Configuration +---------------------------- + +There are no options that should be modified for `couchdb` nodes. + +NOTE: The LEAP platform is designed to support many database nodes. The goal is for you to be able to add nodes and remove nodes and everything should rebalance and work smoothly. Currently, however, we are using a broken CouchDB variant called BigCouch. Until we migrate off BigCouch, you should only have one `couchdb` node. More than one will work most of the time, but there are some bugs that can pop up and that are unfixed. + +Manual Tasks +--------------------- + +### Rebalance Cluster Bigcouch currently does not have automatic rebalancing. It will probably be added after merging into couchdb. @@ -39,8 +56,7 @@ If you add a node, or remove one node from the cluster, /srv/leap/couchdb/scripts/couchdb_restoreall.sh -Re-enabling blocked account -=========================== +### Re-enabling blocked account When a user account gets destroyed from the webapp, there's still a leftover doc in the identities db so other ppl can't claim that account without admin's intervention. Here's how you delete that doc and therefore enable registration for that particular account again: @@ -54,8 +70,7 @@ When a user account gets destroyed from the webapp, there's still a leftover doc curl -s --netrc-file /etc/couchdb/couchdb.netrc -X DELETE 'http://127.0.0.1:5984/identities/b25cf10f935b58088f0d547fca823265?rev=2-715a9beba597a2ab01851676f12c3e4a' -How to find out which userstore belongs to which identity ? -=========================================================== +### How to find out which userstore belongs to which identity ? /usr/bin/curl -s --netrc-file /etc/couchdb/couchdb.netrc '127.0.0.1:5984/identities/_all_docs?include_docs=true' | grep testuser @@ -65,8 +80,7 @@ How to find out which userstore belongs to which identity ? * in this example testuser@example.org uses the database user-665e004870ee17aa4c94331ff3cd59eb -How much disk space is used by a userstore -========================================== +### How much disk space is used by a userstore Beware that this returns the uncompacted disk size (see http://wiki.apache.org/couchdb/Compaction) diff --git a/pages/docs/platform/services/en.md b/pages/docs/platform/services/en.md new file mode 100644 index 0000000..aa4ffc7 --- /dev/null +++ b/pages/docs/platform/services/en.md @@ -0,0 +1,83 @@ +@nav_title = "Services" +@title = "Guide to node services" +@summary = "" +@toc = true + +# Introduction + +Every node (server) must have one or more `services` defined that determines what role the node performs. For example: + + +``` + cat nodes/stallman.json + { + "ip_address": "199.99.99.1", + "services": ["webapp", "tor"] + } +``` + +Here are common questions to ask when adding a new node to your provider: + +* **many or few?** Some services benefit from having many nodes, while some services are best run on only one or two nodes. +* **required or optional?** Some services are required, while others can be left out. +* **who does the node communicate with?** Some services communicate very heavily with other particular services. Nodes running these services should be close together. +* **public or private network?** Some services communicate with the public internet, while others only need to communicate with other nodes in the infrastructure. + +# Available services + +<table class="table table-striped"> +<tr> + <th>Service</th> + <th>VPN</th> + <th>Email</th> + <th>Notes</th> +</tr> +<tr> + <td>webapp</td> + <td><i class="fa fa-circle"></i></td> + <td><i class="fa fa-circle"></i></td> + <td>User control panel, provider API, and support system.</td> +</tr> +<tr> + <td>couchdb</td> + <td><i class="fa fa-circle"></i></td> + <td><i class="fa fa-circle"></i></td> + <td>Data storage for everything. Private node.</td> +<td></td> +</tr> +<tr> + <td>soledad</td> + <td><i class="fa fa-circle-o"></i></td> + <td><i class="fa fa-circle"></i></td> + <td>User data synchronization daemon. Usually paired with <code>couchdb</code> nodes.</td> +<td></td> +</tr> +<tr> + <td>mx</td> + <td><i class="fa fa-circle-o"></i></td> + <td><i class="fa fa-circle"></i></td> + <td>Incoming and outgoing MX servers.</td> +</tr> +<tr> + <td>openvpn</td> + <td><i class="fa fa-circle"></i></td> + <td><i class="fa fa-circle-o"></i></td> + <td>OpenVPN gateways.</td> +</tr> +<tr> + <td>monitor</td> + <td><i class="fa fa-dot-circle-o"></i></td> + <td><i class="fa fa-dot-circle-o"></i></td> + <td>Nagios monitoring. This service must be on the webapp node.</td> +</tr> +<tr> + <td>tor</td> + <td><i class="fa fa-dot-circle-o"></i></td> + <td><i class="fa fa-dot-circle-o"></i></td> + <td>Tor exit node.</td> +</tr> +</table> + +Key: <i class="fa fa-circle"> Required</i>, <i class="fa fa-dot-circle-o"> Optional</i>, <i class="fa fa-circle-o"> Not Used</i> + +<%= child_summaries %>
\ No newline at end of file diff --git a/pages/docs/platform/services/monitor.md b/pages/docs/platform/services/monitor.md new file mode 100644 index 0000000..576b36a --- /dev/null +++ b/pages/docs/platform/services/monitor.md @@ -0,0 +1,36 @@ +@title = "monitor" +@summary = "Nagios monitoring and continuous testing." + +The `monitor` node provides a nagios control panel that will give you a view into the health and status of all the servers and all the services. It will also spam you with alerts if something goes down. + +Topology +-------------------------------------- + +Currently, you can have zero or one `monitor` nodes defined. It is required that the monitor be on the webapp node. It was not designed to be run as a separate node service. + +Configuration +----------------------------------------------- + +* `nagios.environments`: By default, the monitor node will monitor all servers in all environments. You can optionally restrict the environments to the ones you specify. + +For example: + + { + "nagios": { + "environments": ["unstable", "production"] + } + } + +Access nagios web +----------------------------------------------- + +*Determine the nagios URL* + + $ leap ls --print domain.name,webapp.domain,ip_address monitor + > chameleon chameleon.bitmask.net, demo.bitmask.net, 199.119.112.10 + +In this case, you would open `https://demo.bitmask.net/cgi-bin/nagios3` in your browser (or alternately you could use 199.119.112.10 or chameleon.bitmask.net). + +*Determine the nagios password* + +The username for nagios is always `nagiosadmin`. The password is randomly generated and stored in `secrets.json` under the key `nagios_admin_password`. Note that the login is `nagiosadmin` without underscore, but the entry in secrets.json is with underscores. diff --git a/pages/docs/platform/services/mx.md b/pages/docs/platform/services/mx.md new file mode 100644 index 0000000..79f1c4e --- /dev/null +++ b/pages/docs/platform/services/mx.md @@ -0,0 +1,12 @@ +@title = "mx" +@summary = "Incoming and outgoing MX servers." + +Topology +------------------- + +`mx` nodes communicate with the public internet, clients, and `couchdb` nodes. + +Configuration +-------------------- + +There are not values that should be configured for `mx` nodes.
\ No newline at end of file diff --git a/pages/docs/platform/services/openvpn.md b/pages/docs/platform/services/openvpn.md new file mode 100644 index 0000000..5f15ff0 --- /dev/null +++ b/pages/docs/platform/services/openvpn.md @@ -0,0 +1,49 @@ +@title = 'openvpn' +@summary = "OpenVPN egress gateways" + +Topology +------------------ + +Currently, `openvpn` service should not be combined with other services on the same node. + +Unlike most of the other node types, the `openvpn` nodes do not need access to the database and does not ever communicate with any other nodes (except for the `monitor` node, if used). So, `openvpn` nodes can be placed anywhere without regard to the other nodes. + +Configuration +--------------------- + +*Essential configuration* + +* `openvpn.gateway_address`: The address that OpenVPN daemon is bound to and that VPN clients connect to. +* `ip_address`: The main IP of the server, and the egress address for outgoing traffic. + +For example: + + { + "ip_address": "1.1.1.1", + "openvpn": { + "gateway_address": "2.2.2.2" + } + } + +In this example, VPN clients will connect to 2.2.2.2, but their traffic will appear to come from 1.1.1.1. + +Why are two IP addresses needed? Without this, traffic between two VPN users on the same gateway will not get encrypted. This is because the VPN on every client must be configured to allow cleartext traffic for the IP address that is the VPN gateway. + +*Optional configuration* + +Here is the default configuration: + + "openvpn": { + "configuration": { + "auth": "SHA1", + "cipher": "AES-128-CBC", + "fragment": 1400, + "keepalive": "10 30", + "tls-cipher": "DHE-RSA-AES128-SHA", + "tun-ipv6": true + }, + "ports": ["80", "443", "53", "1194"], + "protocols": ["tcp", "udp"] + } + +You may want to change the ports so that only 443 or 80 are used. It is probably best to not modify the `openvpn.configuration` options for now.
\ No newline at end of file diff --git a/pages/docs/platform/services/soledad.md b/pages/docs/platform/services/soledad.md new file mode 100644 index 0000000..e2700d0 --- /dev/null +++ b/pages/docs/platform/services/soledad.md @@ -0,0 +1,12 @@ +@title = 'soledad' +@summary = 'User data synchronization daemon' + +Topology +-------------------- + +Currently, the platform is designed for `soledad` and `couchdb` services to be combined (e.g. every `soledad` node should also be a `couchdb` node). `soledad` nodes might work in isolation, but this is not tested. + +Configuration +------------------------ + +There are no options to configure for `soledad` nodes. diff --git a/pages/docs/platform/services/tor.md b/pages/docs/platform/services/tor.md new file mode 100644 index 0000000..e64b0fe --- /dev/null +++ b/pages/docs/platform/services/tor.md @@ -0,0 +1,32 @@ +@title = 'tor' +@summary = 'Tor exit node or hidden service' + +Topology +------------------------ + +Nodes with `tor` service will run a Tor exit or hidden service, depending on what other service it is paired with: + +* `tor` + `openvpn`: when combined with `openvpn` nodes, `tor` will create a Tor exit node to provide extra cover traffic for the VPN. This can be especially useful if there are VPN gateways without much traffic. +* `tor` + `webapp`: when combined with a `webapp` node, the `tor` service will make the webapp and the API available via .onion hidden service. +* `tor` stand alone: a regular Tor exit node. + +If activated, you can list the hidden service .onion addresses this way: + + leap ls --print tor.hidden_service.address tor + +Then just add '.onion' to the end of the printed addresses. + +Configuration +------------------------------ + +* `tor.bandwidth_rate`: the max bandwidth allocated to Tor, in KB per second, when used as an exit node. + +For example: + + { + "tor": { + "bandwidth_rate": 6550 + } + } + + diff --git a/pages/docs/platform/services/webapp.md b/pages/docs/platform/services/webapp.md new file mode 100644 index 0000000..4e0d171 --- /dev/null +++ b/pages/docs/platform/services/webapp.md @@ -0,0 +1,115 @@ +@title = "webapp" +@summary = "leap_web user management application and provider API." + +Introduction +------------------------ + +The service `webapp` will install the web application [[leap_web => https://leap.se/git/leap_web.git]]. It has performs the following functions: + +* REST API for user registration and authentication via the Bitmask client. +* Admin interface to manage users. +* Client certificate distribution and renewal. +* User support help tickets. + +Coming soon: + +* Billing. +* Customizable and localized user documentation. + +The leap_web application is written in Ruby on Rails 3, using CouchDB as the backend data store. + +Topology +------------------------- + +Currently, the platform only supports a single `webapp` node, although we hope to change this in the future. + +`webapp` nodes communicate heavily with `couchdb` nodes. + +Configuration +-------------------------- + +Essential options: + +* `webapp.admin`: An array of username that will be blessed with administrative permissions. These admins can delete users, answer help tickets, and so on. + +For example, `services/webapp.json`: + + { + "webapp": { + "admins": ["joehill", "ali", "mack_the_turtle"] + } + } + +By putting this in `services/webapp.json`, all the `webapp` nodes will inherit the same admin list. + +Customization +--------------------------- + +The provider directory `files/webapp` can be used to customize the appearance of the webapp. All the files in this directory will get sync'ed to the `/srv/leap/webapp/config/customization` directory of the deployed webapp node. + +Files in the `files/webapp` can override view files, locales, and stylesheets in the leap_web app: + +For example: + + stylesheets/ -- override files in Rails.root/app/assets/stylesheets + tail.scss -- included before all others + head.scss -- included after all others + + public/ -- overrides files in Rails.root/public + favicon.ico -- custom favicon + img/ -- customary directory to put images in + + views/ -- overrides files Rails.root/app/views + home/ + index.html.haml -- this file is what shows up on + the home page + pages/ + privacy-policy.en.md -- this file will override + the default privacy policy + terms-of-service.en.md -- this file will override + the default TOS. + + locales/ -- overrides files in Rails.root/config/locales + en.yml -- overrides for English + de.yml -- overrides for German + and so on... + +To play with these customizations, it is easiest to first modify the contents of the directory `/srv/leap/webapp/config/customization` on the `webapp` node. When doing this, you may need to restart leap_web in order for changes to take effect (`touch /srv/leap/webapp/tmp/restart.txt`). + +Sometimes a `rake tmp:clear` and a rails restart is required to pick up a new stylesheet. + +Once you have what you want, then copy these files to the local provider directory `files/webapp` so that they will be installed each time you deploy. + +Custom Fork +---------------------------- + +Sometimes it is easier to maintain your own fork of the leap_web app. You can keep your customizations in that fork instead of in the provider `files/webapp` directory. Or, perhaps you want to add an engine to the application that modifies the app's behavior. + +To deploy your own leap_web, modify the provider file `common.json`: + + { + "sources": { + "webapp": { + "revision": "origin/develop", + "source": "https://github.com/leapcode/leap_web", + "type": "git" + } + } + } + +To target only particular environment, modify instead `common.ENV.json`, where ENV is the name of the environment. + +See https://github.com/leapcode/leap_web/blob/develop/doc/DEVELOP.md for notes on getting started hacking on leap_web. + +Known problems +--------------------------- + +* Client certificates are generated without a CSR. The problem is that this makes the web + application extremely vulnerable to denial of service attacks. This was not an issue until we + started to allow the possibility of anonymously fetching a client certificate without + authenticating first. + +* By its very nature, the user database is vulnerable to enumeration attacks. These are + very hard to prevent, because our protocol is designed to allow query of a user database via + proxy in order to provide network perspective. + diff --git a/pages/download/en.haml b/pages/download/en.haml new file mode 100644 index 0000000..2e5a024 --- /dev/null +++ b/pages/download/en.haml @@ -0,0 +1,19 @@ +- @title = "Download" + +.row + .col-xs-4.text-center + %i.fa.fa-4x.fa-download + %div + [[Bitmask client application => https://dl.bitmask.net]]<br> + for end-users. + .col-xs-4.text-center + %i.fa.fa-4x.fa-tasks + %div + [[LEAP server platform => platform]]<br> + for service providers. + .col-xs-4.text-center + %i.fa.fa-4x.fa-code-fork + %div + [[Source code => source]]<br> + for hackers. + diff --git a/pages/en.html.haml b/pages/en.html.haml index 931a87b..51a50e6 100644 --- a/pages/en.html.haml +++ b/pages/en.html.haml @@ -26,7 +26,7 @@ %i.fa.fa-user For Users %p We are working to create a suite of high security communication tools that are reliable and easy to use. - = link(:read_more => 'services', :class => 'btn btn-default btn-sm') + = link(:read_more => 'https://bitmask.net/features', :class => 'btn btn-default btn-sm') .col-sm-4 .well .heading diff --git a/pages/services/chat/en.text b/pages/services/chat/en.text deleted file mode 100644 index f6539f6..0000000 --- a/pages/services/chat/en.text +++ /dev/null @@ -1,27 +0,0 @@ -@title = "Chat" - -h1(first). Small messages, big hearts - -Short messages and chat have proven to be indispensable tools for mobilization for activists around the world, particularly on mobile devices. Unfortunately, very few options exist that are both secure and easy to use. Even solutions that people rely on for high security, such as OTR, are vulnerable to association mapping and do not work with asynchronous communication (where both parties do not need to be online at the same time). - -Experimental secure peer-to-peer messaging does exist, but adoption rates have been low because these protocols are incompatible with existing message networks and typically require both parties to be running the application at the same time. When asynchronous messaging is supported, it is slow and lacks the reliability users have come to rely on. - -h1. Secure and federated chat - -The LEAP approach to instant message and chat is to build on stable, federated chat technologies and add support for greatly enhanced security. The goal is to allow users to communicate with existing messaging networks, as well as enjoy a higher degree of protection when communicating with networks that support the enhanced protocols. - -h3. Open protocols, improved - -The primary open protocol for chat is called XMPP. It provides a good foundation for federated chat, but it is sorely lacking key security safeguards and standards for asynchronous messaging. Our additions to XMPP address these limitations: - -*Secure identity:* - -*Client-encrypted cloud data:* Chat applications work much better with a cloud component. For example, this allows you to have the same roster, chat history, and account information on all your clients. There is currently no provision in XMPP for client-encrypting this data. We will create one, and implement it on the client and server. - -*Asynchronous messages:* Currently, patchy adoption of different methods of handling offline messaging result in confusing situations where you often have no indication if a message will be delivered to its recipient or not. - -*Anonymous rosters:* XMPP requires that the server is aware of your list of contacts. This part cannot be client-encrypted, but it can be made highly resistant to association mapping by adding one-time aliases. If a friend on another server wants to add me to their roster, I will give them a unique alias for my actual chat address. Only my server will know that the alias belongs to me. - -*Secure groups:* - -*Required TLS:* As with email, there is no mechanism in XMPP for requiring TLS (the server can advertise that TLS is required, but this is easily thwarted by an attacker). We will add one. diff --git a/pages/services/eip/en.text b/pages/services/eip/en.text deleted file mode 100644 index 4b6e504..0000000 --- a/pages/services/eip/en.text +++ /dev/null @@ -1,60 +0,0 @@ -@title = 'Encrypted Internet' - -h1(first). Encrypted Internet Proxy (EIP) - -Around the world VPN and Tor technologies are essentially for protecting network traffic, bypass network monitoring, and circumventing censorship. Unfortunately, both VPN and Tor can be very difficult to set up and to configure correctly in a manner that actually provides high security. - -The LEAP platform includes an Encrypted Internet Proxy (EIP) service that is hassle-free, automatically self-configuring, and provides an enhanced level of security. Initially, this EIP service will be built using OpenVPN, but we may include the option of using Tor as an alternate transport in the future. - -h1. Features - -LEAP's EIP client will: - -* Automatically self-configure. -* Prevent unencrypted network traffic while the EIP is down (by default). -* Automatically starts on startup (by default). -* Prevent security leaks caused by problems with DNS, IPv6, and other common misconfigurations. - -h1. Benefits - -Traditional VPN or Tor provide a user with considerable benefit. These technologies allow a user to bypass network-based censorship and surveillance by the local ISP. They also aid in safe browsing by preventing web sites from capturing a user’s IP address, and thus geographic location. In the case of VPN, using a VPN can also give you a secure connection to a DNS server. - -LEAP's Encrypted Internet Proxy provides additional benefits when paired with other communication services. - -Current vulnerabilities in TLS and the x.509 certificate authority system make it nearly impossible to establish a secure internet connection with a website or a service provider. New initiatives, like Convergence and Sovereign Keys, hold long-term potential for solving this problem, but are either not available today or work only in limited circumstances. - -By connecting to the internet through an EIP that is part of the LEAP platform, a user will be able to effectively establish out-of-band validation of their network encryption with the service provider. - -h1. Future plans - -h2. Tor - -In the long run, we hope to offer both OpenVPN and Tor as possible transports for the EIP service. - -Tor is an incredibly important project, but it makes different trade-offs than traditional VPN service does. For example, Tor affords the user greater anonymity, but at the cost of slower speed. The user should be able to make this choice. Currently, Tor does not include support UDP traffic, but when it does, we hope to allow the user to substitute Tor for OpenVPN via the LEAP client. - -In the short run, our goal is to make all the LEAP services also work under well under Tor (as Tor hidden services), should a user decide to use Tor instead of LEAP's EIP. - -h2. Darknet - -We plan to eventually create a system to allow service providers who are deploying the LEAP platform to easily establish IPSec encryption of all network traffic with other service providers. - -This will provide nearly complete end-to-end encryption of all the network traffic sent from one user to any other user. Each service provider, however, will still have cleartext access to the traffic of their users. The LEAP "darknet" protects against outside threats, not a compromised service provider. - -h2. Anonymous Client Certificates - -The LEAP platform is designed to de-couple a user's identity from the client certificate they use to connect to the EIP. The service provider will not know what user corresponds to which EIP network connection. - -However, a compromised or nefarious provider could modify the LEAP platform to record a correspondence between username and EIP certificate. In the future, we would like to make this impossible. - -Unfortunately, this is not an easy problem. The problem essentially boils down to this: - -* Time 1: User authenticates with the provider to prove they are a valid user and receives a token. -* Time 2: User redeems this token to get services in a way that does not reveal their identity. - -This is theoretically possible using various [[zero-knowledge proofs => https://en.wikipedia.org/wiki/Zero_knowledge_proof]]. In the long run, we hope to support this capability. - - -h2. Friend in the middle - -We plan to explore the feasibility of adding a "friend in the middle" to the EIP service. The idea is that the service provider can filter traffic in a way that benefits the privacy and security of the user. For example, the EIP gateway could filter advertising or third party behavioral tracking companies. diff --git a/pages/services/email/en.md b/pages/services/email/en.md deleted file mode 100644 index 7ba3fc1..0000000 --- a/pages/services/email/en.md +++ /dev/null @@ -1,99 +0,0 @@ -@title = "Email and its discontents" -@nav_title = "Email" - -<img src="/img/animated-gifs-email-007.gif" align="right" /> - -Email continues to be a vital communication tool. Unfortunately, the email protocol was designed in the Paleocene era of the internet and is unable to cope with the security threats common today. - -For example, there is no standard for ensuring secure relay between mail providers (StartTLS is easily thwarted) and message encryption technology (OpenPGP and S/MIME) has proven to be too cumbersome to reach beyond a very small audience. Even these existing methods, however, offer no protection against meta-data analysis since the email headers remain unencrypted. Finally, email providers have an unfortunate habit of handing over users' data to non-democratic regimes. - -## Email for the modern era - -The LEAP approach to email is to support communication with the legacy email infrastructure while also adding optional layers to the protocol that bring email more in line with modern security practices. This strategy allows for a gradual transition from existing email to secure email. In the short term, there are immediate benefits to a user's security when they adopt LEAP email. In the long term, as more service providers adopt the LEAP platform, email among these service providers gains even more protection. - -Above all else, our focus is on creating a user experience that is as easy and trouble-free as possible while still ensuring a very high level of security. - -## How it works - -When a service provider runs the LEAP platform, their users can access secure email in three steps: - -1. Download and install the Bitmask application. -2. Run the Bitmask application to log in or sign up with the service provider. -3. Configure the user's mail client to connect to the local Bitmask application. In case of the Thunderbird email client, this configuration is semi-automatic. - -The Bitmask application acts as a "proxy" between the service provider and the mail client. It handles all the encryption and data synchronization. - -## Immediate benefits of using LEAP email - -Email features include: - -* LEAP encrypted email is easy to use while still being backward compatible with the existing OpenPGP protocol for secure email. -* All incoming email is automatically encrypted before being stored, so only you can read it (including meta-data). -* Whenever possible, outgoing email is automatically encrypted so that only the recipients can read it (if a valid OpenPGP public keys can be discovered for the recipients). This encryption takes place on the user's device. -* OpenPGP public keys are [automatically discovered and validated](/nicknym), allowing you to have confidence your communication is confidential and with the correct person (without the headache of typical key signing). -* The user does not need to worry about key management. Their keys are always kept up-to-date on every device. -* The user is able to use any email client of their choice (e.g. Thunderbird, Apple Mail, Outlook). -* When disconnected from the internet, the user can still interact with a local copy of all their mail. When the internet connect is available again, all their changes will get synchronized with the server storage and to their other devices. - -General security features of the Bitmask application include: - -* All stored data is encrypted, including local data and cloud backups. This encryption always [takes place on the user's device](/soledad), so the service provider cannot read your stored data. -* Although you specify a username and password to login, your [password is never communicated to the provider](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol). -* If you download the Bitmask application from [downloads.leap.se](https://downloads.leap.se), your service provider cannot add a backdoor to compromise your security. -* The Bitmask application is always kept up to date with the latest security patches (coming soon). - -## Long term benefits when two LEAP compatible providers talk to one another - -One of the fundamental problems with email is that the meta-data routing information is exposed as cleartext. Encrypting a message with OpenPGP or S/MIME does nothing to help with this. - -The email protocol does support an optional method of securely relaying messages using TLS to encrypt the connection. This method, called StartTLS, is easily undermined by attackers and there is no good way for email providers to validate the authenticity of other servers (without relying on the problematic CA certificate authority system). - -For now, LEAP addresses these problems with two enhancements when two compatible providers are talking to one another: - -* When relaying email, server keys are discovered and validated using DNSSEC/DANE. -* For these providers, TLS with validated keys becomes required for all communication. - -This approach is effective against external network observers, but does not protect the meta-data from the service providers themselves. Also, it does not, by itself, protect against more advanced attacks involving timing and traffic analysis. - -In the long term, we plan to adopt one of several different schemes for [securely routing meta-data](routing). - -## Limitations - -* Missing features: the initial release will not support email aliases, email forwarding, or multiple accounts simultaneously. -* You cannot use LEAP email from a web browser. It requires the Bitmask application to run. -* The Bitmask application currently requires a compatible provider. We have plans in the future to semi-support commercial providers like gmail. This would provide the user with much less protection than when they use a LEAP provider, but will still greatly enhance their email security. -* Because all data is synced, if a user has one of their devices compromised, then the attacker has access to all their data. This is obvious, but worth mentioning. -* The user must keep a complete copy of their entire email storage on every device they use. In the future, we plan to support partial syncing for mobile devices. -* We do not plan to support key revocation. Instead, we plan to migrate to shorter and shorter lived keys, as practical. -* With the current implementation, a compromised or nefarious service provider can still gather incoming messages that are not encrypted and meta-data routing information. As more users and providers adopt secure email, many of these problems will go away. - -For more details, please see [known limitations](limitations). - -## Related projects - -There are numerous other projects working on the next generation of secure email. In our view, it is not possible to do secure email alone, it requires new protocols for handing key validation, secure transport, and meta-data protection. We will continue our efforts to reach out to these groups to explore areas of cooperation. - -Free software projects - -* [mailpile.is](http://mailpile.is/) - Python email client with a web interface, optimized searching, and support for OpenPGP. -* [mailiverse.com](https://mailiverse.com) - HTML5 app. Sparse on details. - -Mixed proprietary and free software projects - -* [mega.co.nz](https://mega.co.nz/) - Mega has announced plans for web-based encrypted email, but no details yet. In-browser javascript client will reportedly be open source, backend not. - -Proprietary projects - -* [parley.co](http://parley.co) - Proprietary OpenPGP client and service. Few details so far. -* [startmail.com](https://startmail.com/) - No details yet. -* [Places](https://ansamb.com/) - Announced secure email, no details yet. - -Initiatives - -* Ubiquitous Encrypted Email - A private, invite-only mailing list to discuss new ways to make encrypted email commonplace. - -Email-like, but incompatible with existing email - -* [pond](https://pond.imperialviolet.org/) - Forward secure, asynchronous, peer-to-peer email-like messenger. Addresses are the key fingerprint. Free software, written in Go. -* [bitmessage](https://bitmessage.org) - Peer-to-peer messaging application. Addresses are the key fingerpint. Free software. -* [scrable.io](https://scramble.io/doc/) - Free software, web email, but using the key fingerprint as the email address.
\ No newline at end of file diff --git a/pages/services/en.text b/pages/services/en.text deleted file mode 100644 index 29444ff..0000000 --- a/pages/services/en.text +++ /dev/null @@ -1,22 +0,0 @@ -@nav_title = 'Services' -@title = 'Supported Services' - -LEAP's multi-year plan to secure everyday communication breaks down into discrete services, to be rolled out one at a time. When we introduce a new service, integrated support will be added to both the user-facing [[client]] and the server-side [[platform]]. All communication content will be client-side encrypted, and as much of the metadata as possible. Most importantly, all LEAP services will be based on our plan for [[federated secure identity => nicknym]] and [[unmappable routing => routing]]. - -h2. Roadmap - -h3. Phase 1 - Encrypted Internet Proxy - -Our first service will be [[eip]], providing circumvention, location anonymization, and traffic encryption that is hassle-free, automatically self-configuring, and has an enhanced level of security. - -h3. Phase 2 - Email - -Our second service will be [[client-encrypted email => email]]. The LEAP approach to email is to support communication with the legacy email infrastructure while also adding optional layers to the protocol that bring email more in line with modern security practices. Encryption and decryption will take place transparently via local IMAP and SMTP proxies, allowing the user their choice of mail client. - -h3. Phase 3 - Chat - -Our third service will be [[secure chat => chat]]. We plan to build on top of XMPP, but modify the protocol to allow for higher security and greater usability (while being able to fall back to traditional XMPP when necessary). - -h3. Phases 4, 5, 6 - -In the long term, we plan to develop and deploy client-encrypted file sync/backup, voice communication, and document collaboration. diff --git a/pages/services/technology/client-app/en.haml b/pages/services/technology/client-app/en.haml deleted file mode 100644 index 07dfab8..0000000 --- a/pages/services/technology/client-app/en.haml +++ /dev/null @@ -1,109 +0,0 @@ -- @title = "Client Application" - -%h2 Client-server integration - -%p The LEAP Client will run on the user's device and grant the user access to the #{link 'cloud-based services' => 'services'} of the #{link 'LEAP Platform' => 'platform'}. As new services are added to the LEAP Platform, the LEAP Client will be developed in tandem to work with these services. - -%h2 Client crypto, cloud assistance - -%p For users of cloud-based communication services, there is only one approach that can achieve a reasonable level of security: client-side encryption. - -%p The model proposed here is neither peer-to-peer nor pure cloud; rather, it is a hybrid designed to make a client-encrypted cloud function more smoothly. Some client-encrypted communication services do not require cooperation on the part of the cloud provider, like file backup, for example. - -%p Most other services, however, will only work if the server-side software is designed to work with client-encrypted data. A hybrid model shares the advantages that a pure cloud model has over peer-to-peer: the service is more reliable, is not subject to data loss, works the same on all devices, is faster, and is much easier to use. - --# insert a chart here... - - plain-cloud - cloud with no encryption or server-side encryption only - pretty much all cloud services fall into this category. - Twitter - Dropbox - - crypto-cloud - cloud with layered client-side encryption - some enterprising users have bolted encryption on top of the cloud based services they use. the cloud services are not designed to work with client-side encryption, the the operation is typically awkward, but it can work. - Facebook Chat + OTR - Amazon S3 + Duplicity - gmail + FireGPG - - integrated cloud - cloud with integrated client-encryption - - cloud-side encryption is not really any better than cloud without encryption, so it is not listed in this table. - - Except in the case of EIP, all LEAP services are designed to place little or no trust in the service provider. - -%h2 Crypto for mere mortals - -%p After security, our primary goal with the client is to make it as easy to use as possible. There are several ways we are approaching the problem of usability: - -%p - %b Auto-configuration — - There are a lot of powerful tools for secure communication out there, and most of them are incredibly difficult to set up and configure correctly in a way that ensures you don't compromise your security. Our goal with the LEAP client is to tightly couple the client with the services so that the client will be able to configure itself correctly without user intervention. - -%p - %b The best UI is no UI — - We plan to make the interface for the client as minimal as possible. For EIP, the client will do everything it can to troubleshoot on its own to get a stable encrypted tunnel established. For the messaging services like email and chat, the LEAP Client is a proxy that handles encryption/decryption locally on the user's device, allowing the user to continue to use whatever client software they are comfortable with. - -%h2 Software updates - -%p We want service providers in repressive and hostile contexts to still be able to adopt the LEAP Platform. In order to protect the service provider, the LEAP Client will accept security patches and code upgrades from the LEAP non-profit organization, not from the service provider. - -%p Every LEAP Client will include the public key used to sign updates. When a new client version is available, and the provider supports the API version of the new client, then the new code will be download from LEAP and verified using the keys included with the first download. Alternately, on platforms with good package management, like Debian or Redhat variants of GNU/Linux, updates to the LEAP Client will go through the normal platform specific channels. - -%p This system still leaves open the problem of how to distribute the initial client that is first installed. This is a difficult problem, and one which we hope to work on in the future. - -%h2 Cross platform - -%p Initially, the LEAP Client will support Windows, Mac, and Linux. We are committed to extending support to mobile devices once the desktop version is stable (although currently, Apple's terms of service for the appstore prevent GPL licensed apps, so until this changes we can't distribute on iOS). The mobile version of the LEAP Client will lag behind the desktop version, but our goal is to provide eventual feature parity. - -%p Recent advancements in Javascript and HTML have begun to blur the distinction between client applications that a user installs and client applications that run in a web browser environment. Although there are numerous projects actively working on client-encrypted communication that runs inside the browser, such in-browser efforts are currently crippled by a lack of standardized and trusted cryptographic primitives inside the browser and are so vulnerable to a number of common attacks. We plan to work closely with the new W3C Web Cryptography Working Group in order maximize the deployment of client-encrypted applications, both in currently safe clients as well as more experimental native applications in the browser. - --# %h2 Branded and unbranded - - %p The LEAP client will come in two flavors: branded and unbranded. - - %p - %b The branded client - will be customized with the name and graphics of the service provider using the LEAP Platform. It will be pre-configured to work the with service provider. - - %p - %b The unbranded client - will work with any service provider that runs the LEAP platform. When the user first runs the unbranded client, they will be presented with a list of available service providers and the option to type in the name of a provider that is not in the list. Once the user picks a provider, the client will download a file from the provider that defines the capabilities of the provider and allows the client to autoconfigure itself for use with that provider. - - -%h2 Trust issues - -%p As much as possible, our goal is to design a system that requires very little trust of the service provider. However, there are a few areas where the user will need to trust either LEAP or their service provider: - -%ul - %li - %b Encrypted Internet Proxy: - If the user chooses to enable the EIP service, then all their internet traffic will pass through the service provider. A nefarious or compromised provider could monitor this traffic. - -# %li - %b Notary Keys: - The LEAP Client will come with a set of public keys for the notaries used for #{link 'identity discovery and validation' => 'nicknym'}. If a supermajority of these notaries conspire or get hacked then the security of the identity system will be compromised. - %li - %b Client Software: - Unless the user builds the client software from the source code, the user will trust LEAP Encryption Access Project for the application builds and code updates. - --# %h2 Secrets recovery - - %p What should LEAP do when a user has lost their secrets (either human-memorizable or private keys)? There is no right answer for every situation. - - %p - %b No recovery: - In some situations, it makes the most sense to simply do without the ability to recover lost secrets. - - %p - %b Recovery document: - The LEAP client will give the user the option to export a text file with a complete copy of their private keys and authorization information, either password protected or not. This "recovery document" can be printed or saved electronically as the user sees fit. If the user needs to recover their data, they can load this recover document into any LEAP client. The user can also type the recovery document in manually, although it will be long and very painful to copy manually. - - %p - %b Cloud recovery: - The user is presented with a small ten by ten grid of digits (with QR code) that can be printed. To recover, the user types in these 100 digits into any LEAP client (or scans the QR code using a mobile device). This method is like manual recovery, but it is much easier to type in manually. To achieve this, the full recovery document is encrypted and then stored on the server. The user is then presented with a small code that serves as an encoded index and passphrase to retrieve the full recovery document. This method is desirable when the user does not want to be responsible for storing an electronic copy of the full recovery document. It will also serve as an easy way to set up the LEAP client on a mobile device. The disadvantage of this method is that there is potential for attack on the cloud-stored recovery document. - - %p - %b Email recovery: - The novice user should have the option to recover their secret by a simple email verification. This is less horrible than it sounds. It will work like this: when the user first installs the client, they are given the option to entrust one or more email addresses with the ability to unlock their recovery document. Additionally, they must decide how many of these email addresses must confirm the secret recovery in order for it to succeed. The LEAP client then registers these emails with a third party secret escrow service in such a way that no single party has access to the full secret (unless there is just one email). When the user triggers the reset process, the LEAP client contacts the escrow service and gives it a token to request the release of the recovery document. Once the email accounts have replied to the escrow service with confirmation of assent to the secret recovery, the LEAP client can retrieve the lost secret from the escrow service. This is a complicated process, but from the user's perspective they just hit a "recover" button and then wait for people to reply to the confirmation emails. This is a potential long term enhancement. diff --git a/pages/services/technology/critiques/en.text b/pages/services/technology/critiques/en.text deleted file mode 100644 index acde975..0000000 --- a/pages/services/technology/critiques/en.text +++ /dev/null @@ -1,56 +0,0 @@ -@title = 'Critiques' - -h2. Isn't LEAP too ambitious? - -Yes. However, someone needs to be working on a long term plan to add real security and usability to federated messaging architectures. It will not be easy, but we think it is possible. - -h2. Isn't LEAP just like FreedomBox? - -LEAP and FreedomBox share a similar goal of ensuring that everyone has the right to communicate securely and without censorship. However, the projects use different strategies for achieving this goal. - -* *FreedomBox:* Empower every user to control the hardware on which all their data is stored. Users become their own service providers, running their own hardware. -* *LEAP:* Allow service providers to deploy a cloud-based infrastructure that can scale and is easily maintained. In addition to the performance and usability found in traditional cloud services, LEAP services are also designed to bring a very high level of security to everyday users. - -FreedomBox is an important project. It faces, however, some significant hurdles. Most users demand high availability, but current technology does not allow for hardware or software that is self healing. If it did, sysadmins would be out of work. Things go wrong all the time. Take, for example, email: it is very common for an email server to get spam-bombed, or added to a blacklist, or any number of other problems that require manual intervention by a system administrator to fix. Also, most ISPs block the port needed for email rely. - -In the long run, FreedomBox has a lot of potential. But for the foreseeable future, we think it is important to also pursue the LEAP strategy. - -h2. We should not encourage users to store any data in the cloud, encrypted or not - -Even the best encryption is no guarantee of confidentiality; data in the cloud always has the potential to be decrypted by a determined attacker. - -The entire issue boils down to a matter of degree. Although there is no necessary trade off between security and convenience, you can usually achieve a higher level of security in any system by sacrificing some convenience. But what level of protection and convenience is appropriate for a particular user? - -There are very few people for whom client-encrypted data stored in the cloud will be the weakest link in the confidentiality of their communication and stored data. Most likely, there will be many aspects of their communication that are much more attractive targets to a determined adversary. - -If a person has a threat model that includes an adversary with the resources to both acquire the user's cloud data and to decrypt it, then there is little that LEAP or any other third party can do for them. They will need to become highly proficient at managing and protecting all their own data. - -There are many tools and projects out there to help a user do this. LEAP is designed for a different audience, one not adequately addressed by existing technology: people who want high security but don't have the capacity to become highly skilled in self-managing their encryption. There is room--and need--for both approaches, and it is likely that the amount of people who want high security but do not have the time or skills to adequately self-manage their own environment is already large and increasingly rapidly. - -h2. If you make your system architecture public, then you have given adversaries a blueprint to attack you - -This is, of course, similar to the arguments about the security of FLOSS. Openness can indeed lead to attacks, but more eyes leads to better security. - -In the case of an entire service provider infrastructure, however, it could be argued that things are different. We are not talking about a single piece of software, but the whole integration across many servers and services. A related critique is the potential problem of monoculture: if LEAP is successful, then a high percentage of the secure service providers will be using systems with the same vulnerabilities. - -Monoculture and openness are both interesting issues that could pose problems for the future. We can only be diligent in assessing LEAP once it is deployed by a variety of organizations. With enough flexibility in configuration, it may be that each LEAP deployment is sufficiently distinct from the others to mitigate these concerns. - -h2. Users will not be willing to download a custom client - -This will indeed be the case for a large number of potential users. Because meaningful levels of security cannot be achieved using current technology without a custom client, our hope is that a critical mass of users can be induced to use one. There are two parts to this inducement: increasing awareness as to why an extra step to ensure security is worthwhile, and decreasing the difficulty in actually taking this step. With sufficient education and an improved user experience, many users should be willing to install a custom client. - -On the other hand, rapid developments in Javascript and web browser technology have raised the possibility of running advanced client applications within the browser itself. In this case, a user would not have to install any additional software. However, in-browser crypto is still an area of active research but is currently not safe for deployment, with some areas still to be worked out (like sufficient entropy). LEAP does not depend upon the presence of cryptography in the browser, but would benefit from this should it become viable. The lead W3C employee who began the standardization of Javascript Cryptography is on the board of LEAP, and he will liaise tightly with LEAP as the work matures. - -h2. Users who need security often don't have their own device or access to the internet - -This is absolutely true. The digital divide is alive and well, and LEAP does nothing to bridge the gap between the technological haves and have-nots. However, in the long run, IP-based communication--dependent upon advanced devices such as smart phones--is likely to replace most other forms of communication. The cost of such IP-based communication devices and their connectivity is declining rapidly. It behooves us to lay the groundwork now for a secure IP-based communication infrastructure, both for the people who currently rely on the internet and for the next billion who will gain access to the internet in the near future. - -h2. Client encryption is excessive for most people - -The argument against client encryption is something like this: a secure connection is good enough, so long as the service provider is located in a country with adequate legal protection and without repressive laws. - -There are many reasons why users should be put in control of their data and should not be made to rely on a third party to safeguard it. Third parties have proven to be highly undeserving of trust--They might close shop, bow to pressure from local government, become compromised by external attacks, or accidentally leak sensitive data due to carelessness. - -Our goal is to make secure communication the default for a critical mass of users worldwide. A vital part of this strategy is cooperation with ISPs and service providers who speak the local language of their users and who are attuned to the needs of a particular context. These local service providers don't have the luxury of determining which government's jurisdiction they fall under. However, so long as encryption technology itself is not outlawed, local providers using the LEAP platform will be able to provide a high level of security for their users. - -By requiring client encryption for all services, LEAP also helps to mitigate against the myriad vulnerabilities inherent with most devices. While the LEAP client cannot defend against keyloggers, malware, or penetration of the host OS, it can ensure that all the LEAP cloud data synced by the device is stored in an encrypted format.
\ No newline at end of file diff --git a/pages/services/technology/en.haml b/pages/services/technology/en.haml deleted file mode 100644 index 2ca579e..0000000 --- a/pages/services/technology/en.haml +++ /dev/null @@ -1,30 +0,0 @@ -%h1.first The Technology of LEAP - -%p The long term LEAP plan consists of a set of #{link 'communication services' => 'services'} built upon the core technologies detailed here. - -%p - %b #{link 'Information Security' => 'infosec'}: - An analysis of different approaches to information security and how the LEAP strategy compares. - -%p - %b #{link 'Provider Platform' => 'platform'}: - Turn-key automation for communication service providers. - -%p - %b #{link 'LEAP Client' => 'client'}: - Easy to use client for secure communication. - -%p - %b #{link 'Nicknym' => 'nicknym'}: - A system for automatic discovery and validation of cryptographic identity. - -%p - %b #{link 'Map Resistant Routing' => 'routing'}: - A system for message routing that is resistant to association mapping. - -%p - %b #{link 'Critiques' => 'critiques'}: - Anticipated critiques of the LEAP architecture. - - --# https://guardianproject.info/wiki/Always_Secure_Messaging
\ No newline at end of file diff --git a/pages/services/technology/platform/en.haml b/pages/services/technology/platform/en.haml deleted file mode 100644 index 44bbce9..0000000 --- a/pages/services/technology/platform/en.haml +++ /dev/null @@ -1,16 +0,0 @@ -%h1.first git clone leap-platform - -%p The LEAP Provider Platform is the server-side part of LEAP that is run by service providers. It consists of a set of complementary packages and recipes to automate the maintenance of LEAP services in a hardened GNU/Linux environment. Our goal is to make it painless for service providers and ISPs to deploy a secure communications platform. - -%p The LEAP Platform is essentially a git repository of puppet recipes, with a few scripts to help with bootstrapping and deployment. A service provider who wants to deploy LEAP services will clone or fork this repository, edit the main configuration file to specify which services should run on which hosts, and run scripts to deploy this configuration. - -%h1 More providers, please - -%p We believe that the best way to defend the right to whisper is to bring encryption technology into wider adoption. Despite growing awareness of the importance of communication security, users who attempt to adopt better practices still have few places they can turn. - -%p Most people think of lack of security as a problem of insufficient demand. We think that there are actually enough people out there who would like to use communication tools with higher security but who face severe problems of supply. - -%p The goal of LEAP is to meet this demand with tools that are usable and secure. But the LEAP architecture is necessarily a #{link 'federated' => 'infosec'} one, and the enhanced security it provides is only possible once there is a health ecosystem of service providers using the LEAP platform. - -%p One way to get more service providers is to make the people who run them happy. With the LEAP Platform, we want to reduce the amount of bullshit work. We are not "dumbing down" the work it takes to run a service provider. Rather, our goal is to allow talented sysadmins to focus on the parts that really matter and spend less time wrestling with the frustrating and mundane aspects of system administration. - |