SpiderOak/Encryptr

guide to self hosting?

petervnv opened this issue · 5 comments

Hi all,

I'd like to try out encryptr on a self-hosted debian machine.
I know I need to install crypton on that machine but is there any detailed guide or documentation on how to configure encryptr to use my cloud instead of SpiderOak's

Cheers,
Peter

Anyone? I can't believe I'm the only that has thought about self-hosting...

brad commented

You're definitely not the only one. I'd like to host it on a raspberry pi

4oo4 commented

I've self-hosted mine for a while, there's no (official) guide for self hosting. You basically just follow the build instructions for Crypton and Encryptr, the only difference for self-hosting being that you just need to edit a couple of config files before you actually build them.

For Crypton, you'll want to add your domain name in the CSP section in your server/config/config.production.json:


  "database": {
    "type": "postgres",
    "user": "REDACTED",
    "password": "READACTED",
    "database": "REDACTED",
    "host": "localhost",
    "port": 5432
  },
  "defaultKeySize": 32,
  "privateKey": "priv.pem",
  "certificate": "crt.pem",
  "appPath": ".",
  "redis": {
    "host": "localhost",
    "port": 6379,
    "pass": "",
    "db": 2
  },
  "commitStatusCheckDelay": 100,
  "commitStatusCheckLimit": 100,
  "securityHeaders": {
    "csrf": false,
    "csp": {
      "policy": {
        "default-src": "'self' blob: localhost",
        "connect-src": "'self' wss://localhost:1025 example.com",
        "script-src": "'self' example.com",
        "img-src": "'self' example.com",
        "style-src": "'self' example.com",
        "font-src": "'self' example.com",
        "object-src": "'self' example.com"
      },
      "reportOnly": false,
      "reportUri": ""
    },
    "xframe": "SAMEORIGIN",
    "p3p": false,
    "hsts": {
      "maxAge": 3600,
      "includeSubDomains": false,
      "preload": false
    },
    "xssProtection": false
  },
  "port": 1025
}

In my case, I did an nginx reverse proxy from 1025 to 443 to match how they run Crypton on encryptrstaging.crypton.io:443 (may not be needed if you're running both instances on the same machine):

		location /crypton/ {
                   if (-f $document_root/maintenance.html) {
                            return 503;
                   }
                   proxy_pass https://127.0.0.1:1025/;
                   proxy_http_version 1.1;
		   proxy_set_header Upgrade $http_upgrade;
		   proxy_set_header Connection "upgrade";
		   proxy_set_header X-Real-IP $remote_addr;
	           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;		  
		   proxy_set_header Host $http_host;
		   proxy_set_header X-NginX-Proxy true;
                   proxy_set_header X-Forwarded-Proto https;
                   proxy_set_header X-Forwarded-Port 443;
		   access_log /var/log/nginx/crypton_access.log;
                   error_log /var/log/nginx/crypton_error.log;

		}

Note the trailing slash on the /crypton/ location as well as https://127.0.0.1:1025/, it won't work without it.

Once you have Crypton running, you point Encryptr to your Crypton instance in src/app.js, like so:

    // Set the hostname for the Crypton server
    window.crypton.host = "example.com";
    window.crypton.port = 443;

If also you run yours on a subdirectory, you'll need to add the subdomain a little later on in src/app.js (for this reason it's better to run it on it on its own subdomain):

      // What the xhr checks
      checks: {
        xhr: {
          url: ("https://" +
                window.crypton.host +
                (window.crypton.port ? (":" + window.crypton.port) : "") +
                "/crypton")
        }
      }
    };

Then, go ahead and build Encryptr like the repo says, at which point I copy the contents of encryptr/www to a directory in my nginx root and chown the folder to www-data.

Finally, there's just a little bit of additional nginx config so that it plays nice with websockets. First, I add this to the http section of my nginx config (so it knows how to upgrade HTTP connections to WebSockets):

 	 map $http_upgrade $connection_upgrade {
	    default upgrade;
   	 ''      close;
	}

Then add ws*.example.com to your server_name in your virtual host (so it will listen on wss://example.com as well as https://example.com):

        server {
                server_name example.com www.example.com ws*.example.com;
		listen 443 default ssl http2;
		listen [::]:443 default ssl http2;

That's pretty much it! It's been a really long time since I set it up so I may have forgot something, but that covers most of it.

Thank you so much 4oo4.
This is exactly the kind of info I was looking for.
Much appreciated!

4oo4 commented

I knew I forgot something, there was one last piece of nginx config for websockets:

		location ~* /socket.io {
           	     if (-f $document_root/maintenance.html) {
                     	return 503;
                     }
		     proxy_pass https://127.0.0.1:1025;
                     proxy_set_header Upgrade $http_upgrade;
                     proxy_set_header Connection 'upgrade';
                     proxy_cache_bypass $http_upgrade;
		     proxy_http_version 1.1;
                     proxy_set_header X-Real-IP $remote_addr;
                     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                     proxy_set_header Host $http_host;
                     proxy_set_header X-Forwarded-Proto https;
                     proxy_set_header X-Forwarded-Port 443;

                     access_log /var/log/nginx/encryptr_access.log;
                     error_log /var/log/nginx/encryptr_error.log;

                    }