From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rymes To: development@lists.ipfire.org Subject: Re: [PATCH] change Apache TLS cipher list to "Mozilla Modern" Date: Sat, 11 Nov 2017 14:48:59 -0500 Message-ID: <75F4471A-B5DD-426A-B9E7-5D44149217F5@rymes.com> In-Reply-To: <20171111202744.4c2769dd.peter.mueller@link38.eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6833654058997209677==" List-Id: --===============6833654058997209677== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Is it possible to put a warning in the text after an update, or perhaps in th= e text where "An update requires a reboot" appears?=20 Perhaps announce immediately and roll out two releases from now? Tom > On Nov 11, 2017, at 2:33 PM, Peter M=C3=BCller = wrote: >=20 > Hello Peter, hello Wolfgang, >=20 > +1 for security, too. >=20 > However, it might be good to warn the users (planet post, etc.) some > time before we release a new version which changes this. >=20 > In case we decide to change to the Modern SSL policy, I'll send in > a second patch containing the Apache SSL directives Wolfgang told me > (thanks for this again!). >=20 > Best regards, > Peter M=C3=BCller >=20 >> Hi, >>=20 >> so how do we handle this? >>=20 >> We now have the argument for better security against the argument for >> better compatibility. >>=20 >> Indeed this is not an easy question. So please everybody else who has >> an opinion on this step forward and then I will just count the votes. >>=20 >> Best, >> -Michael >>=20 >>> On Thu, 2017-11-09 at 22:35 +0100, Wolfgang Apolinarski wrote: >>> Hi Peter, >>>=20 >>>>=20 >>>> Hello Wolfgang, >>>>=20 >>>> sorry for replying that late - at the moment I am quite busy. :-| =20 >>>=20 >>> I can fully understand that - my reaction time is usually also a lot long= er than what I want it to be... >>>=20 >>>>>>=20 >>>>>> Actually I proposed that in the discussion to another patch, but >>>>>> Wolfgang said that we would exclude too many systems. =20 >>>>>=20 >>>>> I still think that there might be too many clients, which do not have s= upport for TLS 1.2. >>>>> I would suggest postponing this step to next year. =20 >>>>=20 >>>> To keep it short: I fear this is correct and there are networks - mostly= they belong to companies, ironically - with very ancient client >>>> systems. >>>>=20 >>>> However, I would differ between several cases: >>>> (a) Public web sites such as https://www.ipfire.org - for these, I consi= der the 'Modern' policy OK since nobody wants to transmit >>>> sensitive data with 3DES or SHA1. If a user cannot connect, it is his/he= r/its fault. Further, the more SSL errors they get from big web >>>> sites, the more it hurts. >>>>=20 >>>> (b) Internal web sites - which is the case for IPFire's WebUI - may be c= onsidered as less critical by some people since they are located >>>> in the always trustworthy and super-safe internal network. Needless to s= ay, I consider this being bullshit, but that explains why we still >>>> have WinXP & Co. systems running. >>>>=20 >>>> However, in my opinion, we also should apply the 'Modern' policy there s= ince weak algorithms are weak, no matter in what network >>>> they are used. >>>> And in case this breaks internal systems, it is not our fault either: Al= l you need is a system with FF >=3D 28 or something similar. TLS 1.2 is >>>> far from being brand new and as far as I am concerned, we _can_ expect t= hat people move to this. Period. =20 >>>=20 >>> They only thing I fear is that the apache configuration for the internal = WebUI is also used for addons like owncloud which might be accessed with mobi= le clients - clients which cannot be updated that easily (this is why I cited= the Android OS version usage statistics). >>>=20 >>>>=20 >>>> Service such as the Captive Portal or the Update Accelerator repo are us= ing HTTP, so they should not make trouble. TLS 1.2 is "only" >>>> used for the administration web interface, which usually does not have t= o be accessible from all clients. >>>>=20 >>>> This is why I submitted this patch. =20 >>>=20 >>> After the discussion with Michael, it was also on my personal todo list t= o submit an additional patch with the modern configuration, such that we can = choose which we like best. So I am glad you did that. >>>=20 >>>>=20 >>>> (c) And there are mail servers, which must be treated differently since = they fall back to plain text in case no common SSL/TLS ciphers >>>> were found. TLS on MX is meant as a protection layer against passive att= ackers in first place. This is why I'd never use the 'Modern' >>>> policy on MXs. =20 >>>=20 >>> And there are still mail server that do not accept encrypted connections = at all and/or do not check certificates for validity. I assume that the mail = server world has improved, I still remember when it was not possible to conne= ct securely to GMX' mail servers. >>>=20 >>>>>=20 >>>>> Also, for the modern configuration, we should edit the SSLProtocol valu= e: >>>>> SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 This allows anyone to >>>>> understand that only TLSv1.2+ is supported. =20 >>>>=20 >>>> Yes, you are right. I forgot that. =20 >>>>>=20 >>>>> Regarding the re-ordering of the cipher suites: >>>>> ECDHE-ECDSA is not always faster than ECDHE-RSA. >>>>> It depends on the size of the EC and the RSA key. >>>>> Although I'm assuming that a 4096-bit key is quite slow... =20 >>>>=20 >>>> Surprise! ;-) =20 >>>>> I somewhere read that 2048-bit RSA is faster than 256-bit curve. =20 >>>>=20 >>>> Really? I was unaware of this. =20 >>>=20 >>> I think it was some slow Atom machine - I was just a little bit concerned= , because the router machines are also constraint when it comes to CPU/RAM re= sources. >>>=20 >>>>> We are using a 4096-bit RSA together with a 384-bit curve. Did anyone p= erform some measurements? =20 >>>>=20 >>>> No, not yet. The only numbers I have are from Ivan Ristic, who says: >>>>=20 >>>> algorithm strength CPU time (client) CPU time (server) >>>> ECDHE-ECDSA 256/256 bits 1.09s 0.74s >>>> ECDHE-RSA 256/2048 bits 0.81s 2.06s =20 >>>=20 >>> Ah, interesting. I executed the following command on my Ipfire machine (I= ntel NUC): >>> "openssl speed aes rsa ecdsa ecdh" >>> the results are: >>> Method ; Sign ; Verify ; Sign/s ; Verify/s >>> 384 bit ecdsa (nistp384) ; 0.0007s ; 0.0030s ; 1356.3 ; 335.3 >>> rsa 2048 bits; 0.004814s 0.000141s ; 207.7 ; 7075.8 >>> rsa 4096 bits; 0.034930s 0.000531s ; 28.6 ; 1882.1 >>> Method ; op ; op/s >>> 384 bit ecdh (nistp384) ; 0.0025s ; 400.8 >>>=20 >>> RSA is really fast in verification, but I assume that the server (WebUI) = signs and the client then verifies. So ECDSA is more resource intensive for c= lients, but RSA is a lot slower on servers. >>>=20 >>> Also, I now recognized that secp384r1 is an NIST curve. Well, maybe this = is more a political issue and not that relevant for a WebUI-Frontend... >>>=20 >>>>=20 >>>> Thereof I assume ECDSA keys perform usually better than RSA ones, especi= ally when it comes to server CPU time. =20 >>>=20 >>> Depends on the usage as can be seen above, but in general this is true fo= r servers, especially with increasing key sizes. =20 >>>>>=20 >>>>>>=20 >>>>>> Did you see that conversation? =20 >>>>>=20 >>>>> And I really thought that maybe my mail did not make it through after r= eading the patch... =20 >>>>=20 >>>> I am sorry, but I really did not notice it. Did you say which systems yo= u expect to cause problems with TLS 1.2 only? =20 >>>=20 >>> Yes, according to Mozilla: >>> Oldest compatible clients: Firefox 27, Chrome 30, IE 11 on Windows 7, Edg= e, Opera 17, Safari 9, Android 5.0, and Java 8 >>>=20 >>> Android < 5.0 has still a market share of > 25%. >>> https://en.wikipedia.org/wiki/Android_version_history#/media/File:Android= _historical_version_distribution_-_vector.svg >>>=20 >>> Actually all my clients would be compatible. ;-) >>>=20 >>> Nevertheless, the following additional changes would be a good idea: >>> SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 >>> SSLCompression off >>> SSLSessionTickets off >>> (the last parameter improves PFS). The apache docs: >>> "TLS session tickets are enabled by default. Using them without restartin= g the web server with an appropriate frequency (e.g. daily) compromises perfe= ct forward secrecy." >>>=20 >>> Best regards, >>> Wolfgang >>>=20 >>>>>=20 >>>>>>=20 >>>>>>> On Tue, 2017-11-07 at 20:51 +0100, Peter M=C3=BCller wrote: =20 >>>>>>> Change the TLS cipher list of Apache to "Mozilla Modern". >>>>>>>=20 >>>>>>> ECDSA is preferred over RSA to save CPU time on both server and >>>>>>> client. Clients without support for TLS 1.2 and AES will >>>>>>> experience connection failures. >>>>>>>=20 >>>>>>> Signed-off-by: Peter M=C3=BCller >>>>>>> --- >>>>>>> config/httpd/vhosts.d/ipfire-interface-ssl.conf | 2 +- >>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>>>>=20 >>>>>>> diff --git a/config/httpd/vhosts.d/ipfire-interface-ssl.conf >>>>>>> b/config/httpd/vhosts.d/ipfire-interface-ssl.conf >>>>>>> index c9ccd5be5..d08d3d2bb 100644 >>>>>>> --- a/config/httpd/vhosts.d/ipfire-interface-ssl.conf >>>>>>> +++ b/config/httpd/vhosts.d/ipfire-interface-ssl.conf >>>>>>> @@ -9,7 +9,7 @@ >>>>>>> TransferLog /var/log/httpd/access_log >>>>>>> SSLEngine on >>>>>>> SSLProtocol all -SSLv2 -SSLv3 >>>>>>> - SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-= SHA256:ECDHE-ECDSA >>>>>>> -AES128-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA38 >>>>>>> 4:EC >>>>>>> DHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128- >>>>>>> SHA2 >>>>>>> 56:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES2 >>>>>>> 56-S >>>>>>> HA384:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA: >>>>>>> CAMELLIA128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLI >>>>>>> A256 >>>>>>> -SHA >>>>>>> + SSLCipherSuite >>>>>>> + ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDH >>>>>>> + E-EC >>>>>>> + DSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES1 >>>>>>> + 28-S >>>>>>> + HA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:EC >>>>>>> + DHE- >>>>>>> + RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-S >>>>>>> + HA25 >>>>>>> + 6 >>>>>>> SSLHonorCipherOrder on >>>>>>> SSLCertificateFile /etc/httpd/server.crt >>>>>>> SSLCertificateKeyFile /etc/httpd/server.key =20 >>>=20 >>>=20 >=20 --===============6833654058997209677==--