Add per session pseudo-random component to --reneg-sec intervals

Hi,

Initially I've created this RFE but have been told to send it to the devel list instead:

https://community.openvpn.net/openvpn/ticket/865

Unfortunately I'm not a developer and have never used git so please bear with me as I send a classic patch to the list.

As suggested by user "syzzer" I also tried to improve the patch and here it is:

-------%<--------------------------------------------------------------- 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 n [r] : Renegotiate data chan. key after n seconds default=3600)
and if r is specified, add a per session pseudo-random component in the range of 1 ... r to n (default=0).

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 patch is tested and seems to work well in my environment. As always, comments are very welcome.

Would be nice to have this patch accepted and included in OpenVPN 2.4.2.

Quoted 49 lines

Hi,

Initially I've created this RFE but have been told to send it to the devel list instead:

https://community.openvpn.net/openvpn/ticket/865

Unfortunately I'm not a developer and have never used git so please bear with me as I send a classic patch to the list.

As suggested by user "syzzer" I also tried to improve the patch and here it is:

-------%<--------------------------------------------------------------- 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 n [r] : Renegotiate data chan. key after n seconds default=3600)
and if r is specified, add a per session
pseudo-random
component in the range of 1 ... r to n (default=0).

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 -------%<---------------------------------------------------------------

Quoted 4 lines

The patch is tested and seems to work well in my environment. As always, comments are very welcome.

Would be nice to have this patch accepted and included in OpenVPN 2.4.2.

Any comments on this patch? Would be nice to get some feedback :)

Simon

Interesting to see that there is zero interest in this patch here.

Hi,

Quoted 1 line · Simon Matter

Interesting to see that there is zero interest in this patch here.

This is a misinterpretation.

Quoted 7 lines

Hi,

Quoted 1 line · Simon Matter

Interesting to see that there is zero interest in this patch here.

This is a misinterpretation.

Hi Gert,

Thanks for the explanation, I'll be patient then :)

Quoted 7 lines

Hi,

Quoted 1 line · Simon Matter

Interesting to see that there is zero interest in this patch here.

This is a misinterpretation.

Hi Gert,

Thanks for the explanation, I'll be patient then :)

If it's preferred for the patch to keep it even simpler and compatible the current configs, it could be broken down to something like this in init.c:

I've attached v2 now which works without any config change:

I prefer this version as it allows everybody to profit from it without touching any config files.

Quoted 1 line · Simon Matter

I've attached v2 now which works without any config change:

[..]

Quoted 2 lines

I prefer this version as it allows everybody to profit from it without touching any config files.

I can see the reasoning, but 25% feels a bit on the high side :-) - so let the ratholing begin what the number should be.

Steffan, any views from the crypto side of things?

Hi,

Quoted 9 lines · Gert Doering

Quoted 1 line · Simon Matter

I've attached v2 now which works without any config change:

[..]

Quoted 2 lines

I prefer this version as it allows everybody to profit from it without touching any config files.

I can see the reasoning, but 25% feels a bit on the high side :-) - so let the ratholing begin what the number should be.

Quoted 1 line

Steffan, any views from the crypto side of things?

Not really. I think the feature makes sense, and I like that this will only *substract* from the set time (so not exceed any set limits).

(And I agree that 25% feels on the high side - my gut says somewhere around 10%, but I have no analysis to show why that would be better. I'll leave picking that number to you.)

Quoted 12 lines

Hi,

Quoted 9 lines · Gert Doering

Quoted 1 line · Simon Matter

I've attached v2 now which works without any config change:

[..]

Quoted 2 lines

I prefer this version as it allows everybody to profit from it without touching any config files.

I can see the reasoning, but 25% feels a bit on the high side :-) - so let the ratholing begin what the number should be.

Quoted 8 lines

Quoted 1 line

Steffan, any views from the crypto side of things?

Not really. I think the feature makes sense, and I like that this will only *substract* from the set time (so not exceed any set limits).

(And I agree that 25% feels on the high side - my gut says somewhere around 10%, but I have no analysis to show why that would be better. I'll leave picking that number to you.)

The default is 60 minutes. With 25% that means a time window of 15 minutes, so reneg-sec will occur between 45-60 minutes.

I see this can be too much for some sites, and perhaps too little on
sites which have many users. With 10%, the reneg-window is reduced to
54-60 minutes. For larger sites, this is most likely too small of a window - though far better than everyone at "exactly" 60 minutes.

But I am also wondering if this randomness should only occur on the first renegotiation.

If you have a 6 minutes time window and 100 connected clients, there is a big chance that at some point the randomness will cause a similar congestion again, as multiple clients to have the same delay. With 25% that chance is lower, but the chance increases again with more clients.

So what if this randomness instead only occurs on the _first_ negotiation and then respect the --regneg-sec setting? Then clients will somewhat spread out and then keep a certain predictable renegotiation load. And if using 17%, you get a time window of roughly 10-11 minutes where renegotiation happens. With 100 clients, that means roughly (with a theoretical, ideal and even spread) 10 clients per minute. Which is more reasonable. With 200 clients, it is still getting crowded but not too bad.

But all that said ... I think it would be wise to have an optional argument to --reneg-sec (in addition to the 'sec' argument we have today) which can be used to further open or close this time window. Larger sites will most likely want a larger time window than smaller ones.

Btw ... is --reneg-sec pushable? (Too lazy to check the code, man page says "no"). If not, it would probably be a good idea to enable that.

Quoted 52 lines · Steffan Karger

Quoted 12 lines

Hi,

Quoted 9 lines · Gert Doering

Quoted 1 line · Simon Matter

I've attached v2 now which works without any config change:

[..]

Quoted 2 lines

I prefer this version as it allows everybody to profit from it without touching any config files.

I can see the reasoning, but 25% feels a bit on the high side :-) - so let the ratholing begin what the number should be.

Quoted 8 lines

Quoted 1 line

Steffan, any views from the crypto side of things?

Not really. I think the feature makes sense, and I like that this will only *substract* from the set time (so not exceed any set limits).

