SSL Deployment

[okdistribute]

originally posted by @maxogden

what we do now

We currently use https://github.com/mafintosh/taco-nginx to deploy node processes on Ubuntu servers. This is for deploying node services at subdomains, e.g. signalhub.dathub.org. We point *.dathub.org and dathub.org DNS at a server, and then use taco-nginx to deploy new subdomains on that server.

Our typical setup right now is to have a file called services.sh in the home folder of the server that has entries like this:

psy start -n signalhub -l /home/admin/logs/signalhub.log -- taco-nginx --name signalhub signalhub listen
psy start -n bootstrap -l /home/admin/logs/bootstrap.log -- dht-bootstrap 45.55.78.106
psy start -n dats --cwd /home/admin/src/dat-server -l /home/admin/logs/dats -- taco-nginx --name dats node cli.js

We currently use the psy process monitor. This shell script is idempotent and starts any non-started processes when executed. psy ls lists running processes.

admin@publicbits:~$ psy ls
signalhub      running  1676   3 months ago  taco-nginx --name signalhub signalhub listen
bootstrap      running  29147  3 months ago  dht-bootstrap 45.55.78.106
dats           running  20546  2 months ago  taco-nginx --name dats node cli.js

Executing taco-nginx --name dats node cli.js creates this file:

admin@publicbits:~$ cat /etc/nginx/conf.d/dats.conf 
upstream dats {
  server 127.0.0.1:48012;
}
server {
  listen 443;
  listen 80;
  server_name dats.*;
  location / {
    proxy_pass http://dats;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_buffering off;
    proxy_request_buffering off;
    proxy_http_version 1.1;
    client_max_body_size 0;

  }

}

It also reloads nginx and runs the process (node cli.js)

This is currently useful for dynamic services, but lacks two features:

• static pages
• automatic https for new subdomains

  what we want to do

Building on the above workflow, ideally youd be able to do npm run deploy and it would build the static site, push it up to a server and deploy it as e.g. docs.myserver.org using SSL from certbot/letcencrypt. One issue we have with github pages is you cant do custom domains with SSL. We can do that via cloudflare insecurely, or use surge.sh premium. Or roll our own :D If we can come up with a single workflow that works for static + dynamic processes it would probably be worth it roll our own.

Maybe we can add certbot integration to taco-nginx and a static file serving mode (e.g. just serve this folder full of html). Another fun thing is maybe we can use dat as the deployment tool :D

---

@mafintosh said: I use a wildcart ssl on my own domain to easily get ssl across all services. it costs a bit of money (100-200 usd per year) but its extremely easy to setup / use.

[ibolmo]

@karissa Sorry if it's painfully obvious, but just confirming: dat (and by extension hypercore) is currently running on regular (unsecure) tcp? Or is the p2p distribution already encrypted/secure connection?

Worried about man in the middle.

[joehand]

This issue refers to our discovery servers, which are only used to advertise that someone is sharing a key (but you need the key to find that person). Once peers connect, they do so directly, not through our server. So we avoid man in the middle because you only connect to peers that have the link.

Additionally, all data sent over the direct connection is encrypted.

(The discovery servers may have SSL now too)

[ibolmo]

Ah ok that's what I was wondering about. One last question can a secondary secret or whitelist IP scheme be used?

Highly unlikely that someone can guess the secret key, but in the off chance that a random guess does discover a dat folder what strategies can be employed to protect the resource?

I apologise again if the question is moot. I'm not very good at cryptography so I don't know the odds/complexity for guessing the secret keys.

On Fri, Dec 23, 2016, 3:34 PM Joe Hand notifications@github.com wrote:

This issue refers to our discovery servers, which are only used to advertise that someone is sharing a key (but you need the key to find that person). Once peers connect, they do so directly, not through our server. So we avoid man in the middle because you only connect to peers that have the link.

Additionally, all data sent over the direct connection is encrypted.

(The discovery servers may have SSL now too)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/datproject/projects/issues/1#issuecomment-269048075, or mute the thread https://github.com/notifications/unsubscribe-auth/AABqbpg8QBuZZbSvcS44AN2C4TSXclEsks5rLD6AgaJpZM4I4hRA .

[joehand]

I don't know the odds/complexity for guessing the secret keys.

It is probably more likely to get leaked by human error, but definitely a concern we have.

We don't have any methods for addressing this right now but have discussed both of the ones you suggested. For now, you could encrypt the data before adding it to Dat but we do have plans to address this privacy issue down the line.

[ibolmo]

Yeah it'll require bidirectional watch encrypt/decrypt into and out of dat folder. My usage is a Dropbox replacement so I understand if it's not a priority. Really excited about the project, though.

Keep me apprised of what the team decides/prefers. I'd like to contribute, if possible.

On Fri, Dec 23, 2016, 3:50 PM Joe Hand notifications@github.com wrote:

I don't know the odds/complexity for guessing the secret keys.

It is probably more likely to get leaked by human error, but definitely a concern we have.

We don't have any methods for addressing this right now but have discussed both of the ones you suggested. For now, you could encrypt the data before adding it to Dat but we do have plans to address this privacy issue down the line.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/datproject/projects/issues/1#issuecomment-269049295, or mute the thread https://github.com/notifications/unsubscribe-auth/AABqbu_Owy0rUlYGApGKmUnRJSoCXhqNks5rLEIRgaJpZM4I4hRA .