cancel
Showing results for 
Search instead for 
Did you mean: 

Optimal apache/modssl configuration for pool nodes to avoid slow/aborted SSL backend connections ?

Occasional Contributor

Optimal apache/modssl configuration for pool nodes to avoid slow/aborted SSL backend connections ?

We recently switched some backend pools from
http to https connections. Ever since, we are seeing
a growing number of "connfail" errors (connection reset
by peer).

I am now looking for the optimal (or better: fastest) setup for
encrypted connections between a VATM and the backend pool
nodes, especially for the setup of the apache 2.4/modssl combo

on the backends.

In our case, the backend traffic remains inside our network, so
we have only minimal requirements for encryption, while
connection setup and reuse, short handshake time, and low
CPU consumption are more important.

There are many SSL optimization tutorials, but mostly for
public facing sites. Is there any recommendation
endorsed by Brocade/Pulse staff?  Which connection parameters/
timeouts, Cipher Suites and certificates are recommended?

And what does work best for you people reading this?

 

 

Regards

Ulrich

4 REPLIES
Occasional Contributor

Re: Optimal apache/modssl configuration for pool nodes to avoid slow/aborted SSL backend connection

I have personally never needed to apply any specific tuning to either the Traffic Manager or Apache configuration when using such a setup.

 

Can you please provide more information about your setup?

  • Which version of the Virtual Traffic Manager are you using?
  • Which version of Apache 2.4 and OpenSSL is installed on the backends?
  • What protocol is the virtual server using?
  • Did you make any changes to the global or virtual server SSL settings on the traffic manager?
Occasional Contributor

Re: Optimal apache/modssl configuration for pool nodes to avoid slow/aborted SSL backend connection

Hello Matthias,

 

I have addressed the details of this problem (along with TSR files and logs) in the support case number 00307146 - you might have access to it (do you?) Since the ownership of that case changed recently,  I now hope to see progress there regarding the aborted connections.

 

This community post was meant to collect additional input about the optimal backend configuration, which is something that can be as well discussed in public and would make a good topic for a KB article. The default, even if the settings appear to work, might not be the optimal/fastest setup ...

 

Our nodes are plain debian (8.10) , with the following packages:

ii  apache2                           2.4.10-10+deb8u12                  amd64        Apache HTTP Server
ii  apache2-mpm-event                 2.4.10-10+deb8u12                  amd64        transitional event MPM package for apache2
(...)
ii  libgnutls-openssl27:amd64         3.3.8-6+deb8u7                     amd64        GNU TLS library - OpenSSL wrapper
ii  libssl-dev:amd64                  1.0.1t-1+deb8u8                    amd64        Secure Sockets Layer toolkit - development files
ii  libssl1.0.0:amd64                 1.0.1t-1+deb8u8                    amd64        Secure Sockets Layer toolkit - shared libraries
ii  openssl                           1.0.1t-1+deb8u8                    amd64        Secure Sockets Layer toolkit - cryptographic utility
ii  ssl-cert                          1.0.35                             all          simple debconf wrapper for OpenSSL
(...)

 

The VATM config is mostly default -  non-default settings are kept in the conf/settings.cfg , right? So these are the settings:

# grep ssl conf/settings.cfg
ssl!allow_rehandshake   safe
ssl!cache!expiry        1800
ssl!cipher_suites
ssl!support_ssl3        No

# grep ssl conf/vservers/VHOST-XXXX
log!ssl_failures       Yes
ssl_decrypt     Yes
ssl_headers     No
ssl_ocsp!issuer!_DEFAULT_!aia   Yes
ssl_ocsp!issuer!_DEFAULT_!nonce off
ssl_ocsp!issuer!_DEFAULT_!required      optional
ssl_ocsp!issuer!_DEFAULT_!responder_cert
ssl_ocsp!issuer!_DEFAULT_!signer
ssl_ocsp!issuer!_DEFAULT_!url
ssl_ocsp_stapling       No

On the nodes, we also kept the defaults:

 

# from ssl.conf :
 SSLCipherSuite HIGH:!aNULL
        # Default: Off
        #SSLHonorCipherOrder on
        #   The protocols to enable.
        #   Available values: all, SSLv3, TLSv1, TLSv1.1, TLSv1.2
        #   SSL v2  is no longer supported
 SSLProtocol all -SSLv3

There might be potential for optimizations  regarding the cipher suites, do you have any recommendations ?

Regards

Ulrich

 

 
Occasional Contributor

Re: Optimal apache/modssl configuration for pool nodes to avoid slow/aborted SSL backend connection

The provided SSL settings look good. The pool settings are however missing. If they are not changing any SSL settings the connections from the traffic manager to Apache should use an AES-GCM cipher which is both safe and fast.

 

Can you please check ssl.conf for the necessary configuration directives to enable SSL session resumption in Apache? It could look something like this:

 

SSLSessionCache   shmcb:${APACHE_RUN_DIR}/ssl_scache(4194304)
SSLSessionCacheTimeout  1800

 

Highlighted
Occasional Contributor

Re: Optimal apache/modssl configuration for pool nodes to avoid slow/aborted SSL backend connection

Hello,

 

Paul Wallace and I have published a document Tuning Recommendations for using the Traffic Manager with Apache Backends which will hopefully answer some of your questions.