[openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation

[Sebastian Andrzej Siewior]

From: Sebastian Andrzej Siewior <sebastian at breakpoint.cc>

If the client performs repeatedly a SSL handshakes (via
SSL_renegotiate()) then the server will use much more resources than
the client does. I managed to get 30% load on the server and 7% on the
client side.
This is a computation attack and unfortunately the way a SSL handshake
works. I understand that this `feature' is part of the TLS specification
and I am not trying to nuke from openssl. Instead I would like to
describe the possible attack and some countermeasures to mitigate its
outcome. Having it in the doc section would allow one to ping other
projects, point them to this section and ask them if they could drop the
support for re-negotiation request from the client. From looking around,
nginx for instance does not support renegotiation from client's side.

Signed-off-by: Sebastian Andrzej Siewior <sebastian at breakpoint.cc>
---
 doc/ssl/SSL_CTX_set_options.pod | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/doc/ssl/SSL_CTX_set_options.pod b/doc/ssl/SSL_CTX_set_options.pod
index 635b470e1245..137035c7f6f0 100644
--- a/doc/ssl/SSL_CTX_set_options.pod
+++ b/doc/ssl/SSL_CTX_set_options.pod
@@ -255,6 +255,23 @@ renegotiation between OpenSSL clients and unpatched servers B<only>, while
 B<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION> allows initial connections
 and renegotiation between OpenSSL and unpatched clients or servers.
 
+=head2 Possible attack through renegotiation
+
+The renegotiation performs a new handshake. A handshake is more expensive on
+the server side than on the client side. It is possible that a client with
+little bandwidth and with only a few connections to the server will put the
+server in a position where it will use 100% of its CPU if the client repeatedly
+attempts to renegotiate and therefore constantly performs a new handshake.
+Therefore it is recommended not to renegotiate the handshake if the client
+requested it but only do it on the server side.
+
+If the server drops the connections once the client tries to abuse via a
+renegotiation attempt then the attack is not yet fully mitigated. The client
+can still open multiple connections only for the purpose to perform a handshake
+and close it immediately. This is similar to the initial scenario. It is
+recommended to track frequent connects at firewall level and reject abusive
+connections attemps before the handshake is performed.
+
 =head1 RETURN VALUES
 
 SSL_CTX_set_options() and SSL_set_options() return the new options bitmask
-- 
2.8.1