'Re: OpenVPN/IPsec - Sweet32: Birthday attacks'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfire-development
Subject:    Re: OpenVPN/IPsec - Sweet32: Birthday attacks
From:       ummeegge <ummeegge () ipfire ! org>
Date:       2016-11-12 10:04:43
Message-ID: B1CB14A7-3B99-4A39-A763-D28F271BCCB8 () ipfire ! org
[Download RAW message or body]

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


["signature.asc" (signature.asc)]

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJYJulBAAoJEIPihxX5J8jn+JgQAMOZbu2Ywa7IcyVHwGE8UkGi
3XSdKK4vS155ULA1yiFxgUN54zHRctOl10QS4Ukd9fFR7FwxGYkZ03sdT6J3fkde
1Z7vHqg8v6iEiQJjg4H1iiBQtq7MtHs53XqfRqIlCPKNfHFWaQu/GvLrXuPepVUZ
1nDhYwhUlqhSrT/0rUf5t3RasT+wx4ZR5DOuFBeQlCN9z2w+tfBv06m4IMudc4KJ
dFAwmIYahNuRRU3+LggR+YrWHkheefbmPBns2RQ/ZxfEQMYUa8rBkGFEGMSsS9gB
4GAAVtVci/jl1jfYgP4041KKgDuMHTx0gfU0xXmfBRpe21Ga4/X5s+lyWRhzsW7l
hwOsdYYy6zZ0aonPfKxPmkATd6TyKcn6zEG3NHMsY6GJz0CKFFcQoL99T6S09YBa
x7dpUhuB0uHLoYvKwbaL/mgBfnhmZhbXeam5rfSTSTnm8XXiX44iEZ38ZGf9pFfb
VI+Aqmidd8+9otrGQdZTmQ9yRHezgetkFCj47H3dpwfkeuH42TMUdFKKR8v2Vrk7
Zcx+r9EKuOG0qPlO0UNGXe2zAzzeaNmgXvJUMVuXoVVesSiga+3csYlHT7VC1R+Q
s4dpQ0SYTZ+7N9b7xaJaZBDDbQRGgiujnC04rN5SJeAfspkQQCulwn5qcH3yNpWT
UnqLTdbOZK2BNp3cYAWE
=vgoz
-----END PGP SIGNATURE-----


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic