From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: AW: [PATCH] change Apache TLS cipher list to "Mozilla Modern" Date: Thu, 09 Nov 2017 23:17:44 +0000 Message-ID: <1510269464.2945.18.camel@ipfire.org> In-Reply-To: <007d01d359a2$b0cec030$126c4090$@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6871981770098817575==" List-Id: --===============6871981770098817575== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, so how do we handle this? We now have the argument for better security against the argument for better compatibility. 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. Best, -Michael 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 > > > 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 > > 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 consid= er 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 web > > sites, the more it hurts. > >=20 > > (b) Internal web sites - which is the case for IPFire's WebUI - may be co= nsidered as less critical by some people since they are located > > in the always trustworthy and super-safe internal network. Needless to sa= y, 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 si= nce 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: 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_ expect th= at people move to this. Period. >=20 > They only thing I fear is that the apache configuration for the internal We= bUI is also used for addons like owncloud which might be accessed with mobile= clients - clients which cannot be updated that easily (this is why I cited t= he Android OS version usage statistics). >=20 > >=20 > > Service such as the Captive Portal or the Update Accelerator repo are usi= ng HTTP, so they should not make trouble. TLS 1.2 is "only" > > used for the administration web interface, which usually does not have to= be accessible from all clients. > >=20 > > This is why I submitted this patch. >=20 > After the discussion with Michael, it was also on my personal todo list to = submit an additional patch with the modern configuration, such that we can ch= oose 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 t= hey 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 atta= ckers in first place. This is why I'd never use the 'Modern' > > policy on MXs. >=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 se= rver 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 valu= e: > > > SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 This allows anyone to > > > understand that only TLSv1.2+ is supported. > >=20 > > Yes, you are right. I forgot that. > > >=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 > > Surprise! ;-) > > > I somewhere read that 2048-bit RSA is faster than 256-bit curve. > >=20 > > Really? I was unaware of this. >=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 reso= urces. >=20 > > > We are using a 4096-bit RSA together with a 384-bit curve. Did anyone p= erform some measurements? > >=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 > Ah, interesting. I executed the following command on my Ipfire machine (Int= el 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) si= gns and the client then verifies. So ECDSA is more resource intensive for cli= ents, 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, especia= lly when it comes to server CPU time. >=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 > > > > Did you see that conversation? > > >=20 > > > And I really thought that maybe my mail did not make it through after r= eading the patch... > >=20 > > I am sorry, but I really did not notice it. Did you say which systems you= expect to cause problems with TLS 1.2 only? >=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:Android_h= istorical_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 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-AES12= 8-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-S= HA: > > > > > 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 --===============6871981770098817575== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ2dBZEZpRUU1L3JXNWwzR0dl Mnlwa3R4Z0hudy8yK1FDUWNGQWxvRTRoa0FDZ2tRZ0hudy8yK1EKQ1FleXlCQUFwSW84UUlTT211 enJVdFdvbW1FQkRpOE5OMEVhV1Vqc0wrY2E1d1dyTzIwbDFJeVV6cC9VbzBsawpnYzd3bHhiUktl eG4yazBpckVHUy9Sd1p1Z2NOaXdCd1h5cUh3Qk0reVl5Y1lodFVXR2Nid3FUTEVyRnQrS0VPCnoy eWpvK2l0WUx5TXI1b2FpWE85eG4vemRtRVRVOTRQQ1VKUjZBK2FPYWhIWXVKNnVYM0FFcm90N3hp cUV4eG4KWW1KZjloTk9haEtBRjRDZ0dwUVZQU3h0RWRLY2xRUFNhMEp3WDRzYW9wcjJpVUI1LzYz RUZwMTgrbkRxMHRJKwo5aWhMdE1LdElZNE9LWFRNbXRXTEhkbU91Tk96NWVodTNOUy9vQUtEeWFP M0VXdHhMUFFUMEVUdnZheTlodW9mCllocHhLdWFtZmE0N1Y4d1pPRXpKeDFIQjI0VjlPUzdQcEF6 elhHZkpBZlE1cVFzd2dQZjlKc3NxazIvdUNpOW0KVzIxeFFxUThIeURtOFFYbmdnaWx6T080d1ZI NEMzY0pGaWxDRHU4RmdqTDFnZ2lESHg1dWpBeEFYQ2hNbGtRTgpCZnRBVllCZktRd2w3dkRtV3lm MnBGWDVDWWFYSGpKOFJmTUJxQVJJL2NCMjhFVHBCMUxZS01sR3dHTXdLd2RlCk43dTNMdUxiU0hw bC9NWndFYW5qTTVwbHFQMWFxMWJTUkNTZlk5OVdMTUJSV2ozWEhjcmFZdTl0NnRQeWNhdkEKOW5v OHpDdDJnUmdVQnhCSnZ0cFhsbktpYVlzS1NRUjJwSXVSV0JWTS9EeGsvbXdOQmg3QVNoTm4yT0kz R2kwcApGT05sdDVVZWFxd3FGc2hBVDF3c0xtSm9LZnZqZERmUXV6MnpYVVZmd2xlNDJSWFFMR0U9 Cj1ubk5DCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============6871981770098817575==--