Hi Michael, > > 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? > > > > 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 release. > 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 tell 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 arguments are less important here because > nobody has tens of thousands of people using the webUI at the same time... I would agree here (actually, I wanted to write a similar text). Otherwise, I would not have suggested to stay with compatibility until next year. Nevertheless, I can live with the other option as well. Best regards, Wolfgang > > Best, > -Michael > > > > > Tom > > > > > On Nov 11, 2017, at 2:33 PM, Peter Müller wrote: > > > > > > Hello Peter, hello Wolfgang, > > > > > > +1 for security, too. > > > > > > However, it might be good to warn the users (planet post, etc.) some > > > time before we release a new version which changes this. > > > > > > 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!). > > > > > > Best regards, > > > Peter Müller > > > > > > > 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/Fil > > > > > e:Androi d_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-AE > > > > > > > > > S256- > > > > > > > > > SHA38 > > > > > > > > > 4:EC > > > > > > > > > DHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-R > > > > > > > > > SA- > > > > > > > > > AES128- > > > > > > > > > SHA2 > > > > > > > > > 56:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDH > > > > > > > > > E-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-RS > > > > > > > > > + A- > > > > > > > > > AES128-S > > > > > > > > > + HA25 > > > > > > > > > + 6 > > > > > > > > > SSLHonorCipherOrder on > > > > > > > > > SSLCertificateFile /etc/httpd/server.crt > > > > > > > > > SSLCertificateKeyFile /etc/httpd/server.key > > > > > > > > > >