[erlang-questions] SSL server session cache table issues:

[Ingela Andin]

Hi!

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.

2016-12-07 23:41 GMT+01:00 Kenneth Lakin <kennethlakin@REDACTED>:

> On 12/07/2016 05:30 AM, Fred Hebert wrote:
> > The option is cleverly named ... it prevents reuse of sessions, but not
> > their creation.
>
> Is it true that there's no way to change connection-specific SSL server
> or client options without tearing down the connection and recreating it?
> If it is, then shouldn't {reuse_sessions, false} prevent session caching
> for that connection? Or might the assumption be that a session created
> and cached with a {r_s, false} connection could be later reused with a
> {r_s, true} connection?
>
>
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.



> > We further detected more scans happening due to a PEM cache, which we
> > patched options to bypass it in https://github.com/erlang/otp/pull/1143
> > -- the OTP team merged it in for OTP 19.1
>
>
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.



> I was going to complain that bypass_pem_cache option was undocumented,
> but I just found the ssl_app page that documents that option, as well as
> all of the SSL app options that I _thought_ were undocumented. I now
> feel quite a bit sheepish.
>


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.

Regards Ingela Erlang/OTP team - Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20161208/a18726e8/attachment.htm>