<div dir="ltr"><div><div><div>only for R17 I tested this .<br><br><br></div>if you do not do cache at all the cpu usage increases <br>and dummy cache module is out of questions.<br><br></div><div>so a balance must be founded between session reuse (which a re good) and processor usage.<br></div><div><br>application:get_env(ssl, session_lifetime).<br><br></div><div>returns ok the values.<br><br></div><div>If I have time I'll dig into the code to see what happens deeper.<br></div><div><br></div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 7, 2014 at 4:20 PM, Ingela Andin <span dir="ltr"><<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi!<br><br></div><br></div><div>The following release note is from the first R15 version of ssl:<br></div><div><br>"Invalidation handling of sessions could cause the
time_stamp field in the session record to be set to
undefined crashing the session clean up process. This did
not affect the connections but would result in that the
session table would grow."<br></div><div><div><div><div><div class="gmail_extra"><br></div><br><div class="gmail_extra"><div class="gmail_quote"><span class="">2014-11-07 11:58 GMT+01:00 Bogdan Andu <span dir="ltr"><<a href="mailto:bog495@gmail.com" target="_blank">bog495@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"><div dir="ltr"><div><div><div>I work with R14B04 as production and OTP 17.3 as experimental.<br><br></div><div>R14B04 also deletes all entries after 24 hours.<br></div><div><br></div><div>17.3 also deletes all entries after 24 hours.</div><br>I think is it has to do with passing the environment parameter like this:<br><br>erl -ssl session_lifetime 60 ...<br><br></div><div>I tried many variants and may be I miss something.<br></div><div><br></div>may be I am mistaken but it is possible that only the default value, 24 hours,<br></div>is only considered as the environment variable is not passed correctly by me.<br><div><br></div><div>i think the environment parameters are the problem here because maybe i specify them incorrctly.<br><br></div><div>could you advise what is the proper method of correctly specifying session_lifetime, because according to <br></div><div>manual is like :<br></div><div><br>erl -ssl session_lifetime 60 ...<br></div></div></blockquote></span><div><br><br>You can check with application:get_env(ssl, session_lifetime). to see if you succeed setting the variable.<br><br> </div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>a ssl session must expire afte 60 seconds + delayed 60 seconds = 2 minutes.<br><br></div><div>intstead entries from 'ssl_otp_session_cache' be deleted every 2 minutes, they remain 24 hours .<br><br>after 22 hours I have:<span><br><br>Node: 'n1@www-apps' (Connected) (17/6.2) unix (openbsd 5.4.0) CPU:2 SMP +A:10<br></span>Time: local time 12:50:23, up for 000:21:54:49, 0ms latency,<br>Processes: total 676 (RQ 0) at 21121 RpI using 10978.0k (11007.4k allocated)<br>Memory: Sys 14898.8k, Atom 410.8k/419.5k, Bin 112.9k, Code 10053.7k, Ets 720.6k<br><br><br></div><div>and for ets:i().<br><br>...........<br> 28695 ssl_otp_session_cache ordered_set 115 7134 ssl_manager<br>..........<br><br></div><div>The vm was configured with 60 seconds session lifetime and the client was running 60 seconds<br></div><div>an I expected after 2 minutes to see less entries in the table but they remained untouched<br><br><br></div><div>I will see what happens after 24 hours mark and I'll let you know<br></div><div><br></div><div>and another thing...<br><br></div><div>even if i pass the options:<br>{reuse_session, fun(_,_,_,_) -> false end},<br>{reuse_sessions, false},<br><br></div><div>both or individually , to the ssl:listen/2 function the table is filled with sessions and they expire after 24 hours, <br>only that cpu is working harder, 7-8% which means the sessions a not reused and the ssl <br>handshake is happening every time.<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div><br></div></font></span></div></blockquote><div><br></div></span><div>Was that for both R14 and R17?<br></div><div><div class="h5"><div><br><br><div class="gmail_extra">Regards Ingela Erlang/OTP team - Ericsson AB<br></div><br><br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span><font color="#888888"><div><br></div><div>Bogdan<br></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 7, 2014 at 10:37 AM, Ingela Andin <span dir="ltr"><<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Hi!<br><br></div>Which version of the ssl application are you using? The session cleanup was broken in one of the older versions.<br><br></div>Regards Ingela Erlang/OTP - team Ericsson AB<div><div><br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2014-11-06 17:20 GMT+01:00 Bogdan Andu <span dir="ltr"><<a href="mailto:bog495@gmail.com" target="_blank">bog495@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"><div dir="ltr"><div><div>yes,<br><br></div>in function ssl_manager:invalidate_session/4, the call<br><br><span>erlang</span>:<span>send_after</span>(<span>delay_time</span>(), <span>self</span>(), {<span>delayed_clean_session</span>, <span>Key</span>}), does the actual deletion of session from cache<br><br></div>where <span>delay_time</span>/0 function returns <span>?<span>CLEAN_SESSION_DB by default, which is 60 seconds<br><br><br><br></span></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 6, 2014 at 4:51 PM, Ingela Andin <span dir="ltr"><<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi!<br><br></div><div><br><div><div class="gmail_extra"><div class="gmail_quote"><span>2014-11-06 14:39 GMT+01:00 Bogdan Andu <span dir="ltr"><<a href="mailto:bog495@gmail.com" target="_blank">bog495@gmail.com</a>></span>:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi,<br><br></div><span>i have tried to pass to execute th following forms of commands:<br><br></span></div><span>erl -ssl session_lifetime 60<br><br>erl -ssl session_lifetime '60'<br><br>erl -ssl session_lifetime '[60]'<br><br><br></span></div><span>in order to set a ssl session_lifetime of 60 seconds.<br><br></span></div><span><div>in init of ssl_manager , after session_lifetime + 5 seconds a process is created to validate or invalidate sessions.<br></div><div>So, after 65 seconds a foldl is called on sessions table to check sessions after formula:<br> <span>Now</span> <span>-</span> <span>TimeStamp</span> <span><</span> <span>LifeTime<br><br></span></div><div><span>However, even after I stop the client, the table 'ssl_otp_session_cache' 's size remains the same.<br></span></div><div><br><br></div>After that once every ?<span>CLEAN_SESSION_DB which is 60 seconds , the table is sweeped to delete any expired sessions,<br><br></span></span></div><span>but also nothing happens.<br></span><div><div><div><br></div></div></div></div></blockquote><div><br></div><div>There is also a delay in the actual deletion. In the first sweep the sessions will only be invalidated as there may already be<br></div><div>spawned connection handlers that needs to read the session data before we may delete it. It is a performance trade off. <br></div><div><div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB<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"><div dir="ltr"><div><div><div></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 6, 2014 at 12:28 PM, Ingela Andin <span dir="ltr"><<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi!<br><br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote"><span>2014-11-06 8:53 GMT+01:00 Bogdan Andu <span dir="ltr"><<a href="mailto:bog495@gmail.com" target="_blank">bog495@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"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div>Hi,<br><br></div>on my production servers I have relayd (on OpenBSD) daemon as a reverse proxy to some webservers<br></div>where one can fine tune some connection parameters, as well as some ssl parameters.<br><br></div>I give a snippet from a relayd.conf configuration file on one of my production server:<br><br>.............<br>#<br># Relay and protocol for HTTP layer 7 loadbalancing and SSL acceleration<br>#<br>http protocol www_ssl_prot { <br> header append "$REMOTE_ADDR" to "X-Forwarded-For"<br> header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"<br> header change "Connection" to "close"<br> <br> response header change "Server" to "Apache 0.1"<br><br> # Various TCP performance options<br> tcp { nodelay, sack, socket buffer 65536, backlog 128 }<br><br> ssl { no sslv2, no sslv3, tlsv1, ciphers "HIGH" }<br> ssl session cache disable<br>}<br><br></div>the last directive tells relayd not to use ssl cache.<br><br></div>This configuration is working for years and relayd was restarted once by accident - my fault.<br><br></div>SO, y question is:<br><br></div>can we have this configurable in Erlang, in other words, we might be able to start an erlang vm such as:<br><br></div>erl -ssl session_cache 'disable' -name <a href="mailto:x@a.com" target="_blank">x@a.com</a> ....<br><br></div>The ssl option session_cache can be set to disabled by default and can take values either disable or enabled.<br><br><br></div></div></div></blockquote><div><br></div></span><div>You can already disable the reuse of the sessions using the server option <b>{reuse_sessions, boolean()}</b> which default to true.<br></div><div>The thing we plan to do is to have a configurable limit on the table size when sessions are reused.<br><br></div><div>Regards Ingela Erlang/OTP team Ericsson AB<br></div><div><div><div><br><br> <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"><div dir="ltr"><div><div></div>Just to let you know...<br><br></div>The statistics of a node running from yesterday when I opened this thread of discussion, using a single client:<br><div><div><div><br>Node: 'n1@www-apps' (Connected) (17/6.2) unix (openbsd 5.4.0) CPU:2 SMP +A:10<br>Time: local time 09:48:48, up for 000:20:27:49, 0ms latency,<br>Processes: total 681 (RQ 0) at 610275 RpI using 11526.4k (11805.8k allocated)<br>Memory: Sys 94835.5k, Atom 407.7k/419.5k, Bin 176.4k, Code 9934.7k, Ets 80739.2k<br><br>...........<br><br></div><div>So, can be this made configurable?<br></div><div><br><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 5, 2014 at 8:52 PM, Ingela Andin <span dir="ltr"><<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi!<br><div class="gmail_extra"><br><div class="gmail_quote"><span>2014-11-05 14:15 GMT+01:00 Tony Rogvall <span dir="ltr"><<a href="mailto:tony@rogvall.se" target="_blank">tony@rogvall.se</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">I think the ssl session times is the problem here, and the lack of a maximum size.<br>
<br>
You can change the session time in the ssl environment: session_lifetime<br>
The default is set to 24 hours (in seconds) (if I read it correctly, in ssl_manager.erl)<br></blockquote><div><br></div></span><div>Default values are always hard. It is the maximum recommended time for a session to live</div><div>according to the spec.</div><span><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">
<br>
I guess that a session_cache_size could be a nice thing to have,<br>
limiting the growth of the session cache.<br>
<br></blockquote><div><br></div></span><div>Yes I agree.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In other words you have to estimate the life time of your clients and<br>
try to find a reasonable session_lifetime to match that, without blowing up<br>
the system.<br>
<br>
Maybe the ssl_session_cache_api could be used to implement a strategy with a max size<br>
cache. Retire session least recently used, while performing the update?<br>
There is a time_stamp in the session that that could be used for this purpose.<br>
<br>
OTP: Why is a fixed limit not implemented in the standard ssl_session_cache?<br>
Could this be a target for DOS attacks?<br></blockquote><div><br></div><div><br></div></span><div>We are aware of the problem, and it is on our todo list. One reason it has not had top priority is that on the server side there are often other mechanisms</div><div>like firewalls and webbserver settings that limits the problem. And the reason why it was not implemented in the first place is that implementations by nature</div><div>are iterative and at first you are faced with a lot of bigger problems to solve and then you need to iterate and fine tune and fix things that you now have a better understanding of. </div><div><br></div><div>In current master there is a change to the session table that limits the growth on the client side if the client behaves inappropriate. It also splits the session table into </div><div>a server and a client table which is a better implementation as the same Erlang node can be both a client and a server at the same time. So if someone feels like contributing a max limit please base it on the master branch, otherwise I suspect someone compiling about it did raise the priority level a little. </div><div><br></div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB</div><div><div><div> </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">
<br>
/Tony<br>
<div><div><br>
> On 5 nov 2014, at 13:08, Bogdan Andu <<a href="mailto:bog495@gmail.com" target="_blank">bog495@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> Hi,<br>
><br>
> I performed a series of test regarding the an Erlang SSL server.<br>
><br>
> In this setup a major role is played by the table called 'ssl_otp_session_cache', and of course the processes using it.<br>
><br>
> The problem is that the size of table increases constantly and, because an ets table does not automatically deallocate memory unless the object are deleted from that table, the size of table remains the same even if there no ssl connections to server.<br>
><br>
> For example, with a single client running 'ad infinitum' the table increases at a rate of 5 MBytes/hour. In 12 hours there are allocate around 60 MB of memory only for this table.<br>
><br>
> Some info about this:<br>
> $ erl -sname console@www-apps -remsh n1@www-apps -setcookie operator<br>
> Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:2:2] [async-threads:10] [kernel-poll:false]<br>
><br>
> Eshell V6.2 (abort with ^G)<br>
><br>
><br>
> (n1@www-apps)1> ets:i().<br>
> id name type size mem owner<br>
> ----------------------------------------------------------------------------<br>
> 12 cookies set 0 291 auth<br>
> 4111 code set 410 26132 code_server<br>
> 8208 code_names set 58 7459 code_server<br>
> 12307 httpc_manager__session_cookie_db bag 0 291 httpc_manager<br>
> 16404 ssl_otp_cacertificate_db set 0 291 ssl_manager<br>
> 20501 ssl_otp_ca_file_ref set 0 291 ssl_manager<br>
> 24598 ssl_otp_pem_cache set 3 360 ssl_manager<br>
> 28695 ssl_otp_session_cache ordered_set 138057 8421893 ssl_manager<br>
> 32797 dets duplicate_bag 2 308 dets<br>
> 40990 ign_requests set 0 291 inet_gethost_native<br>
> 45087 ign_req_index set 0 291 inet_gethost_native<br>
> 2261635104 shell_records ordered_set 0 81 <0.30638.37><br>
> ac_tab ac_tab set 33 2216 application_controller<br>
> code_map code_map set 100 2791 <0.72.0><br>
> config config set 12 892 <0.72.0><br>
> dets_owners dets_owners set 1 298 dets<br>
> dets_registry dets_registry set 1 299 dets<br>
> file_io_servers file_io_servers set 1 344 file_server_2<br>
> global_locks global_locks set 0 291 global_name_server<br>
> global_names global_names set 0 291 global_name_server<br>
> global_names_ext global_names_ext set 0 291 global_name_server<br>
> global_pid_ids global_pid_ids bag 0 291 global_name_server<br>
> global_pid_names global_pid_names bag 0 291 global_name_server<br>
> httpc_manager__handler_db httpc_manager__handler_db set 0 291 httpc_manager<br>
> httpc_manager__session_db httpc_manager__session_db set 0 291 httpc_manager<br>
> inet_cache inet_cache bag 0 291 inet_db<br>
> inet_db inet_db set 29 600 inet_db<br>
> inet_hosts_byaddr inet_hosts_byaddr bag 0 291 inet_db<br>
> inet_hosts_byname inet_hosts_byname bag 0 291 inet_db<br>
> inet_hosts_file_byaddr inet_hosts_file_byaddr bag 0 291 inet_db<br>
> inet_hosts_file_byname inet_hosts_file_byname bag 0 291 inet_db<br>
> models models set 3 28952 <0.72.0><br>
> sys_dist sys_dist set 1 334 net_kernel<br>
> ok<br>
> (n1@www-apps)5> ets:info(ssl_otp_session_cache).<br>
> undefined<br>
> (n1@www-apps)7> (8421893*8)/1024.<br>
> 65796.0390625<br>
> (n1@www-apps)8> memory().<br>
> [{total,92699464},<br>
> {processes,8964000},<br>
> {processes_used,8963152},<br>
> {system,83735464},<br>
> {atom,429569},<br>
> {atom_used,421768},<br>
> {binary,199040},<br>
> {code,10411520},<br>
> {ets,69163032}]<br>
><br>
> The memory allocated to table 'ssl_otp_session_cache' is roughly 64 MB in 12 hours.<br>
><br>
> On an OpenBSD platform such process gets killed immediately it hits some memory and/or CPU limits.<br>
><br>
> To make this test on OpenBSD I had to put 'infinit' to memory, otherwise the Erlang VM would be killed.<br>
><br>
> How can one control , tweak or configure this table such that it does not accumulate such data at such high rate.<br>
><br>
> I seems the table being created private, and there is no way to ets:delete_all_objects/1 from table manually.<br>
><br>
> I know that this table caches some SSL data related to clients, but the client has the same IP address,<br>
> and I wonder why is neccesary to store a lot of SSL connection info about the same client when only the ephemeral peer port<br>
> differs?<br>
><br>
> How the size of this table can be held in reasonable limits and the rate it's size increases ?<br>
><br>
> Please if somebody shed some light on these issues.<br>
><br>
> Thank you,<br>
><br>
> Bogdan<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"<br>
<br>
<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div></div></div></div></div>
</blockquote></div><br></div>