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

[Horace Michael <horace.michael@gmx.com>]

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