[erlang-questions] Supporting a port number in spawn/4

[Amit K]

Hi Greg,

Thank you for your feedback!
In general, I think it makes sense to have a solution for this that's built
in to OTP and not have to use an external proxy method.
Going more along the route of what you suggest, a sensible alternative
would be for epmd.exe to be able to accept TLS settings like the Erlang
node (erl.exe) does, and then communication with it will also be protected
by TLS. a quick look at the code makes me  guess that the reason that was
not done originally is that epmd is a small & separate utility written in C
and therefore it doesn't have the "crypto" framework like the other OTP
parts do.

Regards,
Amit



On Tue, Oct 22, 2019 at 10:54 AM Grzegorz Junka <list1@REDACTED> wrote:

>
> On 21/10/2019 21:25, Amit K wrote:
>
> Hi all,
>
> I am very new to Erlang, am considering to use it in a project and I have
> some security concerns.
> I can see it's quite easy to configure TLS for the node-to-node
> communication, but making the name-to-port resolution service (epmd) secure
> seem a bit too complex to me, such as the one suggested here:
> https://www.erlang-solutions.com/blog/erlang-and-elixir-distribution-without-epmd.html
>
> So I was thinking, seeing that there are already options to:
> 1. Start a distributed node without epmd (-start_epmd false)
> 2. Limit a node's port numbers to a specific range (via inet_dist_listen_min
> & inet_dist_listen_max).
>
> Wouldn't it be nice if we could also specify a predefined port to spawn/4,
> to complete that picture? That is allow spawn to look like:
> spawn("Name@REDACTED:Port", Mod, Func, ArgList).
> Then when spawn sees that a port was provided, it can completely skip the
> "epmd resolution" part and proceed with connecting to the target node via
> the provided port.
> Note: I realize that the "Name" becomes slightly redundant when the Port
> is explicit. However this can still be useful - it would be good if the
> implementation will also verify that the port belongs to the provided name
> at the receiving side, so that a node will not accidentally process a
> message that wasn't meant for it.
>
> Again, I'm a complete newbie to Erlang in general, so I may be missing
> something essential here :) But I would love to know what that is, if
> that's the case, or hear your thoughts in general otherwise :)
>
>
> Hi Amit,
>
> There is also another option, run any communication between nodes via IP
> tunnels <https://en.wikipedia.org/wiki/IP_tunnel>. There are some tools
> to automate that
> <https://www.virtualthoughts.co.uk/2019/07/15/application-security-with-mutual-tls-mtls-via-istio/>.
> They are mostly used between docker containers or pods but it's just a
> detail, equally well they can support a microarchitecture build on Erlang
> nodes.
>
> Regards
> Greg
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20191022/7d84ed6d/attachment.htm>