(And I agree that 25% feels on the high side - my gut says somewhere around 10%, but I have no analysis to show why that would be better. I'll leave picking that number to you.)

The default is 60 minutes. With 25% that means a time window of 15 minutes, so reneg-sec will occur between 45-60 minutes.

I see this can be too much for some sites, and perhaps too little on
sites which have many users. With 10%, the reneg-window is reduced to
54-60 minutes. For larger sites, this is most likely too small of a window - though far better than everyone at "exactly" 60 minutes.

But I am also wondering if this randomness should only occur on the first renegotiation.

If you have a 6 minutes time window and 100 connected clients, there is a big chance that at some point the randomness will cause a similar congestion again, as multiple clients to have the same delay. With 25% that chance is lower, but the chance increases again with more clients.

So what if this randomness instead only occurs on the _first_ negotiation and then respect the --regneg-sec setting? Then clients will somewhat spread out and then keep a certain predictable renegotiation load. And if using 17%, you get a time window of roughly 10-11 minutes where renegotiation happens. With 100 clients, that means roughly (with a theoretical, ideal and even spread) 10 clients per minute. Which is more reasonable. With 200 clients, it is still getting crowded but not too bad.

But all that said ... I think it would be wise to have an optional argument to --reneg-sec (in addition to the 'sec' argument we have today) which can be used to further open or close this time window. Larger sites will most likely want a larger time window than smaller ones.

Quoted 2 lines

Btw ... is --reneg-sec pushable? (Too lazy to check the code, man page says "no"). If not, it would probably be a good idea to enable that.

As I understand it client and server have 60 min. by default. Whatever is configured, the smaller value wins. That means, bad clients can set their reneg-sec to very low values and trash the server on the other end. From the server side this looks more or less like a DDOS.

In our environment we have set reneg-sec=0 on all clients because we want the server to have control over it. That's fine because we have only trusted clients. Making it pushable could be a solution to overwrite bad settings in clients.

A more radical solution was to just remove the option on the client side.

Quoted 8 lines

Quoted 7 lines

Hi,

Quoted 1 line · Simon Matter

Interesting to see that there is zero interest in this patch here.

This is a misinterpretation.

Quoted 6 lines

Hi Gert,

Thanks for the explanation, I'll be patient then :)

If it's preferred for the patch to keep it even simpler and compatible the current configs, it could be broken down to something like this in init.c:

I've attached v2 now which works without any config change:

--reneg-sec n
Renegotiate data channel key after n seconds (default=3600).

Note that the effective value used here is a per session pseudo- randomized 25% of n deducted from n. With the default value of 3600 this results in an effective per session value in the range of 2701 ... 3600 seconds.

Quoted 17 lines · Simon Matter

Quoted 8 lines

Quoted 7 lines

Hi,

Quoted 1 line · Simon Matter

Interesting to see that there is zero interest in this patch here.

This is a misinterpretation.

Quoted 6 lines

Hi Gert,

Thanks for the explanation, I'll be patient then :)

If it's preferred for the patch to keep it even simpler and compatible the current configs, it could be broken down to something like this in init.c:

I've attached v2 now which works without any config change:

Quoted 8 lines

--reneg-sec n
Renegotiate data channel key after n seconds (default=3600).

Note that the effective value used here is a per session pseudo- randomized 25% of n deducted from n. With the default value of 3600 this results in an effective per session value in the range of 2701 ... 3600 seconds.

A different approach could be like so:

--reneg-sec 3600
--reneg-sec-1sttime-rand 1|0 (The name here for detail)

Quoted 30 lines · On 05/04/17 16:42, debbie10t wrote:

Quoted 17 lines · Simon Matter

Quoted 8 lines

Quoted 7 lines

Hi,

Quoted 1 line · Simon Matter

Interesting to see that there is zero interest in this patch here.

This is a misinterpretation.

Quoted 6 lines

Hi Gert,

Thanks for the explanation, I'll be patient then :)

If it's preferred for the patch to keep it even simpler and compatible the current configs, it could be broken down to something like this in init.c:

I've attached v2 now which works without any config change:

Quoted 8 lines

--reneg-sec n
Renegotiate data channel key after n seconds (default=3600).

Note that the effective value used here is a per session pseudo- randomized 25% of n deducted from n. With the default value of 3600 this results in an effective per session value in the range of 2701 ... 3600 seconds.

Quoted 4 lines

A different approach could be like so:

--reneg-sec 3600
--reneg-sec-1sttime-rand 1|0 (The name here for detail)

Too complicated ;-)

--reneg-sec # 60 minutes, with X % in randomness
--reneg-sec 1800 # 30 minutes, with X % in randomness (X is what we figure is reasonable by default; between 10-25%)

--reneg-sec 3600 30 # 60 minutes, 30% randomness
--reneg-sec 1800 0 # 30 minutes, no randomness

This won't break any configurations and gives full flexibility without adding new options (which we really try to avoid).

Quoted 9 lines · David Sommerseth

Quoted 7 lines · On 05/04/17 16:42, debbie10t wrote:

A different approach could be like so:

--reneg-sec 3600
--reneg-sec-1sttime-rand 1|0 (The name here for detail)

Oh, and in regards to the first-time/non-first-time .... if we decide for such flexibility, that can be a flag after the randomness.

For example --reneg-sec 3600 12 first-only

I am far from convinced if that should be configurable or not. But still, this approach is still far better than introducing new options.

As I understand it client and server have 60 min. by default. Whatever is configured, the smaller value wins. That means, bad clients can set their reneg-sec to very low values and trash the server on the other end. From the server side this looks more or less like a DDOS.

In our environment we have set reneg-sec=0 on all clients because we want the server to have control over it. That's fine because we have only trusted clients. Making it pushable could be a solution to overwrite bad settings in clients. A more radical solution was to just remove the option on the client side.

Quoted 12 lines · David Sommerseth

Quoted 9 lines · David Sommerseth

Quoted 7 lines · On 05/04/17 16:42, debbie10t wrote:

A different approach could be like so:

