What is the idea behind the default configuration of the ssl app?

[Ingela Andin]

Hi!

tisdag 21 juli 2020 skrev Maas-Maarten Zeeman <mmzeeman@REDACTED>:

> Setting up the ssl application safely for a particular situation can be
> quite hard.
>
> For instance, the default PEM cache and session ticket cache is 1000. The
> session lifetime is 24 hours. This is fine for a server which hardly get
> any traffic, but not ideal for web-servers which get millions of hits.
>
>
The PEM cache is only used by the server for its own certfiles and keyfile
so it will not matter how many clients connections it is hit with like in
the session case.


> Also when TLS 1.3 is used, by default no ticket replay mitigation is
> setup, which is something which is marked as “SHOULD” in the rfc.
>
> You mean for statless tickets. The reason is that we did not have time to
finish the implementation in time for 23.0, it will be included in 23.1. It
should be stated in the state of compliance documentation in the users
guide.



>     What is the idea behind the current defaults? Are they not meant for
> busy server applications?
>

The 24 h is what the RFC suggest as max lifetime. The real max will however
also depend on the max sessions that can be saved. That default is more of
guess of what we can get away with. We have a wide set of users from
embedde devices to powerful webservers. An a rang of protocols like https,
ftps, ldap etc  So picking some defaults is not always easy.


>
> I’m asking because I would like to add a way to easily setup server
> sockets with safe settings to https://github.com/zotonic/zotonic_ssl so
> people don’t have to fiddle with all the possible setting. Especially
> because there are quite some changes between different OTP releases in this
> area.
>
> Unfortunately not everything can be configured when you setup a socket,
> but the module could give warnings when the configuration of the ssl
> application as a whole is not right for a particular class of applications.
> Because of this I was wondering for what kind of applications the current
> defaults are meant, and wether I need to give different default options for
> different situations.
>


Mostly options that can not be set when setting up a socket is options that
affect some application global resource. In general we strive to have
secure defaults. And that is the reason behind most of the changes. Many of
our original defaults where inherited from OpenSSL like 10 years ago.

We have been thinking of maybe having some ”profile” defaults. But there
are lots of options and tradeoffs  and new features for TLS-1.3 so we have
not had time design that.

Regards Ingela Erlang/OTP team Ericsson AB


> Regards,
>
> Maas-Maarten Zeeman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200725/f33bec1d/attachment.htm>