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