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

[Simon Matter]

>> Hi,
>>
>> On Tue, Apr 04, 2017 at 08:29:49AM +0200, Simon Matter wrote:
>>> 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:

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


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

Thanks,
Simon

openvpn-2.4.1-reneg-sec_randomize.patch
Description: Binary data
--
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] Upgrading EasyRSA 2's defaults

[Selva Nair]

Hi,

On Tue, Apr 4, 2017 at 3:48 AM, Steffan Karger  wrote:

> From the openssl man page:
>
> "Beware that with such DSA-style DH parameters, a fresh DH key should
> be created for each use to avoid small-subgroup attacks that may be
> possible otherwise."
>
> This means that if for some reason a non-ephemeral diffie-hellman
> cipher suite is selected, you are at risk of these attacks.
>

Thanks for the clarification.

Selva
--
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] Add per session pseudo-random component to --reneg-sec intervals

[debbie10t]

On 04/04/17 08:30, Simon Matter wrote:
>> Hi,
>>
>> On Tue, Apr 04, 2017 at 08:29:49AM +0200, Simon Matter wrote:
>>> 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 :)

As a non-dev I can not help with implementing this.
But for the record: I think it would be an excellent
edition to openvpn as currently per peer --reneg-*
in --mode server is not possible.

Regards

--
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] Upgrading EasyRSA 2's defaults

[Jan Just Keijser]

Hi David,

On 03/04/17 22:43, David Sommerseth wrote:

On 03/04/17 16:12, Jan Just Keijser wrote:


On 03/04/17 15:53, Samuli Seppänen wrote:

On 02/04/2017 10:57, Steffan Karger wrote:

Hi,

On 31-03-17 22:34, David Sommerseth wrote:

On 31/03/17 10:56, Илья Шипицин wrote:

2017-03-31 13:26 GMT+05:00 Samuli Seppänen >:

  Hi,

  We still bundle EasyRSA 2 with our Windows installers and it is
  prominently advertised on our widely linked to HOWTO:

  >

  As such, EasyRSA 2 is used by many/most OpenVPN server admins.

  However, the default values for EasyRSA 2 such as MD5 hashing algorithm
  and 1024-bit keysize seem totally inadequate for today's standards:

  >
  
>

  I think we should upgrade these to something more recent. What would
  more modern reasonable defaults be?



someday we decided to use DSA (instead of default RSA)
it worked ... until we started to use OpenVPN Connect for iOS.
next, we had to change back to RSA


the conclusion would be "test all available platforms and take a
decision", probably even set up special test server and ask people on
openvpn-users mailing list

Always a good idea to test as many platforms as possible.  But we can
also leverage all the testing which have been done indirectly by others
as well.

The suggestion from Samuli is to update the default key size and hashing
algorithm.  MD5 is broken.  MD5 have been broken for years.  SHA1 have
the recent SHAttering panic, which have its own set of challenges - and
should not be used for certificates any longer (if I have understood the
crypto-gurus correctly).

Also considering that the "world in general" have been moving towards
stronger keys *and* have moved towards SHA256 hashing in certificates,
updating EasyRSA is more than reasonable.

So, I would highly recommend using SHA256.  I have used that for my
OpenVPN setups for several years already.  That works fine for me, and I
know others have done the same.  This is actually the most challenging
move, from a technical point of view - using a new algorithm.  But this
algorithm is well supported by all OpenSSL and mbed TLS implementations
OpenVPN can be built against.

Secondly, updating the key length from 1024 bits to at least 2048 should
not cause any issues at all.  Many users (myself included) often use
4096 bits keys without any issues.

Swapping RSA for DSA is an issue of a completely different league. And
DSA is by OpenSSH considered too weak; IIRC it was even removed in
OpenSSH v7.0.

Yes, upgrading would be good if we still ship it.  I can echo David's
SHA256 / RSA2048+ recommendation.  Enough security margin, and very good
interop (not only crypto libs, but also smart cards, OS key stores,
...).  To not dramatically slow down connection setup on low-cpu-power
devices (e.g. home routers), don't go beyond RSA4096 though.

DSA is _not_ a preferred choice.  The original 1024-bit DSA is too weak
nowadays, and the 'larger' DSA variants are not even close to the wide
support that RSA has.

-Steffan


Hi,

I've issue a pull request here and review would be appreciated:



I tested these changes on Debian 8 which has OpenSSL-1.0.1. Key size was
set to 4096-bits and signature algorithm to SHA256WithRSAEncryption.

The only real issue was DH parameter generation: it took ~25 minutes on
my Intel i5 laptop. Is that acceptable default behavior?


what kind of i5 is this? on my i7-4810 it took 5 minutes. Can you give the full 
CPUID string (from /proc/cpuinfo) ?  then I can
guestimate whether the 25 minutes is realistic for slower hardware.

I've run a a couple of "quick" tests ... on a two different laptops

--- test 1 --
$ time openssl gendh -out test 4096
[...snip...]

real35m40.098s
user35m38.922s
sys 0m0.367s
$ cat /proc/cpuinfo  | grep model\ name | uniq -c
   4 model name  : Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz



