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

[Lukas Larsson]

On Tue, Oct 22, 2019 at 1:02 PM Amit K <klg.amit@REDACTED> wrote:

> 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.
>

I'm kind of curious about what type of attacks you are trying to protect
against? You mention "man in the middle", however, I cannot see how someone
could exploit that to do anything but disrupt the distributed erlang
connections. Though that could only be a lack of imagination on my part,
and when it comes to security we must be extra careful.

Lukas


>
> 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
>>
> _______________________________________________
> 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/91ea08ad/attachment.htm>