Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve public key exchange while peering #57

Open
noidedgroid opened this issue Apr 28, 2016 · 8 comments
Open

Improve public key exchange while peering #57

noidedgroid opened this issue Apr 28, 2016 · 8 comments

Comments

@noidedgroid
Copy link

How can we reduce the friction from peering? Currently we need to exchange certificates (the self-signed ones created during config) out-of-band but we could instead have a well-known location for hosting this cert and having it pulled down automatically as long as the site has protected the resource with HTTPS (no good reason not to imo with Let's Encrypt out there). Ideas?

@majestrate
Copy link
Owner

what about an opt in CA that verifies each node's certificate?

@chen-chan
Copy link
Contributor

chen-chan commented Apr 28, 2016

What I've seen being done (including by myself) is putting the cert in /static/. Maybe a standardized place there could be a thing.
Or maybe and owner of a node can send a signed post that includes the cert and some peering info (the feeds.ini section). The interested users or the daemon than picks that post up and adds it as needed. In daemons case there may be some sort of mod page where those posts are formed into a peering menu where the peerings are populated. From there they can be set up further and enabled o disabled.
(i have no idea how to deal with certs normally lel)

@majestrate
Copy link
Owner

thread on nntpchan also

@noidedgroid
Copy link
Author

I like the idea of including the feeds.ini section (if only to confirm the port #), sorta an all-in-one bundle.
A CA might work but then we have to maintain it, could we not just make use of existing free certs? I was thinking of maybe integrating a lightweight let's encrypt client to make deployment even easier BUT they won't do .onion of course.

Maybe we could just pin the public key inside the feeds.ini? Small script to generate a copypaste-able block for people to copy into their feeds.ini and bam peering done?

@majestrate
Copy link
Owner

majestrate commented Apr 28, 2016

Maybe we could just pin the public key inside the feeds.ini?

that's pretty much what we do anyways

the idea of using a CA is that it'd be a CA just for overchan nodes that are "authorized" but that is too centralized so nevermind, that's a bad idea.

@majestrate
Copy link
Owner

thinking about this more, got an idea.

new newsgroup: ctl.ping

server signed messages only for server discovery.

every day server posts a list of all connected peers with their public key and address info.

@nilesr
Copy link
Contributor

nilesr commented Sep 5, 2017

existing nodes are only subscribed to ctl not ctl.* so it wouldn't be backwards compatible, especially with people who have set up their nodes and just left them running without checking on/performing maintenance on them

@majestrate
Copy link
Owner

ctl is for moderation messages so older nodes will process them as mod events. That is my reasoning for new newsgroup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants