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

hostname resolution at peer connection #24

Open
St333p opened this issue Nov 4, 2020 · 6 comments
Open

hostname resolution at peer connection #24

St333p opened this issue Nov 4, 2020 · 6 comments
Labels
wontfix This will not be worked on

Comments

@St333p
Copy link
Contributor

St333p commented Nov 4, 2020

Currently lnp-cli connect <nodeid>@<address>[:<port>] does not resolve hostnames in the address field, and it accepts only IPv4, IPv6 or onion addresses; same applies to other subcommands such as ping and create. Hostname resolution should be useful for many applications.
For instance, it would come handy in a docker setting where nodes connect to each other referring to their respective hostnames within a docker network.

@dr-orlovsky
Copy link
Contributor

dr-orlovsky commented Nov 4, 2020

Well, the DNS is deliberately removed from LNP/BP Core library and nodes, to prevent occasional exposure of the node to DNS servers and deanonymization - as well as many other types of attacks. That's why only IP addresses and Onion.

The rule we follow: no outcoming traffic from the node other than peer traffic and RPC interface explicitly defined by the user.

One can write a simple script to resolve DNS into IP and paste it as a parameter to the node launching command.

PS. DNS, SSL, PKI delenda est

@dr-orlovsky dr-orlovsky added the wontfix This will not be worked on label Nov 4, 2020
@St333p
Copy link
Contributor Author

St333p commented Nov 5, 2020

Thanks for the clear answer.

I would really appreciate if you could point out some documentation for the attacks you mention, whenever you have time for it.

@dr-orlovsky
Copy link
Contributor

It's a well known attacks: if you don't use SSL nothing guarantees that you connect to the correctly resolved server; any cafe WiFi can direct you on some other host. If you use SSL, you are depending on government authorities authenticating your server and your identity, and the certificate can be revoked/not postponed.

@St333p
Copy link
Contributor Author

St333p commented Nov 5, 2020

Should we document this design choice a bit better? I can take this task.

@dr-orlovsky
Copy link
Contributor

You are welcome

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants