Re: OpenVPN/IPsec - Sweet32: Birthday attacks

[ummeegge <ummeegge@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 6252 bytes --]

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=bef338860cedb98a1eae3a449ef520e4#p102654 .

Erik

Am 16.09.2016 um 11:55 schrieb ummeegge <ummeegge(a)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(a)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
> 
> 
> 
> 


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 842 bytes --]