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

["Peter Müller" <peter.mueller@link38.eu>]

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

Hello Wolfgang,

sorry for replying that late - at the moment I am quite busy. :-|

> Hi Michael and Peter,
> 
> > 
> > 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.

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.

(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.
> 
> 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.
> 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

Thereof I assume ECDSA keys perform usually better than RSA ones, especially
when it comes to server CPU time.
> 
> > 
> > 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?

Best regards,
Peter Müller
> 
> 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-AES256-SHA384: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-AES256-S
> > > HA384:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:
> > > CAMELLIA128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256
> > > -SHA
> > > +    SSLCipherSuite
> > > + ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-EC
> > > + DSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-S
> > > + HA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-
> > > + RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA25
> > > + 6
> > >      SSLHonorCipherOrder on
> > >      SSLCertificateFile /etc/httpd/server.crt
> > >      SSLCertificateKeyFile /etc/httpd/server.key  
>