From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] change Apache TLS cipher list to "Mozilla Modern" Date: Tue, 14 Nov 2017 15:28:37 +0000 Message-ID: <1510673317.4838.441.camel@ipfire.org> In-Reply-To: <75F4471A-B5DD-426A-B9E7-5D44149217F5@rymes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5832031556508785512==" List-Id: --===============5832031556508785512== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, On Sat, 2017-11-11 at 14:48 -0500, Tom Rymes wrote: > Is it possible to put a warning in the text after an update, or perhaps in = the > text where "An update requires a reboot" appears?=20 >=20 > Perhaps announce immediately and roll out two releases from now? That would be an option, but people don't seem to be updating for each releas= e. Some do it every second and some do it for every major or security release. So it will need to be there for a while and then we still won't be able to te= ll the right people that they would be affected. And to the pro-security people: Clearly that is a high priority. But I would like to say that the "conservative" option isn't really broken here. RSA isn't broken, the classic DH isn't broken and some of the server performance argume= nts are less important here because nobody has tens of thousands of people using = the webUI at the same time... Best, -Michael >=20 > Tom >=20 > > 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 > > > > I can fully understand that - my reaction time is usually also a lot > > > > longer 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 support 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 cli= ent > > > > > systems. > > > > >=20 > > > > > However, I would differ between several cases: > > > > > (a) Public web sites such as https://www.ipfire.org - for these, I > > > > > consider the 'Modern' policy OK since nobody wants to transmit > > > > > sensitive data with 3DES or SHA1. If a user cannot connect, it is > > > > > his/her/its fault. Further, the more SSL errors they get from big w= eb > > > > > sites, the more it hurts. > > > > >=20 > > > > > (b) Internal web sites - which is the case for IPFire's WebUI - may= be > > > > > considered as less critical by some people since they are located > > > > > in the always trustworthy and super-safe internal network. Needless= to > > > > > say, 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 th= ere > > > > > since weak algorithms are weak, no matter in what network > > > > > they are used. > > > > > And in case this breaks internal systems, it is not our fault eithe= r: > > > > > All 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_ exp= ect > > > > > that people move to this. Period. =20 > > > >=20 > > > > They only thing I fear is that the apache configuration for the inter= nal > > > > WebUI is also used for addons like owncloud which might be accessed w= ith > > > > mobile 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 a= re > > > > > using HTTP, so they should not make trouble. TLS 1.2 is "only" > > > > > used for the administration web interface, which usually does not h= ave > > > > > to 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 li= st > > > > to 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 > > > > > attackers 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 connecti= ons > > > > at all and/or do not check certificates for validity. I assume that t= he > > > > mail server world has improved, I still remember when it was not > > > > possible to connect securely to GMX' mail servers. > > > >=20 > > > > > >=20 > > > > > > Also, for the modern configuration, we should edit the SSLProtocol > > > > > > value: > > > > > > 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 co= mes > > > > to CPU/RAM resources. > > > >=20 > > > > > > We are using a 4096-bit RSA together with a 384-bit curve. Did > > > > > > anyone perform 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 > > > > (Intel 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 (Web= UI) > > > > signs and the client then verifies. So ECDSA is more resource intensi= ve > > > > for clients, but RSA is a lot slower on servers. > > > >=20 > > > > Also, I now recognized that secp384r1 is an NIST curve. Well, maybe t= his > > > > 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, > > > > > especially when it comes to server CPU time. =20 > > > >=20 > > > > Depends on the usage as can be seen above, but in general this is true > > > > for 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 reading the patch... =20 > > > > >=20 > > > > > I am sorry, but I really did not notice it. Did you say which syste= ms > > > > > you 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, > > > > Edge, 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:And= roi > > > > d_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 > > > > restarting the web server with an appropriate frequency (e.g. daily) > > > > compromises perfect forward secrecy." > > > >=20 > > > > Best regards, > > > > Wolfgang > > > >=20 > > > > > >=20 > > > > > > >=20 > > > > > > > > On Tue, 2017-11-07 at 20:51 +0100, Peter M=C3=BCller wrote: = > > > > > > > > Change the TLS cipher list of Apache to "Mozilla Modern". > > > > > > > >=20 > > > > > > > > ECDSA is preferred over RSA to save CPU time on both server a= nd > > > > > > > > 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 --===============5832031556508785512== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ2dBZEZpRUU1L3JXNWwzR0dl Mnlwa3R4Z0hudy8yK1FDUWNGQWxvTEM2VUFDZ2tRZ0hudy8yK1EKQ1FmWUdnLy9VZ3lia095SnZE azhLSFA3dTJvWVh5L0NuT09McXhKWWQ0K3B3MTRFbDZNZFN3SVZCWHU1YXNhago4cUIyMWFsRVZq aWxycENkVmY1eXdWQ25xcU10eTdiUzlLNE1yUklZRVZQd2xWK2JVbUdSUE1MSm5PMmdoRXNoCjRt VnRwZGloaWFoeTk5c1ZhTGhwYys2d2M1VVpLVmx5RmNlR3JnQWdDdjBwQ2M2Q3N2NFl0M1p1MU9U UDN6ZnoKMlFPSDlQZk9wdGdIZEowcG1JVDhQR2l0elB0OTZaMlFSdXJZbFJpdENESGxFRFlmQ012 TFFyUDBZWS9WdW1rcQo1N0F5eXpzUjVPZXZhMWE4OGpkQjVRNkU1dVpyYzFtM0R2TE1tcDY0TlEw M3o1OW1GSGdMRFl2dVdsVWN6U0RzCnIzQVl1Z3IyQmoyQ2xHVHc0RjRUbU0zU1lKYmVtTkJxMzZw WWh3VnBsVVA4cUNsZFd1RXhtZUkzS1ZHejdKOG4KTlM4RjVzMDN2Zi9VekVKSGQxWU1IdHpJWmxL TDZST3J2QmY5WEsyZHBKMlZHRFJ6eWNCY2hSVVRoaE1MZCtWbwprRlk1SlluZVZPcHBidk5PV2VP SGZiZ2UyZHhHbGNENjJpRXdIWFJjREkzU1dNM0RKaTcvQWk0Y1FGYlRRMzliCkoxSXNwc01Tc29L VHZLTTdHcXRoZ3pFNVJrMkxMZGdmZXJNc2k0a2xnR1dVWXNqOWlveGRsVG5xZlFzNGs1d1AKNWRC TE5OY29qTng5c21jUHR0bURoQ1JzUW54OWdMbmJpcTJ1QXpYbTdxZFFFK0MyNGZRQUYwbzJNNjVz WWJVTAoxNk1TbnR0VFdJOW1KMEJmUWhtZVd5eHpDVmtQMFQ5NzFGQ2g4dUROQWZ2SDhhajM4cjA9 Cj1QVWpyCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============5832031556508785512==--