<div dir="ltr"><div><div><div><div><div><div>with this scenario you can easily DOS yourself. you don t even need DDOS, DOS is enough.<br><br></div><div>In fact I managed to almost DOS myself - in test environment, of course<br></div><div><br></div>With a few hundred concurrent ssl connections to the server one can easily run out of memory<br>sooner than might think.<br><br></div>What about few thousands or millions of concurrent ssl connections?<br><br></div><div>In 24 hours a lot of data can be accumulated from a lot of clients<br></div><div><br></div>Of course one can distribute the application and load balance it, but still the problem is not solved.<br><br></div>The only solution I came up with was that to use a tcp reversed proxy as a a ssl off-loader a<br>nd speak with Erlang plain text.<br><br></div><div>This way the memory remains constant (with little variations, of course) .<br></div><div><br></div>If plain connections are involved the total Ets memory usage does not exceed a value <br>around 600 - 700 Kilobytes of RAM.<br><br></div>And also I am able to confirm the fact that ssl connections opened from Erlang vm<br> (so, as client) does not affect the Ets: memory usage.<br><div><br><br><br><div><div><div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 5, 2014 at 3:15 PM, Tony Rogvall <span dir="ltr"><<a href="mailto:tony@rogvall.se" target="_blank">tony@rogvall.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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>
<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>
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>
<br>
/Tony<br>
<div><div class="h5"><br>
> On 5 nov 2014, at 13:08, Bogdan Andu <<a href="mailto:bog495@gmail.com">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">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>
</blockquote></div><br></div>