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: >>> 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>
--
kind regards,
David Sommerseth
OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital 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
