OpenVPN/IPsec - Sweet32: Birthday attacks

ummeegge ummeegge at ipfire.org
Fri Sep 16 11:55:48 CEST 2016


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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.ipfire.org/pipermail/development/attachments/20160916/e1b171ef/attachment.sig>


More information about the Development mailing list