--reneg-sec 3600
--reneg-sec-1sttime-rand 1|0 (The name here for detail)

Quoted 8 lines

Oh, and in regards to the first-time/non-first-time .... if we decide for such flexibility, that can be a flag after the randomness.

For example --reneg-sec 3600 12 first-only

I am far from convinced if that should be configurable or not. But still, this approach is still far better than introducing new options.

Ok - accept that new options is not preferred but ..

I like the idea of "first-only" addition (which is more or less as I proposed anyway) - And so, instead of having randomness in the reneg-sec itself, it is only randomness in the first run, after that the expected behaviour would be restored. eg: --reneg-sec 3600

To my mind (as a non programmer) this essentially boils down to setting the first --reneg-sec timer to something between 1 and 3600 (default). This affords a much larger window for the scattering of clients and further behaviour is "as expected now".

and it looks very non-instrusive to me ..

Quoted 36 lines · David Sommerseth

Quoted 12 lines · David Sommerseth

Quoted 9 lines · On 05/04/17 16:42, debbie10t wrote:

Quoted 7 lines

A different approach could be like so:

--reneg-sec 3600
--reneg-sec-1sttime-rand 1|0 (The name here for detail)

Quoted 8 lines

Oh, and in regards to the first-time/non-first-time .... if we decide for such flexibility, that can be a flag after the randomness.

For example --reneg-sec 3600 12 first-only

I am far from convinced if that should be configurable or not. But still, this approach is still far better than introducing new options.

Ok - accept that new options is not preferred but ..

I like the idea of "first-only" addition (which is more or less as I proposed anyway) - And so, instead of having randomness in the reneg-sec itself, it is only randomness in the first run, after that the expected behaviour would be restored. eg: --reneg-sec 3600

To my mind (as a non programmer) this essentially boils down to setting the first --reneg-sec timer to something between 1 and 3600 (default). This affords a much larger window for the scattering of clients and further behaviour is "as expected now".

Quoted 2 lines

and it looks very non-instrusive to me ..

To clarify: --reneg-sec 3600 RAND

Where RAND indicates that the first-run timer should run from a random integer from 1 upto the value of --reneg-sec. RAND does not require a user to specify an amount.

Quoted 5 lines

Where RAND indicates that the first-run timer should run from a random integer from 1 upto the value of --reneg-sec. RAND does not require a user to specify an amount.

But then, why not just do it always and forget about the additional option?

Quoted 7 lines

Quoted 5 lines

Where RAND indicates that the first-run timer should run from a random integer from 1 upto the value of --reneg-sec. RAND does not require a user to specify an amount.

But then, why not just do it always and forget about the additional option?

Quoted 1 line

Optional option does not mean that it is disabled by default. If you don't the randomness you would need to do:

reneg-sec 3600 3600

the optional argument also allows it to fine tune it to your needs.

Quoted 6 lines

Optional option does not mean that it is disabled by default. If you don't the randomness you would need to do:

reneg-sec 3600 3600

the optional argument also allows it to fine tune it to your needs.

As the reason for --reneg-sec is to specify how long a key should exist, I don't see any further need to make the "random window" be specifically configurable .. The reneg-sec period will remain as specified (def 3600) except for the first run, where --reneg-sec is started from a random time between now and then. There after returning to "normal" with full randomisation of all connected clients --reneg-sec being spread over the *entire* period of --reneg-sec nn and not some unnecessary window.

Hi,

Quoted 7 lines · On Wed, Apr 05, 2017 at 07:00:54PM +0100, debbie10t wrote:

Quoted 6 lines

Optional option does not mean that it is disabled by default. If you don't the randomness you would need to do:

reneg-sec 3600 3600

the optional argument also allows it to fine tune it to your needs.

Quoted 7 lines

As the reason for --reneg-sec is to specify how long a key should exist, I don't see any further need to make the "random window" be specifically configurable .. The reneg-sec period will remain as specified (def 3600) except for the first run, where --reneg-sec is started from a random time between now and then. There after returning to "normal" with full randomisation of all connected clients --reneg-sec being spread over the *entire* period of --reneg-sec nn and not some unnecessary window.

Setups with 2FA will have to re-enter auth credentials on reneg. Having OpenVPN all of a sudden default to "it could be asking 5 minutes after connection for the credentials again" is massive annoyance - and brings no real benefit anyway.

It makes sense to jitter reneg-sec somewhat (like, 10%-ish), but changing behaviour too much is not bringing much benefit - you don't need to spread the reneg over the whole period anyway, as different clients connect and disconnect at different times anyway. Just if all of them connect at the same time, the identically-timed renegs are a problem.

I like Arne's and David's suggestion - the existing option "as is" will enable X% jitter, while a second parameter can specify a more specific range. Following Arne's argument about users and percent math, it might indeed be better to have "min max" here ("3500 3600"), because that is really easy to understand and explain.

Following Arne's argument about users and percent math, it might indeed be better to have "min max" here ("3500 3600"), because that is really easy to understand and explain.

I don't believe there is any need to specify "max" because that would be --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec

Quoted 2 lines

I don't believe there is any need to specify "max" because that would be --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec

I think you, probably without being aware of it, are agreeing to what the current proposal is:

--reneg-sec max
A renegotiation happens within 'max' seconds, but with a 10%-ish randomness

--reneg-sec min max
A renegotiation happens within 'min' and 'max' seconds, fully controllable

So using --reneg-sec 3600 3600, effectively removes the randomness.

--
kind regards,

David Sommerseth
OpenVPN Technologies, Inc

