leastauthority / s4-2.0 Goto Github PK

View Code? Open in Web Editor NEW

7.0 11.0 1.0 198 KB

Simple Secure Storage Service 2.0

License: Apache License 2.0

Nix 46.46% HCL 1.31% Python 7.56% HTML 0.10% Haskell 44.57%

s4-2.0's Introduction

S4 2.0

This is the DevOps stuff to deploy and operate S4 2.0.

Quick Start

VirtualBox Deployment

Creating a deployment running entirely within local VirtualBox VMs is an easy way to tinker with S4 2.0. At least, it is in principle. In practice, the interaction between NixOps and VirtualBox seems fragile. There is a good chance this won't actually work for you. Bearing that in mind ...

With a working directory of the root of a checkout of S4-2.0:

nixops create --deployment your-s4-petname ops/s4.nix ops/s4-vbox.nix
nixops set-args --arg bridgeAdapter '"<host network interface>"'
nixops deploy --force-reboot --deployment your-s4-petname

For <host network interface>, select a network interface on the host which can route traffic out of your network and which has a DHCP server. This might be something like wlp4s0 or enp0s31f6. Make sure to include all of the quotes as indicated above.

AWS Deployment

Set AWS_PROFILE in your environment. If the AWS account selected has never previously been initialized for S4 2.0 then, with the root of your S4-2.0 checkout as your working directory:

terraform init ops
terraform apply ops

Then, with the same working directory:

nixops create --deployment your-s4-petname ops/s4.nix ops/s4-ec2.nix
nixops deploy --deployment your-s4-petname

Tools

Terraform

Terraform is used to manage certain resources. The Terraform configuration lives in .tf files. It is typically applied using terraform apply.

Nix Tools

Nix is a collection of tools for managing a purely functional Linux distribution.

As much of the deployment as possible is managed using the Nix tools. The configuration lives in .nix files in this repository. It is typically applied using nixops deploy --deployment s4.

NixOS

NixOS is a purely functional Linux distribution. Compared to other Linux distributions, NixOS has the advantages of declarative system configuration, atomic upgrades and rollbacks, and a tailor-made operational management tool (NixOps).

Nix

Nix is a purely functional package manager. It is used to configure a NixOS installation. It is also a purely functional programming language in which this configuration is written.

NixOps

NixOps is a tool for deploying sets of NixOS Linux machines. It uses and extends the purely functional Nix package manager to allow node provisioning and network configuration.

Nixpkgs

Nixpkgs is a collection of packages available for NixOS. Many of these are used in the deployment. NixOS is not limited to the packages in this collection. Where we have needs that go beyond Nixpkgs we can use Nix to create our own packages.

Components

"S4"

This needs a better name. A single long-running process controls and coordinates the other components involved in delivering the service. This process responds to HTTP requests for new subscriptions. It will eventually communicate subscription details using Magic Wormhole, manage persistent state relating to subscriptions, integrate Zcash transactions with subscription state, and create and destroy Tor Onion Services.

Zcash

Multiple non-mining Zcash Sapling full nodes are included as part of this deployment. This allows for processing of Zcash shielded transactions. The Zcash deployment is configured in ops/s4.nix via zcashdService.

A lockbox node is provisioned for maximum resistance to key compromise and holds spending keys. An infra node is provisioned for off-premise deployment and holds only viewing keys.

Wallet

z-addr keys are required to process incoming transactions representing subscription payments. The infra wallet contains only the viewing keys necessary for this processing. This limits the damage that can be done should the wallet be compromised (transactions can be read but funds cannot be spent).

The master spending key(s) are maintained on the lockbox node. Each subscription is assigned a unique `Sprout z-addr<https://github.com/LeastAuthority/S4-2.0/issues/38>`_. As new subscriptions are created and addresses available on the node are allocated, the "pool" of addresses is diminished. Before the pool empties, new viewing keys are generated in the lockbox wallet and imported into the infra wallet.

bin/load-some-more-keys automates this process of key creation and movement.

Tor

A Tor daemon is included as part of this deployment. This allows the service website and Tahoe-LAFS daemons to operate as Onion services. This, in turn, provides location privacy for users browsing the website and operating Tahoe-LAFS clients. The Tor node is primary configured using zcashnode in s4.nix (but maybe this should change).

Tor Service Keys

To publish the website at a stable Onion service address, the deployment requires use of persistent private keys. No such keys have yet been provisioned. Meanwhile, you can generate some throw-away keys:

