From mboxrd@z Thu Jan 1 00:00:00 1970 From: ummeegge To: development@lists.ipfire.org Subject: Re: OpenVPN/IPsec - Sweet32: Birthday attacks Date: Sat, 12 Nov 2016 11:04:43 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4286818330506089445==" List-Id: --===============4286818330506089445== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, i think the whole problem can be solved if an update to OpenVPN version 2.3.1= 3 has been done since the sweet32 problem should there be fixed cause they us= ed in there also the 64 MB limitation in reneg-sec --> https://community.open= vpn.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=3D11186 . As a beneath info, OpenVPN-2.4_alpha2 is out now which was available. Have bu= ild 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 i= f someone is interested in that topic, you can find it in here --> https://fo= rum.ipfire.org/viewtopic.php?f=3D50&p=3D102654&sid=3Dbef338860cedb98a1eae3a44= 9ef520e4#p102654 . Erik Am 16.09.2016 um 11:55 schrieb ummeegge : > Hi, > since i=C2=B4 am currently on a journey and have no access to my developmen= t environment to send some patches via Patchday, i have left a first idea in = Bugzilla --> https://bugzilla.ipfire.org/show_bug.cgi?id=3D11186 . It might b= e great if someone can go through it to give some response. >=20 > Am 15.09.2016 um 13:13 schrieb Michael Tremer : >=20 >> Hi, >>=20 >> 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 >>=20 >> We had a similar discussion over here if it was a good idea to mark someth= ing as >> "strong" over here: >>=20 >> http://lists.ipfire.org/pipermail/development/2015-December/001236.html >=20 > Yes i remember also this discussion, but i think we have had also some othe= rs :-). >=20 >>=20 >> What if something suddenly becomes "weak"? >=20 > 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 informat= ions. > The air in the cipher world becomes a little thin these days. There is curr= ently 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 b= it key lengths. All other currently available ciphers in OpenVPN on IPFire us= es 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 bee= n change in that manner. >=20 >>=20 >> But generally I think this is better than what we have now. >>=20 >>> Ciphers: >>>=20 >>> Strong algorithms >>>=20 >>> With 256 bit (keylenght) <--> 128 Bit block ciphers >>> With 192 bit (keylenght) <--> " >>>=20 >>> Medium algorithms >>>=20 >>> With 128 bit (keylenght) <--> 128 bit block ciphers >>>=20 >>> Weak algorithms >>>=20 >>> With 192 bit (keylenght) <--> 64 bit block ciphers >>> With 128 bit (keylenght) <--> 64 bit block ciphers >>>=20 >>>=20 >>> HMACs: >>>=20 >>> Strong algorithms >>>=20 >>> 512 bit Whirlpool, SHA2 >>> 384 bit SHA2 >>>=20 >>> Medium algorithms >>>=20 >>> 256 bit SHA2 >>>=20 >>> Weak algorithms >>>=20 >>> 160 bit SHA1 and md5 >>>=20 >>>=20 >>> Diffie-Hellman parameter: >>>=20 >>> Strong algorithms >>>=20 >>> 4096, 3072 >>>=20 >>> Medium algorithms >>>=20 >>> 2048 >>>=20 >>> Weak algorithm >>>=20 >>> 1024 >>>=20 >>> May too much but as an first idea for the naming and structure of the >>> optgroups in OpenVPN. >>=20 >> Let's start with that one then and do IPsec later. >=20 > O.K. have started with this. If these patches are ok and i=C2=B4am back hom= e, i can send them via Patchday. > , >>=20 >>> Causing the defaults for the HMAC: >>> SHA1 is really no good choice in OpenVPN but in the time when we=C2=B4ve = added the >>> the selection of the auth algorithm, a lot of configurations have used al= ready >>> '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 generat= ed >>> with new parameters all existing clients with the old defaults (SHA1 in t= hat >>> case) won=C2=B4t work anymore until they have been changed appropriately. >>=20 >> Changing the default to SHA256 has some implications that may cause major >> difficulties later. See my other email for this. >=20 > I see there also some major difficulties cause, as you mentioned it, connec= tions which do not use a new default value needs to change them accordingly o= n every client configuration since the server do not push these kind of setti= ngs. >=20 >>=20 >>> The Diffie-Hellman parameter needs, on weak boards or boards with less en= tropy >>> a lot of time so an security/usability question comes up again. >>>=20 >>> 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/se= rver) >>> and may too much/complicated to configure over the WUI, even if 2.4.x del= ivers >>> it per default ? >>=20 >> Can we assume that we have a reasonably recent version on the clients? >=20 > 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=C2=B4am not really sure about the time difference between the 2.4.x re= lease and a reasonable take over of the new functions into the different clie= nt software and platforms but this point should be considered for the hope of= a software side solution of the sweet32 birthday problem. >=20 > Michael, did you have had a look into the new OpenSSL-1.1.0 update ? What a= re you thinking about that, cause OpenSSL wrote in their announcement that DE= S and all variations of it will only be available if the "enable-weak-ssl-cip= hers=E2=80=9D are set in the compile options, which means if IPFire won=C2=B4= t use this option (if the new OpenSSL will be integrated, seems to be a littl= e messy) the discussed ciphers won=C2=B4t be anyways available anymore. >=20 >=20 > Greetings, >=20 > Erik >=20 >=20 >=20 >=20 --===============4286818330506089445== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KQ29tbWVudDogR1BHVG9vbHMgLSBodHRwczov L2dwZ3Rvb2xzLm9yZwoKaVFJY0JBRUJDZ0FHQlFKWUp1bEJBQW9KRUlQaWh4WDVKOGpuK0pnUUFN T1pidTJZd2E3SWN5Vkh3R0U4VWtHaQozWFNkS0s0dlMxNTVVTEExeWlGeGdVTjU0ekhSY3RPbDEw UVM0VWtkOWZGUjdGd3hHWWtaMDNzZFQ2SjNma2RlCjFaN3ZIcWc4djZpRWlRSmpnNEgxaWlCUXRx N010SHM1M1hxZlJxSWxDUEtOZkhGV2FRdS9HdkxyWHVQZXBWVVoKMW5EaFl3aFVscWhTclQvMHJV ZjV0M1Jhc1Qrd3g0WlI1RE91RkJlUWxDTjl6MncrdGZCdjA2bTRJTXVkYzRLSgpkRkF3bUlZYWhO dVJSVTMrTGdnUitZcldIa2hlZWZibVBCbnMyUlEvWnhmRVFNWVVhOHJCa0dGRUdNU3NTOWdCCjRH QUFWdFZjaS9qbDFqZllnUDQwNDFLS2dEdU1IVHgwZ2ZVMHhYbWZCUnBlMjFHYTQvWDVzK2x5V1Jo enNXN2wKaHdPc2RZWXk2elowYW9uUGZLeFBta0FUZDZUeUtjbjZ6RUczTkhNc1k2R0p6MENLRkZj UW9MOTlUNlMwOVlCYQp4N2RwVWh1QjB1SExvWXZLd2JhTC9tZ0JmbmhtWmhiWGVhbTVyZlNUU1Ru bThYWGlYNDRpRVozOFpHZjlwRmZiClZJK0FxbWlkZDgrOW90ckdRZFpUbVE5eVJIZXpnZXRrRkNq NDdIM2Rwd2ZrZXVINDJUTVVkRktLUjh2MlZyazcKWmN4K3I5RUt1T0cwcVBsTzBVTkdYZTJ6QXp6 ZWFObWdYdkpVTVZ1WG9WVmVzU2lnYSszY3NZbEhUN1ZDMVIrUQpzNGRwUTBTWVRaKzdOOWI3eGFK YVpCRERiUVJHZ2l1am5DMDRyTjVTSmVBZnNwa1FRQ3Vsd241cWNIM3lOcFdUClVucUxUZGJPWksy Qk5wM2NZQVdFCj12Z296Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============4286818330506089445==--