--- test 2 --
$ time openssl gendh -out test 4096
[...snip...]

real13m59.742s
user13m59.448s
sys 0m0.140s
$ cat /proc/cpuinfo  | grep model\ name | uniq -c
   4 model name : Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz

Re: [Openvpn-devel] Upgrading EasyRSA 2's defaults

[Steffan Karger]

Hi,

On 3 April 2017 at 23:14, Selva Nair  wrote:
>
>
> On Mon, Apr 3, 2017 at 4:43 PM, David Sommerseth
>  wrote:
>>
>> On 03/04/17 16:12, Jan Just Keijser wrote:
>> > Hi Samuli,
>> >
>> > On 03/04/17 15:53, Samuli Seppänen wrote:
>> >> On 02/04/2017 10:57, Steffan Karger wrote:
>
>
> snip..
>
>>
>> >>> DSA is _not_ a preferred choice.  The original 1024-bit DSA is too
>> >>> weak
>> >>> nowadays, and the 'larger' DSA variants are not even close to the wide
>> >>> support that RSA has.
>> >>>
>> >>> -Steffan
>> >>>
>> >> Hi,
>> >>
>> >> I've issue a pull request here and review would be appreciated:
>> >>
>> >> 
>> >>
>> >> I tested these changes on Debian 8 which has OpenSSL-1.0.1. Key size
>> >> was
>> >> set to 4096-bits and signature algorithm to SHA256WithRSAEncryption.
>> >>
>> >> The only real issue was DH parameter generation: it took ~25 minutes on
>> >> my Intel i5 laptop. Is that acceptable default behavior?
>> >>
>> > what kind of i5 is this? on my i7-4810 it took 5 minutes. Can you give
>> > the full CPUID string (from /proc/cpuinfo) ?  then I can
>> > guestimate whether the 25 minutes is realistic for slower hardware.
>>
>> I've run a a couple of "quick" tests ... on a two different laptops
>>
>> --- test 1 --
>> $ time openssl gendh -out test 4096
>> [...snip...]
>>
>> real35m40.098s
>> user35m38.922s
>> sys 0m0.367s
>> $ cat /proc/cpuinfo  | grep model\ name | uniq -c
>>   4 model name  : Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
>
>
> 4096 bit "strong" prime is indeed an intensive computation.. Is using
> -dsaparam  option not secure enough?
>
> openssl dhparam -dsaparam -out test 4096
>
> is 15 seconds vs forever without it on my ancient desktop.

From the openssl man page:

"Beware that with such DSA-style DH parameters, a fresh DH key should
be created for each use to avoid small-subgroup attacks that may be
possible otherwise."

This means that if for some reason a non-ephemeral diffie-hellman
cipher suite is selected, you are at risk of these attacks.

If you are worried about the parameter generation time, just use one
of the IETF-provided parameters, e.g:
https://tools.ietf.org/html/rfc7919#appendix-A.2

But beware that using larger groups does not only slow down parameter
generation, it also slows down connection setup.  ECDH is much faster,
but if you need to use DH, do some performance tests before blindly
using 4096-bits parameters.

-Steffan

--
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] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

> Hi,
>
> On Tue, Apr 04, 2017 at 08:29:49AM +0200, Simon Matter wrote:
>> 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:

#define RENEG_RND_PCT 25

to.renegotiate_seconds = max_int((int)options->renegotiate_seconds -
(get_random() % (options->renegotiate_seconds / (100 / RENEG_RND_PCT))),
1);


With the default config this should result in reneg times in the range of
2700 ... 3600 seconds.

Thanks,
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] Add per session pseudo-random component to --reneg-sec intervals

[Gert Doering]

Hi,

On Tue, Apr 04, 2017 at 08:29:49AM +0200, Simon Matter wrote:
> Interesting to see that there is zero interest in this patch here.

This is a misinterpretation.

If you monitor the list, it has been fairly quiet since 2.4.0 release - 
the active core of openvpn developers have all been busy with other
things for one or the other reason, so progress on all fronts has been
slow, and response times could be much better.

I think this is a useful addition, but didn't have time to really think
through the code changes yet (= review), so I didn't say anything.  I know
Steffan is busy with OpenSSL 1.1 plus paid-for work, David is busy with
other important business.  So it might take a bit.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


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

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

[Simon Matter]

Hi,

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

I'm very sure a lot of people are suffering this issue without knowing it.
On heavy loaded multi instance servers OpenVPN tends to lose packets every
hour (with default reneg-sec settings).

That's only in a short period of time but still very annoying for things
like VoIP over the VPN links.

We only found this out after the problem became worse with the bug
mentioned above introduced in OpenVPN 2.4.0. The problem has always been
there but we only became aware of it with the 2.4.0 release.

I guess I'll change the patch then to work without any changes to the
config. That way our binary builds are still compatible with the upstream
version but still improve the issue mentioned above.

For those interested to see how the problem shows up, try this:

Run "prettyping -i 0.1 " to different locations in different
terminals and let it run for a longer time. You will easily see the hourly
packet losses in the patterns. Prettyping is here
https://raw.githubusercontent.com/denilsonsa/prettyping/master/prettyping

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