Hi!<br><br>tisdag 21 juli 2020 skrev Maas-Maarten Zeeman <<a href="mailto:mmzeeman@xs4all.nl">mmzeeman@xs4all.nl</a>>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Setting up the ssl application safely for a particular situation can be quite hard. <div><br></div><div>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. </div><div><br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div>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.</div><div><br></div></div></blockquote><div>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. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>    What is the idea behind the current defaults? Are they not meant for busy server applications?</div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div>I’m asking because I would like to add a way to easily setup server sockets with safe settings to <a href="https://github.com/zotonic/zotonic_ssl" target="_blank">https://github.com/zotonic/<wbr>zotonic_ssl</a> 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.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Regards Ingela Erlang/OTP team Ericsson AB</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>Regards,</div><div><br></div><div>Maas-Maarten Zeeman</div></div></blockquote>