------------------------------------------------------------
------------------
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 [email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Quoted 2 lines · On 05/04/17 23:13, debbie10t wrote:

I don't believe there is any need to specify "max" because that would be --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec

I think you, probably without being aware of it, are agreeing to what the current proposal is:

--reneg-sec max
A renegotiation happens within 'max' seconds, but with a 10%-ish randomness

--reneg-sec min max
A renegotiation happens within 'min' and 'max' seconds, fully controllable

So using --reneg-sec 3600 3600, effectively removes the randomness.

Hi,

Quoted 15 lines · David Sommerseth

Quoted 2 lines · On 05/04/17 23:13, debbie10t wrote:

I don't believe there is any need to specify "max" because that would be --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec

I think you, probably without being aware of it, are agreeing to what the current proposal is:

--reneg-sec max
A renegotiation happens within 'max' seconds, but with a 10%-ish randomness

--reneg-sec min max
A renegotiation happens within 'min' and 'max' seconds, fully controllable

Quoted 1 line

So using --reneg-sec 3600 3600, effectively removes the randomness.

I understand the proposed methods ..

Of the two above, I would be inclined toward option 2.
eg: (for me) --reneg-sec 0 3600 is ideal.

Thanks :)

Quoted 21 lines · On 05/04/17 22:57, debbie10t wrote:

Hi,

Quoted 17 lines · David Sommerseth

Quoted 3 lines · On 05/04/17 23:13, debbie10t wrote:

I don't believe there is any need to specify "max" because that would be
--reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec

I think you, probably without being aware of it, are agreeing to what the current proposal is:

--reneg-sec max
A renegotiation happens within 'max' seconds, but with a 10%-ish randomness

--reneg-sec min max
A renegotiation happens within 'min' and 'max' seconds, fully controllable

So using --reneg-sec 3600 3600, effectively removes the randomness.

Quoted 6 lines

I understand the proposed methods ..

Of the two above, I would be inclined toward option 2.
eg: (for me) --reneg-sec 0 3600 is ideal.

Thanks :)

With the proviso of "First-run only" ..

hello!

just curious how renegotiation is handled in "https" ? is it "an abbrevated ssl handshake" (RFC 2246) or ... ?

2017-04-06 2:39 GMT+05:00 David Sommerseth
<[email protected]...
<mailto:[email protected]...>>:

On 05/04/17 23:13, debbie10t wrote:
> I don't believe there is any need to specify "max" because that would be > --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec

I think you, probably without being aware of it, are agreeing to what the current proposal is:

--reneg-sec max
A renegotiation happens within 'max' seconds, but with a 10%-ish randomness

--reneg-sec min max
A renegotiation happens within 'min' and 'max' seconds, fully controllable

So using --reneg-sec 3600 3600, effectively removes the randomness.

--
kind regards,

David Sommerseth
OpenVPN Technologies, Inc

Hi,

Quoted 15 lines · David Sommerseth

Quoted 2 lines · On 05/04/17 23:13, debbie10t wrote:

I don't believe there is any need to specify "max" because that would be --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec

I think you, probably without being aware of it, are agreeing to what the current proposal is:

--reneg-sec max
A renegotiation happens within 'max' seconds, but with a 10%-ish randomness

--reneg-sec min max
A renegotiation happens within 'min' and 'max' seconds, fully controllable

Quoted 1 line

So using --reneg-sec 3600 3600, effectively removes the randomness.

I understand the proposed methods ..

Of the two above, I would be inclined toward option 2.
eg: (for me) --reneg-sec 0 3600 is ideal.

One final clarification:

As a user, I would prefer to see an early 2fa re-connect than one in the final few minutes, especially if I am already accustomed to a one hour cut off. Such that, I do 45 mins of work and get cut off is more annoying then doing 15 mins and get cut off.

Quoted 4 lines

hello!

just curious how renegotiation is handled in "https" ? is it "an abbrevated ssl handshake" (RFC 2246) or ... ?

The HTTPS and OpenVPN protocol is not comparable in this regard at all. AFAIR, OpenVPN does not make use of the TLS renegotiation possibility at all. So a renegotiation in OpenVPN actually results in a completely new and fresh TLS session, not related to previous TLS sessions at all.

--
kind regards,

David Sommerseth
OpenVPN Technologies, Inc

Quoted 6 lines

2017-04-06 2:39 GMT+05:00 David Sommerseth
<[email protected]...
<mailto:[email protected]...>>:

On 05/04/17 23:13, debbie10t wrote:
> I don't believe there is any need to specify "max" because that

would be

Quoted 1 line

Quoted 1 line

--reneg-sec as is. Otherwise specify a smaller or larger

--reneg-sec

Quoted 20 lines

I think you, probably without being aware of it, are agreeing to what the current proposal is:

--reneg-sec max
A renegotiation happens within 'max' seconds, but with a 10%-ish randomness

--reneg-sec min max
A renegotiation happens within 'min' and 'max' seconds, fully controllable

So using --reneg-sec 3600 3600, effectively removes the randomness.

--
kind regards,

David Sommerseth
OpenVPN Technologies, Inc

Hi,

Quoted 7 lines · On Wed, Apr 05, 2017 at 07:00:54PM +0100, debbie10t wrote:

Quoted 6 lines

Optional option does not mean that it is disabled by default. If you don't the randomness you would need to do:

reneg-sec 3600 3600

the optional argument also allows it to fine tune it to your needs.

Quoted 7 lines

As the reason for --reneg-sec is to specify how long a key should exist, I don't see any further need to make the "random window" be specifically configurable .. The reneg-sec period will remain as specified (def 3600) except for the first run, where --reneg-sec is started from a random time between now and then. There after returning to "normal" with full randomisation of all connected clients --reneg-sec being spread over the *entire* period of --reneg-sec nn and not some unnecessary window.

Setups with 2FA will have to re-enter auth credentials on reneg. Having OpenVPN all of a sudden default to "it could be asking 5 minutes after connection for the credentials again" is massive annoyance - and brings no real benefit anyway.

It makes sense to jitter reneg-sec somewhat (like, 10%-ish), but changing behaviour too much is not bringing much benefit - you don't need to spread the reneg over the whole period anyway, as different clients connect and disconnect at different times anyway. Just if all of them connect at the same time, the identically-timed renegs are a problem.

I like Arne's and David's suggestion - the existing option "as is" will enable X% jitter, while a second parameter can specify a more specific range. Following Arne's argument about users and percent math, it might indeed be better to have "min max" here ("3500 3600"), because that is really easy to understand and explain.

