search

bluelinklabs / ctzn

[DEPRECATED] An open social network built on the Hypercore Protocol data mesh.
https://ctzn.network
MIT License
286 stars 25 forks source link

Server Validation (NS PTR vs. Certificates) #28

Open lmangani opened 3 years ago

lmangani commented 3 years ago

related to: https://github.com/pfrazee/ctzn/blob/master/docs/setting-up-a-server.md#step-5---enable-gclouds-ptr-record

@hamnox seemed to also have input about this subject on the livestream, so opening up this issue for further discussion. apologies in advance should this be just a misinterpretation of the scope and purpose of the current NS requirement.

The currently implemented DNS PTR validation method for IP/domain association of a ctzn server might brutally work for straightforward dedicated server scenarios, but unfortunately introduces a huge number of limiting factors and roadblocks for deploying a dynamic ctzn node w/o a single static IP and/or those running a distributed cloud server relays where IPs might change, but the target domain/server certificate remains intact. My glitch server is one such case realistically - and just like anything on azure, heroku, amazon the service/server is accessible through a battery of IPs serving from dynamic sub-domains we might not own/manage, but otherwise a realistic if not ideal platform to deploy ctzn. Add-On custom domains PTRs would not help much either as far as I can think - any network failure or failover would be tedious to handle/recover from without downtime even if the server data and cert were still perfectly fine.

This is where I think validating the host certificates would be ideal just like browsers mandate, and might allow a durable deployment resilient to network/server relocation, fail-over scenarios, etc. where the data and the domain remain intact:

1) CTZN node B with IP 1.2.3.4 claims to be serving domain "my.domain" towards CTZN node A 2) CTZN node A validates if IP 1.2.3.4 can provide a valid certificate for "my.domain" of CTZN node B regardless of its IP 3) If the cert matches the domain i(n both directions?) cross-join and cross-communication should be allowed.

(banning and black/whitelisting servers/networks for private deployments should be a separate subject)

Note: might want to enable discussions on the repo to avoid everything being reported as an issue?

pfrazee commented 3 years ago

Yeah the issue that @hamnox hit may just be a simple config thing when dealing with docker.

I'm not currently sure which solution will be easier for server admins, I can see why one might be easier than the other. I don't see any reason not to implement both.

lmangani commented 3 years ago

Bumping this up after the (amazing!) alpha launch as this was quite the showstopper for custom server joining communities.

not-not-the-imp commented 3 years ago

I'm now taking the plunge and setting my own server. I'm on a 24 lead time [0] for the DNS to change, and it is not terribly great.

I would say that while SSL/TLS certificate are a mess in general, they are in my case quicker to generate (or acquire) than changing a reverse DNS setting. Lets encrypt[1] and certbot [2] did make it a lot easier for me to get them.

I don't have a mail server or any other server that are on the same IP, so that's not an issue for me. I would expect that the cost of multiple IPv4 addresses would be higher than a SSL/TLS certificate for me.

[0] A screen grab of my VPS provider: reverseDNS

[1] https://letsencrypt.org/ [2] https://certbot.eff.org