14) ElixirConf EU 2019 - Learn you some 'ssl' for much security! - Bram Verburg

Learning Resources Talks
, , ,
1

@voltone - Security advocate, BEAM enthusiast

Learn you some ‘ssl’ for much security!

Talk in three words: TLS, security, troubleshooting

Abstract
Erlang/OTP’s built-in ‘ssl’ application forms the basis of many client and server packages. Unfortunately it has quite a few quirks, potentially leading to weak security. This talk highlights the most important client and server settings for ‘ssl’ sockets, how the defaults have evolved across OTP versions, and how popular libraries build on them. Topics include cipher suite selection, server hostname verification, known certificate issues (wildcard SAN, cross-signed CA), revocation checks, ECDSA servers, and more.

Objectives
Learn to apply secure TLS configurations to clients and servers, either directly with the OTP ‘ssl’ application or through the many libraries that rely on it: Ranch, Cowboy, Plug, Phoenix, httpc, Hackney, HTTPoison, etc.

Audience
Anyone building applications that include TLS client or server functionality, directly or through packages, which means just about anyone developing on the BEAM. The speaker Bram is an architect and security advocate with more than 20 years experience delivering complex software platforms to tier-1 telcos around the world, meeting their stringent security and reliability requirements. He has been using Erlang, and later Elixir, since 2010. As a security advocate, he has taken an interest in the security aspects of the Erlang/OTP ecosystem. This focus he has also continued as a blogger, trainer, speaker, and open source contributor. His latest project is the X509 package, available on Hex.

All will be added to the ElixirConf EU 2019 Talks List or via the #elixirConfEU2019 tag.

14 Likes
2

Wow, wow and wow, I am trilled with all I have learned from this talk and at same time very disappointed with the insecure defaults used by OTP :(.

Security MUST be Opt Out not Opt In, and if the prevalence of the security as Opt in prevails, and its delegated to us developers to properly secure them by the authors of libraries and tools, no one can reasonably expect that the current panorama of a so insecure internet will change at any point in the future, because in the end of the day the majority just want to make it work and finish the sprint on time.

3

Agreed. And I’d love to get the OTP team to adopt verify: :verify_peer as the default for TLS client connections. That way, if the user did not pass in a CA trust store, connections fail with {:error, {:options, {:cacertfile, []}}}. At that point the user is forced to decide: bring in a trust store, or explicitly opt out of verification by passing verify: :verify_none.

Still, I also think application developers have a responsibility to test the end-product, the same way you would include tests to verify user authentication, even if it is mostly handled by a 3rd party package. We all need to talk about this, improve the defaults, improve the documentation, and improve the testing. It all starts with awareness, which was the main goal of the talk.

3 Likes
4

I have open a security report with the Elixir team, because when I was trying to make Elixir work behind the firewall I discovered some unexpected behaviours due to the use of httpc.

I think you should really open an CVE for this with the OTP team, because this defaults make anything using httpc vulnerable to MitM attacks.

man-in-the-middle
man-in-the-middle889×318 28.7 KB

source: https://blog.approov.io/steal-that-api-key-with-a-man-in-the-middle-attack

In my opinion the use of such insecure default shouldn’t be used nowadays, where data breaches occur every week.

Remember that this mentality of being insecure by default in our industry is one of the root causes of the insecure internet we have nowadays. This is because lots of the software used by developers treat security as an opt-in instead of opt-out feature. So lots of developers don’t know they need to secure it or they forget to do it so when releasing to production, or they make errors securing it, that in the end leads to the catastrophic results of so many data breaches and open databases online. Anyone can search in Shodan for databases open to public, like MongoDB, ElasticSearch, Mysql and others.

Remember GDPR in Europe? This is one of the first steps from legislators trying to get control on our data being exposed, and once this will fail, they will legislate the develoeprs profession and makes us personnaly accountable for the mistakes we do… Do you really want to be a developer in a world where legislation regulates your profession? Don’t be mistaken that this cannot happen in the future, because already happen to many other professions that failed to self regulate themselves.

6

Still, I also think application developers have a responsibility to test the end-product, the same way you would include tests to verify user authentication, even if it is mostly handled by a 3rd party package.

I completely agree here, but this not excuse software and tools being used by developers of being insecure by default.

We all need to talk about this, improve the defaults, improve the documentation, and improve the testing. It all starts with awareness, which was the main goal of the talk.

Awareness and discussion around the subject is important, and the first step to make the mentality of security as an opt-out to become the default.

7
2 Likes