Hi all, i think the whole problem can be solved if an update to OpenVPN version 2.3.13 has been done since the sweet32 problem should there be fixed cause they used in there also the 64 MB limitation in reneg-sec --> https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23 . Tried to download the new version to go for a checkout but it seems that the sources are currently not available (Not found 404).
Have wrote also a hint into bugzilla --> https://bugzilla.ipfire.org/show_bug.cgi?id=11186 .
As a beneath info, OpenVPN-2.4_alpha2 is out now which was available. Have build it for IPfire and am currently in testing mode and it looks pretty good. I brought the results up to the forum and asked for more testing people, so if someone is interested in that topic, you can find it in here --> https://forum.ipfire.org/viewtopic.php?f=50&p=102654&sid=bef338860ce... .
Erik
Am 16.09.2016 um 11:55 schrieb ummeegge ummeegge@ipfire.org:
Hi, since i´ am currently on a journey and have no access to my development environment to send some patches via Patchday, i have left a first idea in Bugzilla --> https://bugzilla.ipfire.org/show_bug.cgi?id=11186 . It might be great if someone can go through it to give some response.
Am 15.09.2016 um 13:13 schrieb Michael Tremer michael.tremer@ipfire.org:
Hi,
On Thu, 2016-09-15 at 12:23 +0200, ummeegge wrote:
Hi all, what are you thinking then to arrange the optgroup (thanks Michael for pointing this formatting possibility out) with the following assignments and in e.g. 3 different sections named for example
We had a similar discussion over here if it was a good idea to mark something as "strong" over here:
http://lists.ipfire.org/pipermail/development/2015-December/001236.html
Yes i remember also this discussion, but i think we have had also some others :-).
What if something suddenly becomes "weak"?
An idea can be to keep this list up-to-date by resorting possible new weak candidates as good as it is possible with all in the future released informations. The air in the cipher world becomes a little thin these days. There is currently only AES and Camellia left which supports 192 and 256 bit key lengths. The Seed cipher operates also with 128 bit blocks but uses in max. only 128 bit key lengths. All other currently available ciphers in OpenVPN on IPFire uses 64 bit blocks as far as i can see, thats also the reason why i have added the Seed cipher in the "Medium cipher" section above some other 64 bit block ciphers which uses 192 bit key lengths, so the cipher list order has also been change in that manner.
But generally I think this is better than what we have now.
Ciphers:
Strong algorithms
With 256 bit (keylenght) <--> 128 Bit block ciphers With 192 bit (keylenght) <--> "
Medium algorithms
With 128 bit (keylenght) <--> 128 bit block ciphers
Weak algorithms
With 192 bit (keylenght) <--> 64 bit block ciphers With 128 bit (keylenght) <--> 64 bit block ciphers
HMACs:
Strong algorithms
512 bit Whirlpool, SHA2 384 bit SHA2
Medium algorithms
256 bit SHA2
Weak algorithms
160 bit SHA1 and md5
Diffie-Hellman parameter:
Strong algorithms
4096, 3072
Medium algorithms
2048
Weak algorithm
1024
May too much but as an first idea for the naming and structure of the optgroups in OpenVPN.
Let's start with that one then and do IPsec later.
O.K. have started with this. If these patches are ok and i´am back home, i can send them via Patchday. ,
Causing the defaults for the HMAC: SHA1 is really no good choice in OpenVPN but in the time when we´ve added the the selection of the auth algorithm, a lot of configurations have used already 'auth SHA1' in their configs so the problems comes up if the server configuration will be stored again via the WUI or new clients are generated with new parameters all existing clients with the old defaults (SHA1 in that case) won´t work anymore until they have been changed appropriately.
Changing the default to SHA256 has some implications that may cause major difficulties later. See my other email for this.
I see there also some major difficulties cause, as you mentioned it, connections which do not use a new default value needs to change them accordingly on every client configuration since the server do not push these kind of settings.
The Diffie-Hellman parameter needs, on weak boards or boards with less entropy a lot of time so an security/usability question comes up again.
OpenVPN delivers also the possibility for 'reneg-sec' or 'reneg-bytes' but this needs to be configured as far as i remember on both sides (client/server) and may too much/complicated to configure over the WUI, even if 2.4.x delivers it per default ?
Can we assume that we have a reasonably recent version on the clients?
Good question, possibly the smartphone segment needs longer for that, there are nowadays a lot of "Unused options" findable in different smartphone logs but i´am not really sure about the time difference between the 2.4.x release and a reasonable take over of the new functions into the different client software and platforms but this point should be considered for the hope of a software side solution of the sweet32 birthday problem.
Michael, did you have had a look into the new OpenSSL-1.1.0 update ? What are you thinking about that, cause OpenSSL wrote in their announcement that DES and all variations of it will only be available if the "enable-weak-ssl-ciphers” are set in the compile options, which means if IPFire won´t use this option (if the new OpenSSL will be integrated, seems to be a little messy) the discussed ciphers won´t be anyways available anymore.
Greetings,
Erik