Rod
On 08/31/2016 06:01 AM, ummeegge wrote:
> Hi all,
>>
>> You say "disable in the list." Would systems currently running
>> these ciphers have to rebuild their certificates? Or would their
>> system continue to run as is, but new configurations would only
>> have the better options available.
>
> the systems would run further with these ciphers but it won´t be
> possible to add new clients via WUI without changing the cipher and
> regarding to OpenVPN this means to change all configurations cause
> a OpenVPN instance have no variability with ciphers per client.
>
>>
>> If it would break any existing systems, I would prefer to not
>> disable it. If there was a way to change the tags in OpenVPN to
>> add a DANGER to the label, that would be sufficent. Maybe even a
>> link between Encyption: and the dropdown pointing to the articles
>> describing the issu e.
>>
>> I never like to disallow someone from doing something, especially
>> if it can cause their system to not work after an upgrade. I
>> prefer to warn them, and let them make informed decisions.
>
>
> I think this is also a good idea but as far as i can see OpenSSL
> for example will treat DES (triple-des) with version 1.1
like RC4
> (haven´t seen a similar note with e.g. Blowfish ?) -->
>
https://www.openssl.org/blog/blog/2016/08/24/sweet32/ . So it won´t
> be compiled by default but you need to activate
> "enable-weak-ssl-ciphers in config options in the new OpenSSL
> version. Whereby OpenSSLs new version might fill another discussion
> round i think cause it seems pretty problematic without patching a
> lot of other software which are linked against OpenSSL (e.g. failed
> builds with OpenSSL-1.1 on Debian -->
>
https://breakpoint.cc/openssl-1.1-rebuild-2016-08-26/failed/ ),
> there seems also to be some strange changes in the API but this
> only as a beneath info…
>
>>
>> In my release 104, I see 128 bit as the lowest option. This
>> vulnerability specifically shows that for 64 bit blocks, the
>> problem exists. To successfully attack a 64 bit block, you would
>> only need to generate 32 gig of traffic; definitely reasonable.
>> However, to successfully attack 128 bit blocks requires reading
>> 256 Exobytes, which is unreasonable to worry about at this time.
>> I'm assuming I'm reading this correctly and BF-CBS (128 bit)
>> actually means it is using 128 bit blocks.
>
>
> I don´t think so, this problem addresses not the key lenght, it
> means the fixed-lenght group of bits in the 'block' for these
> ciphers e.g. -->
https://en.wikipedia.org/wiki/Blowfish_(cipher)> under 'Cipher detail' .
>
>>
>> Finally, OpenVPN 2.4 (still very much in alpha) will support
>> cipher negotiation, where the client and server will dynamically
>> negotiate which cipher to use. Within a short time of its
>> release, the problem will no longer exist since both servers and
>> clients will be able to do behind the scenes negotiation.
>
> Yes, 2.4. brings some hope per default in that manner beneath some
> other things (ECDH support, …) but who knows when they will release
> it. Longer time ago i integrated the '--reneg-sec' directive into
> the WUI for testing purposes which is pretty similar to
> '--reneg-bytes' but i left it behind cause IPFire serves also the
> "Additional configuration" possibility so a individual way to
> adjust both configurations (client/server) is possible.
>
>>
>> In this case, mainly Windows XP-systems are affected since 3DES
>> was the only "safe" cipher suite they are able to use. Others
>> (RC4, DES) went down the drain a long time ago.
>>
>> With Sweet32, it became impossible to use such a system for
>> _any_ secure connection, no matter if its HTTPS, VPN or something
>> else.
>
> Not sure about this cause a lot of software ships their own crypto
> libs and do not use the system crypto, for example while the
> OpenVPN development time for Core 79 we tested also Windows XP
> systems positive with the Camellia cipher (AES too but also
> SHA2-512 was ok) -->
>
http://forum.ipfire.org/viewtopic.php?f=17&t=10008&start=90#p69221> .
>
>> Back to the VPN: It seems like there is a similar problem here,
>> because the (at least in Germany) very popular Fritz!Box by AVM
>> cannot handle IPSec VPNs with AES ciphers (source:
>>
http://wiki.ipfire.org/en/configuration/services/ipsec/avm-fritzbox).
>
>>
> Indeed, this is a problem and there are for sure more other
> problematic constellations out there…
>
>> In my humble opinion, removing the 3DES cipher is better. First
>> because it improves the transport security situation, although
>> it cannot be easily exploited. Second, the more weak techniques
>> and broken ciphers a legacy system supports are disabled on the
>> majority of the servers, the sooner people throw the old systems
>> away.
>
> I think this is not completely wide of the mark and it does remind
> me a little on the RC4, MD5, SHA1 discussions. In fact this problem
> is known since long time but anyways this ciphers are nowadays
> nevertheless widely used…
>
> Another good overview causing this topic can be found also here -->
>
https://sweet32.info/SWEET32_CCS16.pdf .
>
> Some thoughts from here.
>
> Greetings,
>
> Erik
>
>
>
>
--
Rod Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net