Re: OpenVPN/IPsec - Sweet32: Birthday attacks

[IT Superhack <itsuperhack@web.de>]

[-- Attachment #1: Type: text/plain, Size: 15664 bytes --]

Hello Michael,

Michael Tremer:
> Hey,
> 
> apologies for jumping in on this so late, but time is rare for me at the moment.
> 
> I agree that we need to do something here, but with crypto we always end up with
> the same problem. That is: How do we offer a good migration path?
> 
> Some ciphers we support are clearly broken. If we would disable those probably
> the majority of IPsec tunnels and OpenVPN connections would not work any more
> since lots of hardware that you buy today still only does RC4, (3)DES, SHA1 or
> MD5. That's terrible.
Indeed, it is. :-(
> 
> If we would kick out all of those, we would have people ask to get these back
> in. They have some reasons to use those. AFAIK does lots of Cisco stuff
> implement 3DES in hardware which is therefore much faster than AES.
Yes, some earlier versions of the Cisco ASA series don't even support AES, and
in some cases, there is a bug preventing a successful VPN connection (that applies
to the AVM Fritz!Boxes, too).
> 
> That's not convincing to me, but in those businesses out there, they need
> throughput and prioritize that over security.
> 
> Then there is the big lack of a migration path for OpenVPN. If you change the
> cipher on the server side, no client would be able to connect any more unless
> you update the configuration. Completely unfeasible to do with probably more
> than 5 connections. If OpenVPN would negotiate the ciphers like IPsec does there
> would be a good chance. Unfortunately it does not and is not even very user-
> friendly when you have a configuration mismatch.
> 
> Hence I am with Rod. People will only touch that if they have to and that is
> very often when the hardware dies.
> 
> So I think there is no chance that we just remove all the "broken" ciphers here.
> That will break too many systems. People would probably avoid updating then and
> get new security issues in other components.
I agree with this and it's a very common behavior. (In fact, more than a third of
the security incidents the customers of my company encounter can be tracked down
to this behavior.)
> 
> So could someone work on a patch to mark these as "weak". We had this discussion
> earlier on this list but a final solution was never implemented.
> 
> We could just modify the dropdown on the OpenVPN page like this:
> 
> CAMELLIA-CBC (256 bit)
> CAMELLIA-CBC (192 bit)
> ...
> Weak Ciphers
>   BF-CBC
>   ...
> 
> The <optgroup> tag can be used for that:
>   http://www.w3schools.com/tags/tag_optgroup.asp
> 
> Additionally we can show a flag next to it if a weak cipher is in use.
That's a good idea. Maybe we can also display a notification on the main page
(similar to the "there is a new update available" notice) since usually you
don't touch the VPN configuration sites if everything works.
> 
> The IPsec dropdown can be modified in just the same way.
Yep.
> 
> So we will keep supporting those ciphers, but we make it crystal clear that it
> is not recommended to use them.
> 
> Would that be okay with you? Did I get everything discussed here baked into the
> proposed solution?
I'm happy with this.
> 
> Are we proposing any insecure defaults? We should adjust these then.
Yes:
OpenVPN (advanced server options): SHA1 is set as default
IPSec (advanced connection options): SHA1 is enabled by default

I am not sure about the "Grouptype" options in IPSec, since I would disable
anything weaker than 2048 Bits (RSA/MODP) or 256 Bits (ECDSA/ECP).

Neither am I sure about the "Diffie-Hellman parameters". 1024 Bits - which
is set as default currently, is awfully short; 2048 is the minimum recommended
length. Needless to say, this may take ages on slow hardware, so I'm not
sure how to deal with this.

Similar problems occur within Apache:
* Logjam/Weak DH params, which cannot be fixed easily at the moment
* current configuration supports SHA1. But if we'd disable that, clients must
use TLS 1.2 which is better, but not always possible (IE6-8 on WinXP/Vista/7).

Best regards,
Timmothy Wilson
> 
> Best,
> -Michael
> 
> On Sat, 2016-09-10 at 01:49 -0500, R. W. Rodolico wrote:
>> From what I understand, existing configurations will stay the same and
>> still be able to connect. The only effect this will have is to keep
>> people from creating new certs with the insecure ciphers. In that
>> case, I think they could be killed with no problem.
>>
>> If you decide to do this, all we need to do is document it so we don't
>> get people asking "where is blowfish; I always use that!" Putting it
>> in the forum is cool, but I want to put it in the documentation
>> (wiki.ipfire.org), mainly in
>> http://wiki.ipfire.org/en/configuration/services/openvpn. Again, I'm
>> not coding, so I am happy to document.
>>
>> I was concerned you were talking about pulling the ciphers completely
>> out of OpenVPN, so the server would not be able to respond when an old
>> connection was made using one of the insecure ciphers. Pulling it from
>> the list of available ciphers for new connections should not be an
>> issue at all.
>>
>> Happy to help whatever you need with the wiki. I'm on the
>> documentation(a)lists.ipfire.org list. Is that the one you're talking
>> about? I use OpenVPN quite a bit, so just let me know what you want me
>> to do.
>>
>> Rod
>>
>> On 09/05/2016 03:30 AM, ummeegge wrote:
>>>
>>> Hi,
>>>
>>> Am 01.09.2016 um 21:29 schrieb R. W. Rodolico <rodo(a)dailydata.net 
>>> <mailto:rodo(a)dailydata.net>>:
>>>
>>>>
>>>> Signierter PGP-Teil No matter which way you decide to go, we
>>>> need to document as soon as possible. Is there any way we could
>>>> modify release 104 to highlight insecure ciphers and insert a
>>>> link to an article? I volunteer to write
>>>>
>>>
>>> the decision needs to made by the core developers, may also in 
>>> conjunction with an update of the OpenSSL library to version 1.1 
>>> cause as you could read in the OpenSSL announcement, if the 
>>> 'enable-weak-cipher" option won´t be set DES (and his variations) 
>>> won´t work anymore ? But i´am not sure about that may there are 
>>> other ways around. I wanted only to point this specific problem
>>> out and as far as i can see the half of the OpenVPN ciphers are 64
>>> bit block ciphers and are affected. Exception are Camellia, AES and
>>> the Seed ciphers. Have also made some smaller changes in the
>>> OpenVPN wiki (it definitely needs some updates/fixes) and i will
>>> make some more in the next days and it would be great if you go
>>> also for some extensions (may we can meet in the wiki mailinglist
>>> for coordination).
>>>
>>>>
>>>> the article.
>>>>
>>>> What I'm thinking is, in 104 (I'm assuming dropping the insecure
>>>>  ciphers would not happen until 105), whey they view the OpenVPN
>>>>  screen, if they are using an insecure cipher, the text would
>>>> show up in red or something. It seems a simple fix (but I've not 
>>>> looked at the code, so it may not be).
>>>>
>>>
>>> Since Core 104 is currently in testing tree, this could be a
>>> chance and as you mentioned it is a simple text formatting patch
>>> but as i wrote it before, the core developers needs to decide
>>> that.
>>>
>>>>
>>>>
>>>> I disagree with "the sooner people throw old systems away" idea, 
>>>> as my basic philosophy is to use equipment until it won't boot. 
>>>> One of the advantages to FOSS. But, in this case, we're looking 
>>>> at the possibility of having to force outdated options in 
>>>> multiple packages which would be a fairly good sized effort.
>>>>
>>>
>>> There are configuration possibilities between "throw old systems 
>>> away" or "disable this ciphers", but in would in anyways needs 
>>> knowledge and activities from the user side in that case.
>>>
>>>>
>>>>
>>>> Whatever happens, it needs to be documented, and I'd like to get 
>>>> it out there as soon as possible. And very visible even to users 
>>>> who don't read mailing lists or even visit the Planet.
>>>>
>>>
>>> I did some announcements also in the IPFire forum, may i should
>>> pin it to the top...
>>>
>>>>
>>>>
>>>> I'm still not clear on one thing. If Blowfish (for example) is 
>>>> used in one of my connections and it was removed, I'm assuming 
>>>> that connection would no longer work. Correct? It sounds like we 
>>>> have the option of removing it from the list of available 
>>>> options, but also removing support completely from OpenVPN. Am I 
>>>> missing something.
>>>>
>>>
>>> This connection will work further even if Blowfish has been
>>> deleted from the WUIs cipher list it will further appear in the
>>> server.conf and it is furthermore present in the OpenSSL library
>>> but the problem will be to change things in the WUI or even to add
>>> more clients cause by pressing the next time 'save' the
>>> configuration will be changed (if no other cipher will be set to 
>>> 'CAMELLIA-256-CBC' will be written to server.conf cause it is
>>> first in the list) and all other client configurations needs then
>>> to be adjusted accordingly.
>>>
>>>
>>>>
>>>>
>>>> Rod
>>>>
>>>> P.S. Sorry about the misunderstanding. Blowfish is fixed at 64. 
>>>> It is only the key length that is variable. My bad.
>>>>
>>>
>>> No problem good that we clear things like that.
>>>
>>>
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]