-
Notifications
You must be signed in to change notification settings - Fork 19
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
Nodes API should use HTTPS #75
Comments
Documentation should be added to show node operators how to set up dns and ssl. This would be a separate issue. |
adamstallard
changed the title
Nodes API should use HTTPS
Nodes API should use HTTPS (120-200 Subs)
Apr 7, 2020
alirezapaslar
changed the title
Nodes API should use HTTPS (120-200 Subs)
Bounty - Nodes API should use HTTPS (120-200 Subs)
Apr 13, 2020
alirezapaslar
changed the title
Bounty - Nodes API should use HTTPS (120-200 Subs)
Nodes API should use HTTPS (120-200 Subs)
Apr 16, 2020
adamstallard
changed the title
Nodes API should use HTTPS (120-200 Subs)
Nodes API should use HTTPS (60-100 Subs)
Aug 31, 2020
adamstallard
changed the title
Nodes API should use HTTPS (60-100 Subs)
Nodes API should use HTTPS
Sep 13, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reason for the change
It's good for nodes to have an https:// url for the api so that a Link ContextId operation doesn't reveal the link between a BrightID and a ContextId. Also so that BrightIDs aren't associated with IP addresses.
Another option is for clients to know a node's public key and encrypt the canonicalized json using it, but I think https:// also covers data that is returned that might also link a user's BrightID to an IP address and also some clients work better with https:// so it's nice for a node to provide it.
How to implement the change
I think for supporting HTTPS, we should consider using nginx that is not in a container. We can write instructions for installing nginx and configuring it with letsencrypt. They will obviously need to have registered domain for the certificate.
Having another nginx in front of the nginx container should be easier for users to understand and configure than bringing the nginx out of its container. It also means fewer container ports need to be published on the host.
The text was updated successfully, but these errors were encountered: