OpenVPN/IPsec - Sweet32: Birthday attacks

OpenVPN/IPsec - Sweet32: Birthday attacks

[ummeegge]

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

Hi all,
i wanted to report a cross-site scripting vulnerability problem for OpenVPN and possibly also IPSec via the "SWEET32: Birthday attacks on 64-bit block ciphers which concerns the DES cipher incl. the 3DES variants but also the Blowfish cipher. The only way to fix it which i have currently recognized is to use other ciphers then those and another way for a faster implementation for OpenVPN is to renegotiate new keys more often. An example can be to use '--reneg-bytes 64000' in the configuration.

So my question is should we delete those ciphers from the OpenVPN/IPsec cipher lists and announce this problem to the community may via the Planet (have announced it already in the IPFire forum for OpenVPN) ?

Some deeper insides causing this problem can be found in here:

- https://sweet32.info/
- https://community.openvpn.net/openvpn/wiki/SWEET32

Greetings,

Erik

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

Re: OpenVPN/IPsec - Sweet32: Birthday attacks

[IT Superhack]

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

Hello Erik,

as far as I am concerned, removing ciphers from any software is
always a bit problematic.

For security reasons, it is always better to disable broken or
weak ciphers such as RC4, MD5 or similar. But this may cause
trouble if there are many legacy clients around.

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.

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).

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.

Nevertheless, it should be mentioned in the release notes that
some clients might not work anymore, so users can prepare for this scenario.

Best regards,
Timmothy Wilson


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

Re: OpenVPN/IPsec - Sweet32: Birthday attacks

[R. W. Rodolico]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 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).

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.

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'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.

Rod

P.S. Sorry about the misunderstanding. Blowfish is fixed at 64. It is
only the key length that is variable. My bad.

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlfIgYoACgkQuVY3UpYMlTSzFgCeLO4bSlFCKxQhLyUu8cYwvqqm
XTEAn21YnfIxBw3nj2lZodZNYNH2tI57
=uFjx
-----END PGP SIGNATURE-----

Re: OpenVPN/IPsec - Sweet32: Birthday attacks

[R. W. Rodolico]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

- -- 
Rod Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlfTrN0ACgkQuVY3UpYMlTQIEwCfWXgT85dwJqrnwBeYGmSblPuL
XjIAmgPujDjAZ0beVeK2Ka4Xyt+GS7lz
=LKnz
-----END PGP SIGNATURE-----

Re: OpenVPN/IPsec - Sweet32: Birthday attacks

[Michael Tremer]

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

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.

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.

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.

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.

The IPsec dropdown can be modified in just the same way.

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?

Are we proposing any insecure defaults? We should adjust these then.

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: 819 bytes --]

Re: OpenVPN/IPsec - Sweet32: Birthday attacks

[IT Superhack]

[-- 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 --]

Re: OpenVPN/IPsec - Sweet32: Birthday attacks

[Michael Tremer]

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

On Wed, 2016-09-14 at 19:04 +0000, IT Superhack wrote:
> 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).

I do not feel sorry at all for people who are using these. Especially if you set
up a VPN connection like this, you will probably figure out that you have to
change some settings to get it working. And you have been warned.

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

I am not sure if that is necessary on the main page. There is no way to silence
any warnings, so I am not sure if that is too distracting and in the way.

We don't want to throw too many warnings at the users because that makes them
not reading any of those.

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

Cool.

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

Good point.

> 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).

>From a security point of view I would support this. But see below :)

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

Same here. A background task system is required to do that. The design of the
webif makes this so complicated only.

> 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).

But changing the defaults for OpenVPN has some very bad implications:

If we would set this to higher settings, this would certainly work better on
modern systems. But if you have a single XP box that you need to connect you
cannot go back to SHA1 any more without replacing all other connections, too.

TLS1.2 is therefore very far out of reach.

> 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-fritzbo
> > > > > > > x
> > > ).
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > 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: 819 bytes --]

Re: OpenVPN/IPsec - Sweet32: Birthday attacks

[Michael Tremer]

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

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

What if something suddenly becomes "weak"?

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.

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

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

> 
> Some ideas from here.
> 
> Greetings,
> 
> Erik
> 
> 
> 
> Am 14.09.2016 um 21:04 schrieb IT Superhack <itsuperhack(a)web.de>:
> 
> > 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-fritz
> > > > > > > > box
> > > > ).
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > 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: 819 bytes --]

Re: OpenVPN/IPsec - Sweet32: Birthday attacks

[ummeegge]

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

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(a)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





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

Re: OpenVPN/IPsec - Sweet32: Birthday attacks

[ummeegge]

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

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(a)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(a)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
> 
> 
> 
> 


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