Hi, In order to evaluate the impact of any change on ciphers I usually use https://ssllabs.com/ssltest in order to get a full report on clients (including mobile clients) that will no longer be able to use my test server with new protocols and ciphers. >From my experience with such changes I recommend to keep at least TLS 1.0, 1.1 and a few older RSA ciphers in order to permit access to a reasonable list of clients. A possible configuration for the server with grade A+ is the one copied from www.paypal.com. On above link you can check the config and for paypal.com, config that allows TLS 1.0, 1.1, 1.2 and a few older RSA ciphers in order to allow older clients to use the site) Best Regards Horace On November 10, 2017 1:17:44 AM GMT+02:00, Michael Tremer wrote: >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, >> >> > >> > Hello Wolfgang, >> > >> > sorry for replying that late - at the moment I am quite busy. :-| >> >> I can fully understand that - my reaction time is usually also a lot >longer than what I want it to be... >> >> > > > >> > > > Actually I proposed that in the discussion to another patch, >but >> > > > Wolfgang said that we would exclude too many systems. >> > > >> > > 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. >> > >> > To keep it short: I fear this is correct and there are networks - >mostly they belong to companies, ironically - with very ancient client >> > systems. >> > >> > 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 web >> > sites, the more it hurts. >> > >> > (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. >> > >> > However, in my opinion, we also should apply the 'Modern' policy >there 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 >either: All you need is a system with FF >= 28 or something similar. >TLS 1.2 is >> > far from being brand new and as far as I am concerned, we _can_ >expect that people move to this. Period. >> >> 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 mobile clients - clients which cannot be updated that >easily (this is why I cited the Android OS version usage statistics). >> >> > >> > Service such as the Captive Portal or the Update Accelerator repo >are using 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. >> > >> > This is why I submitted this patch. >> >> 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 choose which we like best. So I am glad you did that. >> >> > >> > (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. >> >> 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 connect securely to GMX' mail servers. >> >> > > >> > > 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. >> > >> > Yes, you are right. I forgot that. >> > > >> > > 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... >> > >> > Surprise! ;-) >> > > I somewhere read that 2048-bit RSA is faster than 256-bit curve. >> > >> > Really? I was unaware of this. >> >> 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 resources. >> >> > > We are using a 4096-bit RSA together with a 384-bit curve. Did >anyone perform some measurements? >> > >> > No, not yet. The only numbers I have are from Ivan Ristic, who >says: >> > >> > 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 >> >> 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 >> >> 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 clients, but RSA is a lot slower on servers. >> >> 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... >> >> > >> > Thereof I assume ECDSA keys perform usually better than RSA ones, >especially when it comes to server CPU time. >> >> Depends on the usage as can be seen above, but in general this is >true for servers, especially with increasing key sizes. >> > > >> > > > >> > > > Did you see that conversation? >> > > >> > > And I really thought that maybe my mail did not make it through >after reading the patch... >> > >> > 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? >> >> 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 >> >> 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 >> >> Actually all my clients would be compatible. ;-) >> >> 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." >> >> Best regards, >> Wolfgang >> >> > > >> > > > >> > > > On Tue, 2017-11-07 at 20:51 +0100, Peter Müller wrote: >> > > > > 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üller >> > > > > --- >> > > > > 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-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 >> >> -- Horace Michael (aka H&M) Please excuse my typos and brevity. Sent from a Smartphone.