[erlang-questions] TLS Distribution Certificate Strategy

[Fred Dushin]

> On Apr 24, 2018, at 6:02 AM, Jesper Louis Andersen <jesper.louis.andersen@REDACTED> wrote:
> 
> On Fri, Apr 20, 2018 at 3:57 PM Raimo Niskanen <raimo+erlang-questions@REDACTED <mailto:raimo%2Berlang-questions@REDACTED>> wrote:
> Hello list!
> 
> I am working on the task to get Erlang Distribution over TLS to be easy to
> use and flexible. :-/
> 
> 
> You know what I am going to say:
> 
> "What are NOT part of this task?"
> 
> 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.
> 
> For cloud services, the general rules are:
> 
> * Machines are brought up and down at a whim, they usually change IP addresses, some times also networks.
> * Machines can have stable DNS names where the underlying IP change, so be prepared for that setting.
> * Some systems don't have stable DNS either
> * The network, cluster size, etc are all dynamic and will scale up and down depending on load.
> * The network is highly unreliable. Weekly disconnects are commonplace for any point-to-point connection. In larger clusters, assume daily TCP disconnects.
> * The network is likely to deliberately fault-inject to verify the system is robust under noise (Chaos-monkey strategies).

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:

> 
> 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.
> 
> The Erlang distribution protocol is quite the contrary to the typical cloud network though:
> 
> * Assumes a mostly stable static network
> * Assumes a few static machines
> * Assigns names to everything, in a somewhat static way
> * Assumes you know every node "beforehand" in many situations
> 
> I feel this is the impedance mismatch which is present. Hence my original pet-peeve: define the scope :)
> 
> My own solution would definitely be "screw you, TLS, here is my own public key registry, vault, and libsodium/enacl :)"

Um, no.  Not that TLS is a panacea, but...

https://github.com/saltstack/salt/commit/5dd304276ba5745ec21fc1e6686a0b28da29e6fc <https://github.com/saltstack/salt/commit/5dd304276ba5745ec21fc1e6686a0b28da29e6fc>

I think the larger question here is: why aren't you using TLS?

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.

-Fred

> 
> _______________________________________________
> 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/20180424/2b1e160b/attachment.htm>