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