Server path

[mitra42]

@jmday raised the issue of storing server name, so we can remove any data from a malicious server. I think it needs to be server "path" a-la-usenet so that a bad server can't fake this field.

@danaronson Thoughts ?

Note - this does add the question of what constitutes a name for a server and might interact with the question you raised Dan about certificates for sync.

[danaronson]

maybe we just want to move to the certificate idea.

@jmday The thought that I had is that servers could be legitimate or illegitimate (and legitimate servers could become illigitemate) via Safe2 (or a greater collection or orgs) running a certificate authority. We could only allow connections from servers or clients that have a certificate signed by the certificate authority and have an open and transparent definition of what is required for our certificate authority to sign certificates.

[mitra42]

The client one might be hard - and not much point (and require complex cert distribution) but how hard would it be to distribute certs - I've never done this, I can think of simple ways of doing this
a) complex: certificate authority of our own, under one of the registrars I guess - I haven't a clue about this one
b) Wild card cert *.safe2.org, then a DNS server that matched DNS to cert.
c) People just need their own certs (e.g. Letsencrypt), in their own domains, and we keep some kind of global table of ones we register.

In any case in /sync we'd have to figure out how to check the cert (or assume the nginx front end had) and somehow capture the domain name from it ?

I don't know how to do any of this forward-looking in http (as opposed the https server being contacted having a cert), do you @danaronson

[danaronson]

I know how to do some of it. I would suggest not creating our own scheme. CA's are well documented and a clear way of doing this. Client certs can be included in builds (at least in IOS, pretty sure in android to). If you deal with certs it is important to also support CRL (certificate revocation list) in case you want to revoke someone's cert. Most webservers know how to do that.

Happy to have a conversation. i think this is an exact use case for CAs

[mitra42]

What about server<>server which is the real use case we care about in this Issue.

[danaronson]

people who run servers also create keys to register with the CA. Same thing, client certificates. I want to make clear that I've never done this, but have read enough to believe that it is pretty straightforward, and as I said, this is exactly one of the use cases for setting up a CA. https://roll.urown.net/ca/index.html

…

On Fri, May 8, 2020 at 8:28 PM Mitra Ardron ***@***.***> wrote: What about server<>server which is the real use case we care about in this Issue. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#119 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYRXCLXJOMZMQF4CFSCZDRQTEXLANCNFSM4M4PHARQ> .

[mitra42]

The path part of this is done in PR #128, so its now on @danaronson for the CA if that is the route we are going.

[mitra42]

If I understood our discussion - then the solution is to use the certificate or domain ID of the server we are connecting to via HTTPS (since its in 'sync' which is always a Pull from a known location.

[danaronson]

yes

…

On Wed, May 13, 2020 at 12:41 AM Mitra Ardron ***@***.***> wrote: If I understood our discussion - then the solution is to use the certificate or domain ID of the server we are connecting to via HTTPS (since its in 'sync' which is always a Pull from a known location. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#119 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYRXGRR3NBNGKZDSUGNCDRRJFJ5ANCNFSM4M4PHARQ> .