2017-04-06 3:26 GMT+05:00 David Sommerseth
<[email protected]...
<mailto:[email protected]...>>:

On 05/04/17 23:43, Илья Шипицин wrote:
> hello!
>
> just curious how renegotiation is handled in "https" ? > is it "an abbrevated ssl handshake" (RFC 2246) or ... ?

The HTTPS and OpenVPN protocol is not comparable in this regard at all. AFAIR, OpenVPN does not make use of the TLS renegotiation possibility at all. So a renegotiation in OpenVPN actually results in a completely new and fresh TLS session, not related to previous TLS sessions at all.

both HTTPS and OpenVPN are

1) client-->server
2) long running
3) SSL based

they are similar from many point of view

as, renegotiation does occur for https, and we do not observe "hourly" CPU peaks, I think it worth not reinventing the wheel here

Quoted 6 lines

I like Arne's and David's suggestion - the existing option "as is" will enable X% jitter, while a second parameter can specify a more specific range. Following Arne's argument about users and percent math, it might indeed be better to have "min max" here ("3500 3600"), because that is really easy to understand and explain.

After all the discussion I prefer the simple solution. I've changed my systems to the reduced 10% jitter and I'm wondering if it has to be made more complicated than this? I works very well and after some hours the renegs have spread very well. If you ask me it's perfectly fine that way as long as the docs clearly state that a pseudo random 10% us deducted from reneg-sec automatically to spread renegs.

With the 1 hour default, not setting --reneg-sec gives a time window of 6 minutes with 10%. That is a reasonable default unless explicitly overridden by either --reneg-sec 3600 (no randomness) or --reneg-sec 3000 4000 (with a 1000 seconds large time window)

Quoted 7 lines · Simon Matter

Quoted 6 lines

I like Arne's and David's suggestion - the existing option "as is" will enable X% jitter, while a second parameter can specify a more specific range. Following Arne's argument about users and percent math, it might indeed be better to have "min max" here ("3500 3600"), because that is really easy to understand and explain.

Quoted 6 lines

After all the discussion I prefer the simple solution. I've changed my systems to the reduced 10% jitter and I'm wondering if it has to be made more complicated than this? I works very well and after some hours the renegs have spread very well. If you ask me it's perfectly fine that way as long as the docs clearly state that a pseudo random 10% us deducted from reneg-sec automatically to spread renegs.

It must be configurable, based on many years experience with helping out on configuring OpenVPN tunnels. There are millions of OpenVPN configurations out in the world (and I don't even think I'm exaggerating that much even), many small ones and quite some large ones. There are VPN service providers with several hundred thousands paying customers, and there are an enormous amount of VPN service providers in addition. In addition to all the private and corporate deployments.

So enforcing a good feature equally on all these configurations will backfire at us.

And the more I think about the 10% randomness vlaue (or any percentage), I really wonder how clever that is. If a site uses --reneg-sec 1800 (I have seen that), that means a 3 minute window. If a site uses 14400 (4 hours, I've seen that too), that gives a 24 minute window. These window sizes may be perfectly fine. But depending on the amount of connected users, this may be troublesome too.

Last night I chatted with krzee on #openvpn-devel about this. He does quite some cool stuff with OpenVPN and have lots of IP phones connecting to VPN servers. He said that randomness by default may not be ideal for
some of the setups he manages. But he loves the idea behind this
feature.

Krzee argued that configurations explicitly setting --reneg-sec 3600 should not have any randomness. If a configuration does _not* set --reneg-sec, it may have randomness with 1 hour as the base. And those wanting better control of the time window should use:
--reneg-sec min max

I initially was of the opinion --reneg-sec 3600 should have randomness (the 10-17% base). But after having slept on it, I think Krzee have a good point. Setting --reneg-sec explicitly with only a single value should not have any randomness.

With the 1 hour default, not setting --reneg-sec gives a time window of 6 minutes with 10%. That is a reasonable default unless explicitly overridden by either --reneg-sec 3600 (no randomness) or --reneg-sec 3000 4000 (with a 1000 seconds large time window)

Hi,

Quoted 50 lines · David Sommerseth

Quoted 7 lines · Simon Matter

Quoted 6 lines

I like Arne's and David's suggestion - the existing option "as is" will enable X% jitter, while a second parameter can specify a more specific range. Following Arne's argument about users and percent math, it might indeed be better to have "min max" here ("3500 3600"), because that is really easy to understand and explain.

Quoted 6 lines

After all the discussion I prefer the simple solution. I've changed my systems to the reduced 10% jitter and I'm wondering if it has to be made more complicated than this? I works very well and after some hours the renegs have spread very well. If you ask me it's perfectly fine that way as long as the docs clearly state that a pseudo random 10% us deducted from reneg-sec automatically to spread renegs.

It must be configurable, based on many years experience with helping out on configuring OpenVPN tunnels. There are millions of OpenVPN configurations out in the world (and I don't even think I'm exaggerating that much even), many small ones and quite some large ones. There are VPN service providers with several hundred thousands paying customers, and there are an enormous amount of VPN service providers in addition. In addition to all the private and corporate deployments.

So enforcing a good feature equally on all these configurations will backfire at us.

And the more I think about the 10% randomness vlaue (or any percentage), I really wonder how clever that is. If a site uses --reneg-sec 1800 (I have seen that), that means a 3 minute window. If a site uses 14400 (4 hours, I've seen that too), that gives a 24 minute window. These window sizes may be perfectly fine. But depending on the amount of connected users, this may be troublesome too.

Last night I chatted with krzee on #openvpn-devel about this. He does quite some cool stuff with OpenVPN and have lots of IP phones connecting to VPN servers. He said that randomness by default may not be ideal for
some of the setups he manages. But he loves the idea behind this
feature.

Krzee argued that configurations explicitly setting --reneg-sec 3600 should not have any randomness. If a configuration does _not* set --reneg-sec, it may have randomness with 1 hour as the base. And those wanting better control of the time window should use:
--reneg-sec min max

I initially was of the opinion --reneg-sec 3600 should have randomness (the 10-17% base). But after having slept on it, I think Krzee have a good point. Setting --reneg-sec explicitly with only a single value should not have any randomness.

Quoted 4 lines

With the 1 hour default, not setting --reneg-sec gives a time window of 6 minutes with 10%. That is a reasonable default unless explicitly overridden by either --reneg-sec 3600 (no randomness) or --reneg-sec 3000 4000 (with a 1000 seconds large time window)

Wow, this discussion suddenly caught some attention! I'll chip in too.

I was fine with not making this configurable, but the discussion convinced me that people really want to be able to configure this, so I agree we should.

As for the option, I think Arne's proposal is the best:
--reneg-sec max [min]
where <nothing> == --reneg-sec 3600 == --reneg-sec 3600 3240 (assuming 10% default randomization)

Why? Because this
1) doesn't change the meaning of the first argument based on whether the second is present. That's just confusing.
2) does by default what we expect is best for most users: randomize the reneg-sec value
3) still allows administrators to disable randomization
4) 'max' and 'min' are hard to misinterpret ('window', 'jitter' or 'offset' are much easier to misinterpret)

