From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: [PATCH] change Apache TLS cipher list to "Mozilla Modern" Date: Sat, 11 Nov 2017 20:39:15 +0100 Message-ID: <20171111203915.5dba7cb4.peter.mueller@link38.eu> In-Reply-To: <007d01d359a2$b0cec030$126c4090$@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3884002230121003397==" List-Id: --===============3884002230121003397== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Wolfgang, > 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 > > > > > > > > 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 >=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). Hm, yes, you have a point. I was not aware of these addons, nevertheless, I voted for "better security". ;-)=20 >=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 >=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 >=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. Yes, some RFC even defines that enforcing TLS must not be enabled on public mail servers. On my system, I kicked out 3DES recently, which does not seem to have a huge impact (yet), RC4 was much worse since all the old MS Exchanges use it. >=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! ;-) =20 > > > I somewhere read that 2048-bit RSA is faster than 256-bit curve. =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 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 >=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. Maybe this effect can be ignored at client side since you normally have only one HTTPS connection open to the WebUI - the firewall machine might have quite more. >=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... Yes. In IPsec, there are Brainpool curves, too, which I use as an alternative= to the NIST ones. However, the german Bundesamt f=C3=BCr Sicherheit in der Infor= mationstechnik (BSI) seems to be somehow related to them, so one has to decide which agency = to trust. :-| Curve25519 is also usable for IPsec... Speaking about Apache, most clients do not support anything else than the NIS= T curves (256 and 384 bits) for the ECDSA key. They sometimes support other curves (su= ch as the 25519 mentioned) for the ECDHE key exchange, which we might enable for IP= Fire. However, this needs some research, but it is on my todo list. >=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 > > > > > > > > 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 >=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 Updates - always in season, never out of style. :-) >=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." Thanks for catching that again. If we decide to implement the Modern policy, I will submit a second patch containing all the SSL changes. Best regards, Peter M=C3=BCller >=20 > Best regards, > Wolfgang >=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". > > > > > > > > > > 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. > > > > > > > > > > Signed-off-by: Peter M=C3=BCller > > > > > --- > > > > > config/httpd/vhosts.d/ipfire-interface-ssl.conf | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > 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 >=20 >=20 --===============3884002230121003397==--