<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><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" class="">Setting up the ssl application safely for a particular situation can be quite hard. <div class=""><br class=""></div><div class="">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 class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">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></blockquote><div><br class=""></div><div>Sorry, I meant the session cache. The default is 1000 sessions there. When you hit that limit the ssl_manager will silently invalidate all sessions. That is a valid strategy, but it is problematic that it does this silently without at least logging something. Our server normally has around 60k open ssl connections. And because it is handling web traffic, there are a lot of sessions which are opened and abandoned quickly. At the time of introduction I overlooked this config option, and had to figure out in production what was slowing down ssl. (recon ftw). Adding a warning log message when the session cache reached its limit will probably very helpful in figuring out how to fix this.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></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" class=""><div class=""><br class=""></div><div class="">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 class=""><br class=""></div></div></blockquote><div class="">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></blockquote><div><br class=""></div><div>Yeah, stateless tickets do not work right now. Opened a PR with an easy fix.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> </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" class=""><div class=""> What is the idea behind the current defaults? Are they not meant for busy server applications?</div></div></blockquote><div class=""><br class=""></div><div class="">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></blockquote><div><br class=""></div><div>Yes, I can imagine that. We have a couple of different services (http, smpt, mqtt) on our application. The fact that some settings are done at the ssl app level, like the session_cache, session lifetimes, and tls 1.3 session ticket lifetimes and the stateful storage max sizes, means we have to run the different sockets with the same base settings. This is not ideal. We would prefer to be able to set different limits per socket. For the http socket we need a large session cache, and short lifetimes. For the mqtt, which is used less, the cache can be smaller, but the session lifetimes should be longer.</div><br class=""><blockquote type="cite" class=""><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" class=""><div class=""><br class=""></div><div class="">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" class="">https://github.com/zotonic/<wbr class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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></blockquote></div><div><br class=""></div><div><br class=""></div><div>The implementation and configuration details of TLS will always be a moving target I think. Maybe that makes having a sort of profile system even more important in order to hide the implementation details a bit. </div><div><br class=""></div><div><br class=""></div><div>Regards, </div><div><br class=""></div><div>Maas-Maarten Zeeman</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""></body></html>