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: Fri, 16 Sep 2016 11:55:48 +0200 Message-ID: In-Reply-To: <1473938011.2757.196.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0671597123201947130==" List-Id: --===============0671597123201947130== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, since i=C2=B4 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 Bu= gzilla --> https://bugzilla.ipfire.org/show_bug.cgi?id=3D11186 . It might be = great if someone can go through it to give some response. Am 15.09.2016 um 13:13 schrieb Michael Tremer : > 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 a= nd >> 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 somethi= ng as > "strong" over here: >=20 > 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= :-). >=20 > What if something suddenly becomes "weak"? An idea can be to keep this list up-to-date by resorting possible new weak ca= ndidates as good as it is possible with all in the future released informatio= ns. The air in the cipher world becomes a little thin these days. There is curren= tly only AES and Camellia left which supports 192 and 256 bit key lengths. Th= e 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 th= e Seed cipher in the "Medium cipher" section above some other 64 bit block ci= phers which uses 192 bit key lengths, so the cipher list order has also been = change in that manner. >=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. O.K. have started with this. If these patches are ok and i=C2=B4am back home,= 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 a= dded the >> the selection of the auth algorithm, a lot of configurations have used alr= eady >> '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 th= at >> 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. I see there also some major difficulties cause, as you mentioned it, connecti= ons 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 setting= s. >=20 >> The Diffie-Hellman parameter needs, on weak boards or boards with less ent= ropy >> 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/ser= ver) >> and may too much/complicated to configure over the WUI, even if 2.4.x deli= vers >> it per default ? >=20 > Can we assume that we have a reasonably recent version on the clients? Good question, possibly the smartphone segment needs longer for that, there a= re nowadays a lot of "Unused options" findable in different smartphone logs b= ut i=C2=B4am not really sure about the time difference between the 2.4.x rele= ase 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-ciphe= rs=E2=80=9D are set in the compile options, which means if IPFire won=C2=B4t = use this option (if the new OpenSSL will be integrated, seems to be a little = messy) the discussed ciphers won=C2=B4t be anyways available anymore. Greetings, Erik --===============0671597123201947130== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KQ29tbWVudDogR1BHVG9vbHMgLSBodHRwczov L2dwZ3Rvb2xzLm9yZwoKaVFJY0JBRUJDZ0FHQlFKWDI4RzJBQW9KRUlQaWh4WDVKOGpuK2hzUCtn SmVKRVJXT2RKVVhVd2pONTJhSUw4ZgpYM3JVeWhqcXlLa0U2aTg5QVlQSTU5Tm1zRmh3eGk2TGdF aGk2TFd5cjhwdHE2V3d0ODdzU1FENExWZ0VlRldkCmt0eVVGMklzNnNDUG9tN0FtMkFETXhCblFr MGFLRzZxUFg2Z1I2VTNsQjFaVmk4VWlQWk8zeDBXd1FRMTdyVzMKSnViTVdVVG9QUS9Ud3VUL3VW aWo1UzhIMkI3Vk9WK1VBdjEwYmZJSnVibjhjeVIvdDNGVWZzQy9DemlGYlFDQworZ0syR2VNOXpC QTB5YXQzL29YbWVCUVFkaTlyWXlqOTRSdEpmVVl0UDFTaWtXSVpXT29MT2JGSU5DVXI0YVMxCm11 K2lZOGVtMzUzUHdJa0J0SGRPaldaa3RJeXIzYmdYeG90NnZTMDhvUm9Rd3RFRFFQbnlZS051c21T OWhLaUoKSXFGbi9DcUQ0VFpHNUZpQ0JOV3R0eDBPVlAxdEZjNDVqZ2NDUldNbUxDMUIyb1ZvOVZX NldRclE0ZEtyeVVmYgpham1MbnlENWk4dHlhNTlkSWR3Mm1RZGlyem9TLyttU25LL0ROak5XYnFE QUpIaDRjdTQ1M3RxZHlOdDUxQitQClN6RnhCNFY1RHNJUHNiVm5TMCtna29ZbFNuWHVYTERBZ3d3 ZTd4ZDlrakRxVklBUWZJQ0ZDRUZiMi9sQWRXU2oKWVIwakFXaGx3TlUwa05Bd3NYS250QWxqdFRn aHVkMytVdURLWmJ0dHhsZGttVUNuNXluR3VsUXQyK1hmYjJHSQpWeHRPcnlEQldIL2prOUlWS2Fp cmhwa21WRjhaT2RPUUxqY2FtTjF3ME1DZ2NYc1Q1bzN4YmE0QWxnQkpBT1dDClJDdlVYMEtqL0E5 bXdtaFl0bXo4Cj1MZUhQCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============0671597123201947130==--