As for 'first time only' or 'always': go for always.

That will slowly
spread out the clients over the entire reneg-sec window, instead of over just xx% of the window. The odds that 'all periods line up' that

As you can see, the current proposal does not allow for first random, followed by expected/normal/regular renegs. It is either *always* random or *never* random .. I believe this is a poor decision.

As you can see, the current proposal does not allow for first random, followed by expected/normal/regular renegs. It is either *always* random or *never* random .. I believe this is a poor decision.

Web servers these days are also multi-threaded (or "multi-forked"), so they can utilize multiple cores more efficiently. OpenVPN is *single threaded*. So when one client starts a TLS renegotiation, it blocks all the other connected clients until the renegotiation have completed. When you then have 100 connected clients spending 1-2 seconds on each renegotiation happening at the same time, you will have 100-200 seconds of slow and lagging VPN tunnel. This does not mean that you will see a CPU spike, as each client is handled serialized (one by one) - not in parallel.

Hi,

Quoted 3 lines · On Thu, Apr 06, 2017 at 01:49:04PM +0100, debbie10t wrote:

As you can see, the current proposal does not allow for first random, followed by expected/normal/regular renegs. It is either *always* random or *never* random .. I believe this is a poor decision.

Your voice has been heard, and nobody else of the core team has been convinced. It is not necessary to repeat that more often.

Quoted 73 lines

Hi,

Quoted 62 lines · David Sommerseth

Quoted 11 lines · Simon Matter

Quoted 10 lines

I like Arne's and David's suggestion - the existing option "as is" will
enable X% jitter, while a second parameter can specify a more specific
range. Following Arne's argument about users and percent math, it might
indeed be better to have "min max" here ("3500 3600"), because that is
really easy to understand and explain.

Quoted 8 lines

After all the discussion I prefer the simple solution. I've changed my systems to the reduced 10% jitter and I'm wondering if it has to be made
more complicated than this? I works very well and after some hours the renegs have spread very well. If you ask me it's perfectly fine that way
as long as the docs clearly state that a pseudo random 10% us deducted from reneg-sec automatically to spread renegs.

It must be configurable, based on many years experience with helping out
on configuring OpenVPN tunnels. There are millions of OpenVPN configurations out in the world (and I don't even think I'm exaggerating
that much even), many small ones and quite some large ones. There are VPN service providers with several hundred thousands paying customers, and there are an enormous amount of VPN service providers in addition. In addition to all the private and corporate deployments.

So enforcing a good feature equally on all these configurations will backfire at us.

And the more I think about the 10% randomness vlaue (or any percentage),
I really wonder how clever that is. If a site uses --reneg-sec 1800 (I have seen that), that means a 3 minute window. If a site uses 14400 (4 hours, I've seen that too), that gives a 24 minute window. These window
sizes may be perfectly fine. But depending on the amount of connected users, this may be troublesome too.

Last night I chatted with krzee on #openvpn-devel about this. He does quite some cool stuff with OpenVPN and have lots of IP phones connecting
to VPN servers. He said that randomness by default may not be ideal for
some of the setups he manages. But he loves the idea behind this
feature.

Krzee argued that configurations explicitly setting --reneg-sec 3600 should not have any randomness. If a configuration does _not* set --reneg-sec, it may have randomness with 1 hour as the base. And those wanting better control of the time window should use:
--reneg-sec min max

I initially was of the opinion --reneg-sec 3600 should have randomness (the 10-17% base). But after having slept on it, I think Krzee have a good point. Setting --reneg-sec explicitly with only a single value should not have any randomness.

Quoted 4 lines

With the 1 hour default, not setting --reneg-sec gives a time window of 6 minutes with 10%. That is a reasonable default unless explicitly overridden by either --reneg-sec 3600 (no randomness) or --reneg-sec 3000 4000 (with a 1000 seconds large time window)

Wow, this discussion suddenly caught some attention! I'll chip in too.

Quoted 8 lines

I was fine with not making this configurable, but the discussion convinced me that people really want to be able to configure this, so I agree we should.

As for the option, I think Arne's proposal is the best:
--reneg-sec max [min]
where <nothing> == --reneg-sec 3600 == --reneg-sec 3600 3240 (assuming 10% default randomization)

The Initial proposal was --reneg-sec [min] max (horrible)

Quoted 10 lines

Why? Because this
1) doesn't change the meaning of the first argument based on whether the second is present. That's just confusing.
2) does by default what we expect is best for most users: randomize the reneg-sec value
3) still allows administrators to disable randomization
4) 'max' and 'min' are hard to misinterpret ('window', 'jitter' or 'offset' are much easier to misinterpret)

Quoted 1 line

As for 'first time only' or 'always': go for always.

If it is set to always, you are permanently changing the function of --reneg-sec to always use random *or* no random at all, which the user cannot modify. This randomise is only required for the first period and subsequent periods should return to normal.

