In “Learn You Some Erlang for Great Good” by Fred Hébert, published in January 2013 by No Starch Press, San Francisco, we have a strange mixture of apparently humoristic remarks about the Erlang Security capabilities; but –at the same time— some good information that may help the prospective (or committed) Erlang developers and architects to address the issues we are studying. (All remarks below between square brackets are mine, CT.)
The book extols the Erlang design and functionalities –and rightfully so—for the ability of this language to provide a rare concurrent development and execution platform. The aspects of fault tolerance, resiliency, scalability, performance, light-weight process spawning and messaging are presented in a very useful introduction. But page after page we only see in action the staunch focus on “performance” and the related engineering objectives, and we have to progress to Chapter 26 (Distribunomicon, page 441) to finally find something related to Security.
The treatment is in accordance with the Erlang canonical documentation and other books on the subject: the Security aspect is understood only in the context of “distributed” computing. In other words, Security is perceived only as a need that arises in and for the intercommunication of computer hosts (nodes). A useful remark by Hébert is that “Like almost every other feature of Erlang, the distributed layer of the language was first added in order to provide fault tolerance.”
While still highlighting the “tooling” approach of the Erlang designers, Hébert presents a good summary of distributed computing, and the actual problems that arise in networked computing. He describes the “Fallacies of Distributed Computing” with the same kind of humour that he uses in the rest of the book, a positive characteristic, perhaps, but one that does not serve the subject well at some points.
In particular, it does not help to understand the author´s position when he addresses the lack of Security capabilities in Erlang. On pate 447 in the section titles “The Network is Secure,” he asserts that it is “dangerous to believe that everything is safe—that you can trust the messages you receive…” only to reveal to us that “In the case of distributed Erlang, this is sadly an assumption that was made [i.e. that the network *is* safe]”
Immediately Hébert shows a blank rectangle (“intentionally left blank”) to emphasise the fact that the Erlang security model is non-existent (page 447).
Here is where humoristic remarks do not help, especially because these help Hébert only to avoid a qualitative assessment of the Erlang capabilities. Hébert writes:
“This is because Erlang distribution was initially meant for fault tolerance and redundancy of components. In the old days of the language back when it was used for telephone switches and other telecommunication applications. Erlang would often be deployed on hardware running in the weirdest places—very remote locations with odd conditions […] In these cases you had failover hardware in the same physical location as the main hardware,. This is often where distributed Erlang would run, and it explains why Erlang designers assumed a safe network to operate with.”
“Sadly this means that modern Erlang applications can rarely be clustered automatically across different data centres. In fact, it isn’t recommended to do so. Most of the time, you will want your system to be based on many smaller, walled-off cluster of Erlang nodes, usually located in single locations.”
What is Fred Hébert’s actual take on this matter? While revealing the “blank” security model and “explaining” why the designers left out proper distributed capabilities, we nevertheless get the impression that all of this is not a problem. So, Hébert, despite the humoristic take on the total lack of Security model seems to side with the design choices that make Erlang a poor choice if there are any Security requirements for distributed computing.
As a solution for this bleak situation, Hébert suggests:
“Anything more complex [than the non-distributed environment he describes in the previous quotation] will need to be left to the developers using one of the following methods:
“-Switching to SSL
-Implementing their own high-level communications layer
-Tunnelling over secure channels
-Reimplementing the communication protocol between nodes.”
In other words, the author suggests that the “developers” should implement third party technologies, operating system mechanisms or else install their own code and solutions to supplement Erlang platforms for their lack of security capabilities.
This confirms my perception that Erlang is not only “light” in terms of Security, i.e. it has no defences at the level of the platform itself for example for access control, but it is also “dependent” on other components of an enterprise architecture (starting from the operating system and every other capability that may help to protect the weak Erlang platform.
Now, considering that a Secure environment is as safe as its weakest link, does this mean that any service platform utilising Erlang-OTP will be as weak as Erlang? Does this mean that when we think of Security in such an environment we should “count out” Erlang-OTP and not ask from it any Security capability and instead we should either programmatically or structurally provide security services around it?
Hébert points to various references which may help remedy the problems:
“Using SSL is explained in the Secure Socket Layer User’s Guide (Chapter 3, “Using SSL for Erlang Distribution,” at http://www.erlang.org/ doc/apps/ssl/ssl_distribution.html). Pointers on how to implement your own carrier protocol for the Erlang distribution are provided in the ERTS User’s Guide (Chapter 3, “How to implement an alternative carrier for the Erlang
distribution” at http://www.erlang.org/doc/apps/erts/alt_dist.html), which also contains details on the distribution protocol (Chapter 9, “Distribution Protocol,” at http://www.erlang.org/doc/apps/erts/erl_dist_protocol.html). “
All of which is just useful and potentially helpful, but also reveals a wrong notion of Security, one which limits it to the protection of the messaging channels and does not address the authorisation levels that may be granted on the software and *by* the software itself. By emphasising SSL and “roll-your-own” changes to the communication protocols Hébert is really not only addressing but effectively ignoring the real security issues we see in Erlang. And this is all we get:
“Even in these cases [i.e. when using SSL, etc,], you must be careful, because someone gaining access to one of the distributed nodes then has access to all of them, and can run any command those nodes can. “
On Page 462 the author turns to the Erlang inter-node communication cookies and writes:
“Many references such as the official Erlang documentation, put cookies under the topic of Security. But that has to be seen as a joke, because there’s no way anyone seriously considers cookies to be safe things. The cookie is a little unique value that must be shared between nodes to allow them to connect with each other. Cookies are closer to the idea of usernames than passwords, and I’m pretty sure no one would consider having a username (and nothing else) as a security feature.”
As you see, good and healthy humour only goes so far when you need to address things that are not funny.