pip install stem
mkdir -p ops/secrets/onion-services/v3
./bin/generate-onion-keys ops/secrets/onion-services/v3/signup-website
./bin/generate-onion-keys ops/secrets/onion-services/v3/main-website

You must have keys before you can use nixops to deploy the service.

s4-2.0's People

Contributors

Stargazers

Watchers

Forkers

meejah

s4-2.0's Issues

Create a Tor version of the whole leastauthority.com website

This will let privacy-conscious users find out about P4 without revealing metadata while they do so.

Re-enable non-anonymous mode using txtorcon 18.3

txtorcon 18.3 makes non-anonymous ephemeral services available via endpoint description strings. Use this to re-enable this tor feature.

Assign a Sapling diversified payment address to each subscription

Processing time for N Sapling diversified addresses is supposedly roughly constant on N. This makes it appealing to use this kind of address for each subscription to avoid having the transaction processing cost grow with the number of active subscriptions.

As of the time of this issue, no API is available for working with Sapling diversified addresses so we are going to use "regular" Sapling addresses instead.

When such an API becomes available, we should switch to Sapling diversified addresses.

Add onion services when new subscriptions are created

When a new subscription is created, create its Onion Service(s).

See #52

Generate an Onion Service key (or keys) for new subscriptions

Each subscription needs its own private address(es) for the Tahoe-LAFS storage servers of the service. Generate the keys necessary for such address(es).

If a single onion service can forward multiple ports, it may be feasible to use a single service with different ports forwarding to different storage servers. If not, multiple services (thus multiple keys) may be required.

