<div dir="ltr">Hi Lukas,<div><br></div><div>It's a great question! </div><div>And actually, choosing between disabling epmd completely and protecting communication via TLS, will have somewhat different security benefits. </div><div><br></div><div>1. <b>Protecting epmd communication via TLS</b> - This only protects us from an attacker that wants to perform epmd impersonation, because TLS here is authenticating only the server node to the client node. </div><div>Then perhaps if we have two Erlang nodes on the same machine, let's say Node1 and Node2, an attacker can make the client node connect to Node2 instead of Node1 by returning the wrong port by a simple manipulation of the plain epmd traffic, and in that way expose sensitive data to the client node, which exists in Node2 but not in Node1. Maybe it's a bit far fetched but from my limited knowledge it looks like a possible attack scenario. </div><div>Another thing that the encryption is good for here is probably in preventing a covert channel. </div><div><br></div><div>2. <b>Disabling epmd completely</b> - This approach eliminates a lot more attack vectors actually. </div><div>Just as one simple example, assume for a moment that we have a buffer overflow bug in epmd, then using this approach you will not be affected by it. By completely disabling an unnecessary service (if it's really unnecessary of course, in some situations I assume epmd is very much required!) the attack surface reduces much more so it's difficult to list in detail everything we'll be protecting against. </div><div>Nevertheless, we all know that it's a good security practice to disable unrequired services whenever you can :) and especially ones that listen to requests from the outside world.</div><div><br></div><div>Regards,</div><div>Amit</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 22, 2019 at 2:49 PM Lukas Larsson <<a href="mailto:lukas@erlang.org">lukas@erlang.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 22, 2019 at 1:02 PM Amit K <<a href="mailto:klg.amit@gmail.com" target="_blank">klg.amit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Greg,<div><br></div><div>Thank you for your feedback!</div><div>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. </div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Lukas</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Regards,</div><div>Amit</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 22, 2019 at 10:54 AM Grzegorz Junka <<a href="mailto:list1@gjunka.com" target="_blank">list1@gjunka.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>On 21/10/2019 21:25, Amit K wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>I am very new to Erlang, am considering to use it in a
project and I have some security concerns. </div>
<div>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: <a href="https://www.erlang-solutions.com/blog/erlang-and-elixir-distribution-without-epmd.html" target="_blank">https://www.erlang-solutions.com/blog/erlang-and-elixir-distribution-without-epmd.html</a></div>
<div><br>
</div>
<div>So I was thinking, seeing that there are already options
to:</div>
<div>1. Start a distributed node without epmd (<span style="color:rgb(52,52,52);font-family:monospace,serif;font-size:14px;letter-spacing:0.28px">-start_epmd
false</span>) </div>
<div>2. Limit a node's port numbers to a specific range (via <span style="background-color:rgb(247,247,247);color:rgb(52,52,52);font-family:monospace,serif;font-size:11.9px;letter-spacing:0.28px;white-space:pre-wrap">inet_dist_listen_min &</span><span style="background-color:rgb(247,247,247);color:rgb(52,52,52);font-family:monospace,serif;font-size:11.9px;letter-spacing:0.28px;white-space:pre-wrap"> inet_dist_listen_max</span>).</div>
<div><br>
</div>
<div>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:</div>
<div>spawn("Name@Host:Port", Mod, Func, ArgList). <br>
</div>
<div>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. </div>
<div>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.</div>
<div><br>
</div>
<div>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 :)</div>
</div>
<br>
</blockquote>
<p><br>
</p>
<p>Hi Amit,</p>
<p>There is also another option, run any communication between nodes
via <a href="https://en.wikipedia.org/wiki/IP_tunnel" target="_blank">IP tunnels</a>.
There are some <a href="https://www.virtualthoughts.co.uk/2019/07/15/application-security-with-mutual-tls-mtls-via-istio/" target="_blank">tools
to automate that</a>. 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.</p>
<p>Regards<br>
Greg<br>
</p>
</div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div></div>
</blockquote></div>