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