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@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@dailydata.net
<mailto:rodo@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