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 <sam...@openvpn.net
<mailto:sam...@openvpn.net>>:
Hi,
We still bundle EasyRSA 2 with our Windows installers and it is
prominently advertised on our widely linked to HOWTO:
<https://openvpn.net/index.php/open-source/documentation/howto.html
<https://openvpn.net/index.php/open-source/documentation/howto.html>>
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:
<https://github.com/OpenVPN/easy-rsa-old/blob/master/easy-rsa/2.0/vars#L53
<https://github.com/OpenVPN/easy-rsa-old/blob/master/easy-rsa/2.0/vars#L53>>
<https://github.com/OpenVPN/easy-rsa-old/blob/master/easy-rsa/2.0/openssl-1.0.0.cnf#L57
<https://github.com/OpenVPN/easy-rsa-old/blob/master/easy-rsa/2.0/openssl-1.0.0.cnf#L57>>
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:
<https://github.com/OpenVPN/easy-rsa-old/pull/1>
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...]
real 35m40.098s
user 35m38.922s
sys 0m0.367s
$ cat /proc/cpuinfo | grep model\ name | uniq -c
4 model name : Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
<http://ark.intel.com/products/88193/Intel-Core-i5-6200U-Processor-3M-Cache-up-to-2_80-GHz>
--- test 2 ----------------------------------------------------------
$ time openssl gendh -out test 4096
[...snip...]
real 13m59.742s
user 13m59.448s
sys 0m0.140s
$ cat /proc/cpuinfo | grep model\ name | uniq -c
4 model name : Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
<http://ark.intel.com/products/85215/Intel-Core-i7-5600U-Processor-4M-Cache-up-to-3_20-GHz>
--- test 3 ----------------------------------------------------------
$ time openssl gendh -out test 4096
[...snip...]
real 14m54.432s
user 14m53.475s
sys 0m0.339s
$ cat /proc/cpuinfo | grep model\ name | uniq -c
4 model name : Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz
<http://ark.intel.com/products/53401/Intel-Xeon-Processor-E3-1220L-3M-Cache-2_20-GHz>
The main difference, if I looked at the correct "Intel Ark" page for
your i7-4800 [1], is the CPU cache (yours is 6MB, while the others are
3-4MB. The i5 have max turbo freq at 2.8GHz, while the others are quite
closer (3.2-3.4 GHz, yours is at 3.8GHz).
[1]
<http://ark.intel.com/products/78937/Intel-Core-i7-4810MQ-Processor-6M-Cache-up-to-3_80-GHz>
thanks for all the numbers and I just realized that the "openssl gendh"
performance is related not only to the CPU and clock speed, but also to
the available "randomness" in the machine: If I re-run "openssl gendh"
on my laptop the numbers vary from a few minutes to ~20 minutes.
However, if I wiggle the mouse before and while the "openssl gendh" is
running then the time is shorter - the random mouse movements translate
into more randomness for the kernel. This suggests that doing *other*
stuff on your PC/laptop while "openssl gendh" is running will actually
*speed it up* - contrary to most compute-intensive operations.
Also, "openssl gendh" does not depend on the CPU's cache size - the
amount of data generated is far too low to exceed the L2 cache.
As a final note: more modern Linux kernels (4.2+ ish) have a
jitterentropy_rng.ko
<https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bb5530e4082446aac3a3d69780cd4dbfa4520013>
kernel module, which might help as well.
HTH,
JJK
------------------------------------------------------------------------------
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
