Re: [Openvpn-devel] [PATCH v4] Add per session pseudo-random jitter to --reneg-sec intervals

[Simon Matter]

Hi,

> From: Simon Matter 
>
> While we were suffering from the "TLS Renegotiation Slowdown" bug here
> https://community.openvpn.net/openvpn/ticket/854 we realized that there is
> still room for improvement in our use case.
>
> It appears that TLS renegotiation is getting more and more expensive in
> terms of CPU cycles with recent changes for more security. To make things
> worse, we realized that most renegotiation procedures took place at almost
> the same time and increased the CPU load too much during these periods.
> That's especially true on large, multi-instance openvpn setups.
>
> I've created attached patch to add a per session pseudo-random component
> to
> the --reneg-sec intervals so that renegotiation is evenly spread over
> time.
> It is configured by simply adding a second value to --reneg-sec as
> described in the --help text:
>
> --reneg-sec max [min] : Renegotiate data chan. key after at most max
>   (default=3600) and at least min (default 90% of max on
>   servers and equal to max on clients).
>
> The jitter is only enabled by default on servers, because the actual reneg
> time is min(reneg_server, reneg_client).  Introducing jitter at both ends
> would bias the actual reneg time to the min value.
>
> Note that the patch also slightly changes the log output to show the sec
> value in the same way as the bytes/pkts values:
>
> TLS: soft reset sec=3084/3084 bytes=279897/-1 pkts=1370/0
>
> The idea and first versions of this patch are from Simon Matter.  Steffan
> Karger later incorporated the mailing list comments into this patch.  So
> credits go to Simon, and all bugs are Steffan's fault ;-)
>
> Signed-off-by: Simon Matter 
> Signed-off-by: Steffan Karger 
> ---
> v3: incorporate comments from openvpn-devel@, don't add jitter by
> default on the client side.
> v4: fix printing of reneg interval, clarify/typofix comments

I've tested it and it works as expected, thanks!

Regards,
Simon


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [patch] Fix time_t printing

[Jeremie Courreges-Anglas]

FWIW I have added a "portability" section to the CodeStyle page, and
a subsection about time_t & suseconds_t.

  
https://community.openvpn.net/openvpn/wiki/CodeStyle#Printingtime_tandsuseconds_tvalues

Feedback welcome.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE


signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v4] Add per session pseudo-random jitter to --reneg-sec intervals

[Steffan Karger]

From: Simon Matter 

While we were suffering from the "TLS Renegotiation Slowdown" bug here
https://community.openvpn.net/openvpn/ticket/854 we realized that there is
still room for improvement in our use case.

It appears that TLS renegotiation is getting more and more expensive in
terms of CPU cycles with recent changes for more security. To make things
worse, we realized that most renegotiation procedures took place at almost
the same time and increased the CPU load too much during these periods.
That's especially true on large, multi-instance openvpn setups.

I've created attached patch to add a per session pseudo-random component to
the --reneg-sec intervals so that renegotiation is evenly spread over time.
It is configured by simply adding a second value to --reneg-sec as
described in the --help text:

--reneg-sec max [min] : Renegotiate data chan. key after at most max
  (default=3600) and at least min (default 90% of max on
  servers and equal to max on clients).

The jitter is only enabled by default on servers, because the actual reneg
time is min(reneg_server, reneg_client).  Introducing jitter at both ends
would bias the actual reneg time to the min value.

Note that the patch also slightly changes the log output to show the sec
value in the same way as the bytes/pkts values:

TLS: soft reset sec=3084/3084 bytes=279897/-1 pkts=1370/0

The idea and first versions of this patch are from Simon Matter.  Steffan
Karger later incorporated the mailing list comments into this patch.  So
credits go to Simon, and all bugs are Steffan's fault ;-)

Signed-off-by: Simon Matter 
Signed-off-by: Steffan Karger 
---
v3: incorporate comments from openvpn-devel@, don't add jitter by
default on the client side.
v4: fix printing of reneg interval, clarify/typofix comments

 doc/openvpn.8 | 26 +-
 src/openvpn/init.c| 15 ++-
 src/openvpn/options.c | 11 +--
 src/openvpn/options.h |  1 +
 src/openvpn/ssl.c |  6 +++---
 5 files changed, 48 insertions(+), 11 deletions(-)

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index a4189ac2..eb5258f9 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -33,7 +33,7 @@
 .\" .ft -- normal face
 .\" .in +|-{n} -- indent
 .\"
-.TH openvpn 8 "25 August 2016"
+.TH openvpn 8 "04 April 2017"
 .\"*
 .SH NAME
 openvpn \- secure IP tunnel daemon.
@@ -4957,10 +4957,26 @@ Renegotiate data channel key after
 packets sent and received (disabled by default).
 .\"*
 .TP
-.B \-\-reneg\-sec n
-Renegotiate data channel key after
-.B n
-seconds (default=3600).
+.B \-\-reneg\-sec max [min]
+Renegotiate data channel key after at most
+.B max
+seconds (default=3600) and at least
+.B min
+seconds (default is 90% of
+.B max
+for servers, and equal to
+.B max
+for clients).
+
+The effective
+.B reneg\-sec
+value used is per session pseudo-uniform-randomized between
+.B min
+and
+.B max\fR.
+
+With the default value of 3600 this results in an effective per session value
+in the range of 3240..3600 seconds for servers, or just 3600 for clients.
 
 When using dual\-factor authentication, note that this default value may
 cause the end user to be challenged to reauthorize once per hour.
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 1ed2c55e..a4dd2c87 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -2693,7 +2693,20 @@ do_init_crypto_tls(struct context *c, const unsigned int 
flags)
 to.packet_timeout = options->tls_timeout;
 to.renegotiate_bytes = options->renegotiate_bytes;
 to.renegotiate_packets = options->renegotiate_packets;
-to.renegotiate_seconds = options->renegotiate_seconds;
+if (options->renegotiate_seconds_min < 0)
+{
+/* Add 10% jitter to reneg-sec by default (server side only) */
+int auto_jitter = options->mode != MODE_SERVER ? 0 :
+get_random() % max_int(options->renegotiate_seconds / 10, 1);
+to.renegotiate_seconds = options->renegotiate_seconds - auto_jitter;
+}
+else
+{
+/* Add user-specified jitter to reneg-sec */
+to.renegotiate_seconds = options->renegotiate_seconds -
+(get_random() % max_int(options->renegotiate_seconds
+- options->renegotiate_seconds_min, 
1));
+}
 to.single_session = options->single_session;
 to.mode = options->mode;
 to.pull = options->pull;
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 49ed004b..0a5c6a64 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -603,7 +603,9 @@ static const char usage_message[] =
 "  if no ACK from remote within n seconds (default=%d).\n"
 "--reneg-bytes n : Renegotiate data chan. key after n bytes sent and 
recvd.\n"