AW: [PATCH] change Apache TLS cipher list to "Mozilla Modern"

[Wolfgang Apolinarski <wolfgang.apolinarski@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 13140 bytes --]

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 <peter.mueller(a)link38.eu> 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 <peter.mueller(a)link38.eu>
> > > > > > > > > ---
> > > > > > > > > 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
> > > > >
> > > > >