<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 24, 2018, at 6:02 AM, Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com" class="">jesper.louis.andersen@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Fri, Apr 20, 2018 at 3:57 PM Raimo Niskanen <<a href="mailto:raimo%2Berlang-questions@erix.ericsson.se" class="">raimo+erlang-questions@erix.ericsson.se</a>> wrote:<br class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello list!<br class="">
<br class="">
I am working on the task to get Erlang Distribution over TLS to be easy to<br class="">
use and flexible. :-/<br class="">
<br class=""></blockquote><br class=""></div><div class="gmail_quote">You know what I am going to say:<br class=""><br class=""></div><div class="gmail_quote">"What are NOT part of this task?"<br class=""><br class=""></div><div class="gmail_quote">I have a general toxic reaction to words such as "easy to use" and "flexible" because the former can hide important details in the name of easy, but then make more intricate setups impossible; and the latter often risks making the core of the system bad as a sacrifice for being able to do anything.<br class=""><br class=""></div><div class="gmail_quote">For cloud services, the general rules are:<br class=""><br class=""></div><div class="gmail_quote">* Machines are brought up and down at a whim, they usually change IP addresses, some times also networks.<br class=""></div><div class="gmail_quote">* Machines can have stable DNS names where the underlying IP change, so be prepared for that setting.<br class=""></div><div class="gmail_quote">* Some systems don't have stable DNS either<br class=""></div><div class="gmail_quote">* The network, cluster size, etc are all dynamic and will scale up and down depending on load.<br class=""></div><div class="gmail_quote">* The network is highly unreliable. Weekly disconnects are commonplace for any point-to-point connection. In larger clusters, assume daily TCP disconnects.<br class=""></div><div class="gmail_quote">* The network is likely to deliberately fault-inject to verify the system is robust under noise (Chaos-monkey strategies).<br class=""></div></div></div></blockquote><div><br class=""></div><div>So I agree with all of those, and I think it adds to the argument that any additional authentication over and above PKIX certificate validation should NOT use hostnames or IP addresses, or should not _require_ hostnames or IPs. I am still happy to rant about TLS hostname validation [sic], as it is complete and utter BS outside of the context of e-commerce, for which it was designed. Yet for some reason even intelligent people think it should make its way into RFCs. :head-bang:</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><br class=""></div><div class="gmail_quote">In this setting, the lure of having TLS would be that you don't have to build a virtual network which also encrypts. Rather, you can just have the Erlang nodes connect by TLS. It also simplifies the notion of connecting "into" the cluster from the outside.<br class=""><br class=""></div><div class="gmail_quote">The Erlang distribution protocol is quite the contrary to the typical cloud network though:<br class=""><br class=""></div><div class="gmail_quote">* Assumes a mostly stable static network<br class=""></div><div class="gmail_quote">* Assumes a few static machines<br class=""></div><div class="gmail_quote">* Assigns names to everything, in a somewhat static way<br class=""></div><div class="gmail_quote">* Assumes you know every node "beforehand" in many situations<br class=""><br class=""></div><div class="gmail_quote">I feel this is the impedance mismatch which is present. Hence my original pet-peeve: define the scope :)<br class=""><br class=""></div><div class="gmail_quote">My own solution would definitely be "screw you, TLS, here is my own public key registry, vault, and libsodium/enacl :)"<br class=""></div></div></div></blockquote><div><br class=""></div><div>Um, no. Not that TLS is a panacea, but...</div><div><br class=""></div><div><a href="https://github.com/saltstack/salt/commit/5dd304276ba5745ec21fc1e6686a0b28da29e6fc" class="">https://github.com/saltstack/salt/commit/5dd304276ba5745ec21fc1e6686a0b28da29e6fc</a></div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><i class="">I think the larger question here is: why aren't you using TLS?<br class=""><br class="">I will warn you in advance that "because we're using ZeroMQ" is a silly answer. This is at least the third vulnerability that has been found in your homebrew transport encryption, after the lack of a MAC and a timing attack. I hope you now realize that homebrewing your own transport encryption is a bad idea and you should seriously consider switching to TLS at this point to avoid future attacks.</i></div></div></blockquote><br class=""><div><div>-Fred</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><br class=""></div></div>
_______________________________________________<br class="">erlang-questions mailing list<br class=""><a href="mailto:erlang-questions@erlang.org" class="">erlang-questions@erlang.org</a><br class="">http://erlang.org/mailman/listinfo/erlang-questions<br class=""></div></blockquote></div><br class=""></body></html>