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

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

[Wolfgang Apolinarski]

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

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.

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.

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...
I somewhere read that 2048-bit RSA is faster than 256-bit curve.
We are using a 4096-bit RSA together with a 384-bit curve. Did anyone perform some measurements?

> 
> Did you see that conversation?

And I really thought that maybe my mail did not make it through after reading the patch...

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

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

[Peter Müller]

[-- 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  
> 

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

[Wolfgang Apolinarski]

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

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

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

[Michael Tremer]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Horace Michael]

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

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 <michael.tremer(a)ipfire.org> 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 <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-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. 

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

[Paul Simmons]

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

+1 Security

Thank you,
Paul


On Thu, 2017-11-09 at 23:17 +0000, 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
> 

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

[Peter Müller]

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

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/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 <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-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  
> > 
> >   

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

[Tom Rymes]

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

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?

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/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 <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-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  
>>> 
>>> 
> 

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

[Michael Tremer]

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

Hi,

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

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/File: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-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  
> > > > 
> > > > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Wolfgang Apolinarski]

[-- 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
> > > > >
> > > > >

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

[Peter Müller]

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

Hello *,

thanks for the discussion.

After all, staying compatible in the WebUI for the next time
is okay in my point of view. Maybe we can have a look at this
again in one year or a half one...

Best regards,
Peter Müller

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

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

[Matthias Fischer]

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

Hi,

We're on a firewall, so +1 for security from me.

Best,
Matthias

On 10.11.2017 00:17, 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 <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-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
>> 
>> 
> 

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

[Peter Müller]

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

Hello Wolfgang,

> 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).
Hm, yes, you have a point. I was not aware of these addons, nevertheless,
I voted for "better security". ;-) 
> 
> > 
> > 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.
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.
> 
> > >
> > > 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.
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.
> 
> 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ür Sicherheit in der Informationstechnik
(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 NIST curves
(256 and 384 bits) for the ECDSA key. They sometimes support other curves (such as
the 25519 mentioned) for the ECDHE key exchange, which we might enable for IPFire.

However, this needs some research, but it is on my todo list.
> 
> > 
> > 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
Updates - always in season, never out of style. :-)
> 
> 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."
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ü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-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  
> > >  
> 
>