Company A has 1,000 vpn users and (for what ever reason) they reboot the server every 24 hours. They experience the slow down because all their vpn users are permanently connected. They all connect at once. This patch is not trying to address the initial connect it is trying to address the subsequent reneg's all happening at once.

Quoted 5 lines · On 06/04/17 15:37, debbie10t wrote:

Company A has 1,000 vpn users and (for what ever reason) they reboot the server every 24 hours. They experience the slow down because all their vpn users are permanently connected. They all connect at once. This patch is not trying to address the initial connect it is trying to address the subsequent reneg's all happening at once.

This is not what --reneg-sec is about. --reneg-sec does not control the initial connection. What you want here is a randomized initial connection delay when client have lost connection to the openvpn server and needs to do a reCONNECT.

That is an entirely different feature than reNEGOTIATION of established tunnels (which --reneg-sec targets). However, randomizing --reneg-sec will improve the situation *after* the initial connect congestion, once the first renegotiation round starts. At this point in time, things will start to spread out.

But I emphasize again, --reneg-sec have never tried to solve randomizing of the _initial_ connect step.

Quoted 2 lines

This patch is not trying to address the initial connect it is trying to address the subsequent reneg's all happening at once.

From: Simon Matter <[email protected]...>

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 <[email protected]...>

Signed-off-by Steffan Karger <[email protected]...>

---
v3: incorporate comments from openvpn-devel@, don't add jitter by
default on the client side.

 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(-)

doc/openvpn.8 +20 -5

index a4189ac2..eb5258f9 100644
@@ -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

doc/openvpn.8 +1 -0

+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.

src/openvpn/init.c +6 -1

index 1ed2c55e..0b64930e 100644
@@ -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 the reneg-sec of each connection by default
 */
+        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;

src/openvpn/init.c +4 -0

+    }
+    else
+    {
+        /* Add user-specific jitter to the renge-sec of each connection

*/

src/openvpn/init.c +3 -0

+        to.renegotiate_seconds = options->renegotiate_seconds -
+                (get_random() % max_int(options->renegotiate_seconds
+                                        -

options->renegotiate_seconds_min, 1));

src/openvpn/init.c +1 -0

+    }
     to.single_session = options->single_session;
     to.mode = options->mode;
     to.pull = options->pull;

src/openvpn/options.c +0 -0

index 641a26e2..7fe22064 100644
@@ -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"
"--reneg-pkts n : Renegotiate data chan. key after n packets sent
and recvd.\n"
- "--reneg-sec n : Renegotiate data chan. key after n seconds
(default=%d).\n"
+ "--reneg-sec max [min] : Renegotiate data chan. key after at most max
(default=%d)\n"
+ " and at least min (defaults to 90%% of max on
servers and equal\n"
+ " to max on clients).\n"
"--hand-window n : Data channel key exchange must finalize within n
seconds\n"
" of handshake initiation by any peer
(default=%d).\n"
"--tran-window n : Transition window -- old key can live this many
seconds\n"

src/openvpn/options.c +6 -1

@@ -870,6 +872,7 @@ init_options(struct options *o, const bool init_gc)
     o->tls_timeout = 2;
     o->renegotiate_bytes = -1;
     o->renegotiate_seconds = 3600;
+    o->renegotiate_seconds_min = -1;
     o->handshake_window = 60;
     o->transition_window = 3600;
     o->ecdh_curve = NULL;

@@ -7999,10 +8002,14 @@ add_option(struct options *options,
         VERIFY_PERMISSION(OPT_P_TLS_PARMS);
         options->renegotiate_packets = positive_atoi(p[1]);
     }