Generate them as part of subscription creation and persist them (see #51). Acting on them will be a separate task.

Add documentation about how to deploy S4 2.0

There are some Terraform and nixops commands. These tools are hinted at but we could provide a quickstart section in the README.

Support VirtualBox as a deployment target

This might be useful for development purposes. Supposedly, NixOps makes this easy with its built-in VirtualBox features.

Create a form for provisioning a new subscription and receiving an invite code for it

The website reachable via #8 and containing instructions from #9 will have a button that asks the backend to provision a subscription. Create the web side of this interaction so a button can be clicked and an invite code in a response is given to the person requesting the subscription.

Avoid recycling the Tor Hidden Services when Tor keys have not changed

nixops deploy ... re-uploads keys and restarts key services. Our Tor Hidden Service helper services restart when the key services restart. This destroys the existing hidden service descriptor and creates and uploads a new one. This introduces a long service interruption to the hidden services.

Remove this service interruption.

Add the subscription management server to the Nix-based deployment

A new server was introduced for #11. It's in the repo but it doesn't get deployed. Update the nix deployment definition to run the server as an Onion Hidden Service.

Try out https://github.com/meejah/txtorcon/pull/316

This PR adds better ephemeral service support to txtorcon and will obsolete our txxonion code. Try it out to see if it works. If it does, we can switch to it once it is in a txtorcon release.

Create signup instructions in the form of a web site

Describe how to sign up for S4 2.0 in the form of a web site.

The site will be served via #8

Read and understand https://blog.wearewizards.io/how-to-use-nixops-in-a-team

The plan is currently to use NixOps for S4 2.0. https://blog.wearewizards.io/how-to-use-nixops-in-a-team seems to have some ideas and opinions about practices for doing this in a team-friendly way. Read and understand it.

Allow S4 subscription configuration to cause Tahoe-LAFS clients to connect using Tor

It is necessary for clients to access their Tahoe-LAFS services using Tor in order to preserve their privacy. If they fail to do so, network addressing information about them is revealed.

One approach here is to update our S4 configuration blob, currently (but not necessarily) transferred via magic-wormhole to be able to specify the client should turn on the --hide-ip option.

Another approach is to configure the S4 subscription's introducer and storage servers to only listen on onion addresses and only include such an address in the connection hints of their fURLs.

Maybe both of these would be good.

Monitor the Zcash blockchain for transactions to a set of shielded payment address

The first step in integrating payments with any kind of subscription management will be detecting payments on the blockchain.

With #1 in place, we will have a full node we can ask about transactions.

Create a service which watches for transactions to a specified set of addresses and sends the critical details of them onward to some other payment tracking service. Guarantee at-least-once delivery (or better 😉) so that no payments are missed by the downstream system.

Switch from Sprout to Sapling addresses

Having upgraded to Zcash 2.0.1, it is now possible to work with (non-diversified) Sapling addresses. It should be less resource intensive to use these. Updated the (minimal) interaction the code currently has with such addresses to make sure they are Sapling addresses.

Persist subscription state

There is already a server which will accept HTTP requests to "create" new subscriptions. However, nothing is really created.

Create some real persistent state associated with the new subscription. Start with just a unique identifier but get it added to a persistent store, somehow.

All of the necessary fields to actually operate the service will come later.

Operate a Zcash Overwinter full node on S4

This is necessary to process shielded transactions.

It is likely this will need to be upgraded to a Sapling full node once a Sapling-capable node is available. That effort will be tracked separately.

This node only needs to join the Zcash network and keep up to date with new blocks. It will need persistent storage so it can easily remain up-to-date even if restarted.

This node can also be on the testnet and be switched to mainnet later on.

Send a real invoice down the Magic Wormhole

When #49 is complete it will be possible to have a real Magic Wormhole conversation with the service.

Build on that by implementing negotiation for a P4 invoice and then send a real P4 invoice.

The Tahoe-LAFS configuration in the m field of the invoice need not be legitimate.

Integrate subsequent payment information into a subscription state by extending subscription period

With #4 done, we will have a stream of payment information flowing. Create a service into which it can flow.

This service is responsible for a couple things, one of which is the maintenance of an existing subscription when a matching payment is detected.

It must be possible to associate this payment with an existing subscription. With Sapling diversified payment addresses, an option is for each subscription to receive its own payment address. Prior, an option is for the secure message field of the transaction to include a subscription identifier (returned previously alongside the other Tahoe-LAFS configuration data).

The Tor Onion services are unreliable

When restarting the different servers involved, the services often don't re-appear at their Onion address. This makes the whole system unreliable. Figure out how to make the services reliable.

Integrate initial payment information into a subscription state by creating new subscriptions

With #4 done, we will have a stream of payment information flowing. Create a service into which it can flow.

This service is responsible for a couple things, one of which is the creation of new subscriptions when a first payment is detected. Such a payment needs to receive a response containing the necessary subscription details (i.e., Tahoe-LAFS configuration).

Therefore, the initial payment must contain reverse addressing information of some sort. For example, a Zcash z address to which a zero-value transaction containing the information in the encrypted message field may be sent.

New subscriptions can be provisioned in the "subscription manager" service in the same way as web-based signup currently does.

Provide an endpoint which provisions a new subscription and returns an invite code for it

#10 will introduce a button on a web page. The button needs an endpoint to do the necessary work on the backend. Do it.

Publish customer invoices

Create an endpoint where customers can retrieve their current and future invoices.

Add some real logging to the server

Figure out what a good way to do logging in Haskell is. Then add some logging to the code that's present already.

Enable CI for the "s4" test suite

There are some automated tests in the repository now. Run them on a CI system.

Give out a real Magic Wormhole code in response to POST /v1/subscriptions

Currently a hard-coded bogus code is given out. Give out a code that can actually be redeemed at wormhole.leastauthority.com instead. A real invoice need not come out of it when redeemed but something should come out of it.

Refactor s4.nix to improve readability

Drag the low-level implementation details out to separate modules which can be invoked from s4.nix. Make s4.nix a nice high-level definition of coordination/orchestration using those other modules. Make reading s4.nix read like an overview of how the deployment works.

Upgrade the Zcash Overwinter full node to Sapling

The node deployed in #1 will need need to be upgraded to be a Sapling node (Zcash 2.0.1 probably).

Restore Onion Services if they are missing

Several events may destroy the Tahoe-LAFS storage service onion services (those created as a result of #53).

This happens if the Tor daemon restarts, if the S4 daemon restarts, or if the connection between the two is lost for some reason.

Create them if they are missing.

Secure the Zcash wallet

Investigate how to run the Zcash full node with only the incoming viewing key (or does it need the full viewing key? What is the difference?). Specifically, it should run without the spending key so that if it is compromised funds cannot be transferred away.

Since the node will be deployed for #1 , a brand new wallet / new keys should be generated here and the old wallet / keys discarded (drained of funds first, if necessary) since they will not necessarily have been deployed in a way that keeps them safe from compromise.

Ideally the payment address would be a multisig address. However, Zcash does not yet support multisig shielded addresses. A fallback might be to manually apply Shamir's Secret Sharing to the spending key (from which all other keys are derived) and distribute the pieces accordingly. This introduces operational complexity and requires some kind of trusted set up and distribution, though.

Add a "development" node to the S4 deployment

It might be useful to have a dedicated node alongside other nodes in the deployment the purpose of which is developer support only.

Operate a signup website on a Tor endpoint

To sign up, a user will navigate to a well-known Onion-address URL and click a button to receive an invite code.

Set up the necessary Tor node for operating such a site.