<div dir="ltr">Hi!<br><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">To start I will address questions earlier in the thread.The max session is not a hard limit, when max is reached a process of removing all previous sessions is started. It might be a problem if you have a constant high load. Maybe we should rethink!? The thing is the manager process must manage the session ids (used for resumption) and to not make this bottleneck to big we have to keep session data around for a little while as to let already spawned connection processes read it from the public ets table.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-12-07 23:41 GMT+01:00 Kenneth Lakin <span dir="ltr"><<a href="mailto:kennethlakin@gmail.com" target="_blank">kennethlakin@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/07/2016 05:30 AM, Fred Hebert wrote:<br>
> The option is cleverly named ... it prevents reuse of sessions, but not<br>
> their creation.<br>
<br>
Is it true that there's no way to change connection-specific SSL server<br>
or client options without tearing down the connection and recreating it?<br>
If it is, then shouldn't {reuse_sessions, false} prevent session caching<br>
for that connection? Or might the assumption be that a session created<br>
and cached with a {r_s, false} connection could be later reused with a<br>
{r_s, true} connection?<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>TLS sessions are not connection specific, so the assumption is that a later connection may want to reuse the session, and that by default you want to reuse a sessions if possible. I also think there is reason why RFC 5077 - "Transport Layer Security (TLS) Session Resumption without Server-Side State" was written.<br> </div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> We further detected more scans happening due to a PEM cache, which we<br>
> patched options to bypass it in <a href="https://github.com/erlang/otp/pull/1143" rel="noreferrer" target="_blank">https://github.com/erlang/otp/<wbr>pull/1143</a><br>
> -- the OTP team merged it in for OTP 19.1<br>
<br></span></blockquote><div><br></div><div>I am working at the moment to move the PEM cache to its own process, so that its work should not interrupt the manager process. We will keep the bypass option but it should no longer be needed to avoid cache overhead for certificates provided in DER  format.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
</span>I was going to complain that bypass_pem_cache option was undocumented,<br>
but I just found the ssl_app page that documents that option, as well as<br>
all of the SSL app options that I _thought_ were undocumented. I now<br>
feel quite a bit sheepish.<br></blockquote><div><br><br></div><div>I can take the opportunity to say that our docs has to kind of man pages, man(6)  the applications man page so to speak, that documents for instance  application variables. An man(3) pages that document the API of the application. The main API of the application is implemented in a module with the same name as the application, but there can be  more API modules. I would guess that the HTML version of the docs are the most used version. I am just saying there is a reason for the structure and knowing about it makes it easier to find things.<br><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB <br></div><div>  <br></div><div> </div></div></div></div></div></div>