-    else if (streq(p[0], "reneg-sec") && p[1] && !p[2])
+    else if (streq(p[0], "reneg-sec") && p[1] && !p[3])
     {
         VERIFY_PERMISSION(OPT_P_TLS_PARMS);
         options->renegotiate_seconds = positive_atoi(p[1]);
+        if (p[2])
+        {
+            options->renegotiate_seconds_min = positive_atoi(p[2]);
+        }
     }
     else if (streq(p[0], "hand-window") && p[1] && !p[2])
     {

src/openvpn/options.h +1 -0

index 496c1143..a74dc94d 100644
@@ -548,6 +548,7 @@ struct options
     int renegotiate_bytes;
     int renegotiate_packets;
     int renegotiate_seconds;
+    int renegotiate_seconds_min;
 
     /* Data channel key handshake must finalize
      * within n seconds of handshake initiation. */

src/openvpn/ssl.c +1 -3

index cb94229a..174f13cb 100644
@@ -2732,9 +2732,9 @@ tls_process(struct tls_multi *multi,
                 && ks->n_packets >= session->opt->renegotiate_packets)
             ||
 (packet_id_close_to_wrapping(&ks->crypto_options.packet_id.send))))
     {
-        msg(D_TLS_DEBUG_LOW,
-            "TLS: soft reset sec=%d bytes=" counter_format "/%d pkts="
 counter_format "/%d",
-            (int)(ks->established + session->opt->renegotiate_seconds -
 now),
+        msg(D_TLS_DEBUG_LOW, "TLS: soft reset sec=%lld/%d bytes="

counter_format

src/openvpn/ssl.c +2 -1

+            "/%d pkts=" counter_format "/%d",
+            (now - ks->established), session->opt->renegotiate_seconds,
             ks->n_bytes, session->opt->renegotiate_bytes,
             ks->n_packets, session->opt->renegotiate_packets);
         key_state_soft_reset(session);
--

2.14.1

From: Simon Matter <[email protected]...>

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 <[email protected]...>

Signed-off-by Steffan Karger <[email protected]...>

---
v3: incorporate comments from openvpn-devel@, don't add jitter by
default on the client side.

 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(-)

doc/openvpn.8 +20 -5

index a4189ac2..eb5258f9 100644
@@ -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

doc/openvpn.8 +1 -0

+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.

src/openvpn/init.c +6 -1

index 1ed2c55e..0b64930e 100644
@@ -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 the reneg-sec of each connection by default
 */
+        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;

src/openvpn/init.c +4 -0

+    }
+    else
+    {
+        /* Add user-specific jitter to the renge-sec of each connection

*/

src/openvpn/init.c +3 -0

+        to.renegotiate_seconds = options->renegotiate_seconds -
+                (get_random() % max_int(options->renegotiate_seconds
+                                        -

options->renegotiate_seconds_min, 1));

src/openvpn/init.c +1 -0

+    }
     to.single_session = options->single_session;
     to.mode = options->mode;
     to.pull = options->pull;

src/openvpn/options.c +0 -0

index 641a26e2..7fe22064 100644
@@ -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"
"--reneg-pkts n : Renegotiate data chan. key after n packets sent
and recvd.\n"
- "--reneg-sec n : Renegotiate data chan. key after n seconds
(default=%d).\n"
+ "--reneg-sec max [min] : Renegotiate data chan. key after at most max
(default=%d)\n"
+ " and at least min (defaults to 90%% of max on
servers and equal\n"
+ " to max on clients).\n"
"--hand-window n : Data channel key exchange must finalize within n
seconds\n"
" of handshake initiation by any peer
(default=%d).\n"
"--tran-window n : Transition window -- old key can live this many
seconds\n"

src/openvpn/options.c +6 -1

@@ -870,6 +872,7 @@ init_options(struct options *o, const bool init_gc)
     o->tls_timeout = 2;
     o->renegotiate_bytes = -1;
     o->renegotiate_seconds = 3600;
+    o->renegotiate_seconds_min = -1;
     o->handshake_window = 60;
     o->transition_window = 3600;
     o->ecdh_curve = NULL;

@@ -7999,10 +8002,14 @@ add_option(struct options *options,
         VERIFY_PERMISSION(OPT_P_TLS_PARMS);
         options->renegotiate_packets = positive_atoi(p[1]);
     }
-    else if (streq(p[0], "reneg-sec") && p[1] && !p[2])
+    else if (streq(p[0], "reneg-sec") && p[1] && !p[3])
     {
         VERIFY_PERMISSION(OPT_P_TLS_PARMS);
         options->renegotiate_seconds = positive_atoi(p[1]);
+        if (p[2])
+        {
+            options->renegotiate_seconds_min = positive_atoi(p[2]);
+        }
     }
     else if (streq(p[0], "hand-window") && p[1] && !p[2])
     {

src/openvpn/options.h +1 -0

index 496c1143..a74dc94d 100644
@@ -548,6 +548,7 @@ struct options
     int renegotiate_bytes;
     int renegotiate_packets;
     int renegotiate_seconds;
+    int renegotiate_seconds_min;
 
     /* Data channel key handshake must finalize
      * within n seconds of handshake initiation. */

src/openvpn/ssl.c +1 -3

index cb94229a..174f13cb 100644
@@ -2732,9 +2732,9 @@ tls_process(struct tls_multi *multi,
                 && ks->n_packets >= session->opt->renegotiate_packets)
             ||
 (packet_id_close_to_wrapping(&ks->crypto_options.packet_id.send))))
     {
-        msg(D_TLS_DEBUG_LOW,
-            "TLS: soft reset sec=%d bytes=" counter_format "/%d pkts="
 counter_format "/%d",
-            (int)(ks->established + session->opt->renegotiate_seconds -
 now),
+        msg(D_TLS_DEBUG_LOW, "TLS: soft reset sec=%lld/%d bytes="

counter_format

src/openvpn/ssl.c +2 -1

+            "/%d pkts=" counter_format "/%d",
+            (now - ks->established), session->opt->renegotiate_seconds,
             ks->n_bytes, session->opt->renegotiate_bytes,
             ks->n_packets, session->opt->renegotiate_packets);
         key_state_soft_reset(session);
--

2.14.1

Hi Steffan,

While running your v3 version of the patch I found an issue with the modified logging. It gives the following error while building

gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../include

(quoted diff) +0 -4

-I../../src/compat       -DPLUGIN_LIBDIR=\"/usr/lib64/openvpn/plugins\"
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic -std=c99 -c -o ssl.o ssl.c

ssl.c: In function 'tls_process':
ssl.c:2735:9: warning: format '%lld' expects argument of type 'long long int', but argument 3 has type 'time_t' [-Wformat=]
msg(D_TLS_DEBUG_LOW, "TLS: soft reset sec=%lld/%d bytes="
counter_format

         ^

and the log output is also corrupted

TLS: soft reset sec=14774687501680/336605974 bytes=18446744069414584320/581335 pkts=0/0
TLS: soft reset sec=14787572403571/77375 bytes=18446744069414584320/885 pkts=0/-1080308296
TLS: soft reset sec=14164802145506/6746662 bytes=18446744069414584320/86778 pkts=0/0
TLS: soft reset sec=15264313773538/186529 bytes=18446744069414584320/1108 pkts=0/13935244

Please have a look at the attached v4 patch which fixes it for me. The output is now

TLS: soft reset sec=3474/3474 bytes=8470454/-1 pkts=108673/0
TLS: soft reset sec=3489/3489 bytes=429623769/-1 pkts=656033/0
TLS: soft reset sec=3517/3517 bytes=89365/-1 pkts=877/0
TLS: soft reset sec=3537/3537 bytes=206142/-1 pkts=1123/0

which seems reasonable to me.
In the patch I've modified the lines below:

msg(D_TLS_DEBUG_LOW,
- "TLS: soft reset sec=%d bytes=" counter_format "/%d pkts="
counter_format "/%d",
- (int)(ks->established + session->opt->renegotiate_seconds -
now),
+ "TLS: soft reset sec=%d/%d bytes=" counter_format "/%d pkts="
counter_format "/%d",
+ (int)(now - ks->established), session->opt->renegotiate_seconds,

             ks->n_bytes, session->opt->renegotiate_bytes,

I'm not a developer and not a git user, so please accept my hand crafted patch work :-)

From: Simon Matter <[email protected]...>

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 <[email protected]...>

Signed-off-by Steffan Karger <[email protected]...>

---
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