Re: SSL/TLS best current practice
Here's my proposed comment to inject in trunk/2.4/2.2 default httpd-ssl.conf - any adjustments here? # httpd 2.2.30, 2.4.13 and later force-disable aNULL, eNULL and EXP ciphers, # while OpenSSL disabled these by default in 0.9.8zf/1.0.0r/1.0.1m/1.0.2a. +1 Agreed +1. That's nice and informative. I couldn't tell from the discussion if this config was being pushed in to 2.2. It is? If so, that's great. It'll help me justify pushing it to our customer shipping installations.
Re: SSL/TLS best current practice
On Tue, May 26, 2015 at 11:45 AM, Andy Wang aw...@ptc.com wrote: On 05/26/2015 11:25 AM, William A Rowe Jr wrote: On Tue, May 26, 2015 at 10:45 AM, Yann Ylavic ylavic@gmail.com mailto:ylavic@gmail.com wrote: On Tue, May 26, 2015 at 5:29 PM, Andy Wang aw...@ptc.com mailto:aw...@ptc.com wrote: # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4 SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4 !aNULL isn't needed? No since !aNULL:!eNULL:!EXP is forcibly added to the configured ciphersuite. A legitimate question, however. The example should document this IMHO. Getting right on that. I initially thought openssl disabled the NULL ones by default but when i started playing with openssl cipher strings and saw them I got confused. Didn't even consider that httpd did it automatically. Documenting it would be a nice touch. Thanks for doing that. As it turns out, 0.9.2b disabled aNULL/eNULL by default. Export ciphers are disabled by default as of 0.9.8zf/1.0.0r/1.0.1m/1.0.2a. Here's my proposed comment to inject in trunk/2.4/2.2 default httpd-ssl.conf - any adjustments here? # httpd 2.2.30, 2.4.13 and later force-disable aNULL, eNULL and EXP ciphers, # while OpenSSL disabled these by default in 0.9.8zf/1.0.0r/1.0.1m/1.0.2a.
Re: SSL/TLS best current practice
On Wed, May 27, 2015 at 5:58 PM, William A Rowe Jr wr...@rowe-clan.net wrote: On Tue, May 26, 2015 at 11:45 AM, Andy Wang aw...@ptc.com wrote: I initially thought openssl disabled the NULL ones by default but when i started playing with openssl cipher strings and saw them I got confused. Didn't even consider that httpd did it automatically. Documenting it would be a nice touch. Thanks for doing that. As it turns out, 0.9.2b disabled aNULL/eNULL by default. Yes, if you don't specify any ciphersuite (ie. no SSLCipherSuite in httpd). Export ciphers are disabled by default as of 0.9.8zf/1.0.0r/1.0.1m/1.0.2a. AFAICT, they are not even selectable (not in ALL and EXP is ignored)... Here's my proposed comment to inject in trunk/2.4/2.2 default httpd-ssl.conf - any adjustments here? # httpd 2.2.30, 2.4.13 and later force-disable aNULL, eNULL and EXP ciphers, # while OpenSSL disabled these by default in 0.9.8zf/1.0.0r/1.0.1m/1.0.2a. +1
Re: SSL/TLS best current practice
On Tue, May 26, 2015 at 10:45 AM, Yann Ylavic ylavic@gmail.com wrote: On Tue, May 26, 2015 at 5:29 PM, Andy Wang aw...@ptc.com wrote: # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4 SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4 !aNULL isn't needed? No since !aNULL:!eNULL:!EXP is forcibly added to the configured ciphersuite. A legitimate question, however. The example should document this IMHO. Getting right on that.
Re: SSL/TLS best current practice
On Tue, May 26, 2015 at 5:29 PM, Andy Wang aw...@ptc.com wrote: --- # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4 SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4 !aNULL isn't needed? No since !aNULL:!eNULL:!EXP is forcibly added to the configured ciphersuite.
Re: SSL/TLS best current practice
--- # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4 SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4 !aNULL isn't needed?
Re: SSL/TLS best current practice
On 05/26/2015 11:25 AM, William A Rowe Jr wrote: On Tue, May 26, 2015 at 10:45 AM, Yann Ylavic ylavic@gmail.com mailto:ylavic@gmail.com wrote: On Tue, May 26, 2015 at 5:29 PM, Andy Wang aw...@ptc.com mailto:aw...@ptc.com wrote: # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4 SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4 !aNULL isn't needed? No since !aNULL:!eNULL:!EXP is forcibly added to the configured ciphersuite. A legitimate question, however. The example should document this IMHO. Getting right on that. I initially thought openssl disabled the NULL ones by default but when i started playing with openssl cipher strings and saw them I got confused. Didn't even consider that httpd did it automatically. Documenting it would be a nice touch. Thanks for doing that. Andy
Re: SSL/TLS best current practice
On 05/06/2015 07:22 PM, William A Rowe Jr wrote: Here is my proposed global config for httpd.conf.in http://httpd.conf.in for 2.4 and 2.2, which I believe mirrors the 'MUST' of RFC 7525. So new default configs are improved, and that's great. Any joint interest in maintaining a guide to implementing SSL/TLS best practices in the documentation for those that don't normally see our latest/greatest default configuration and/or need some extra prose around it? A start would be: * list source material for best practices * describe how known tradeoffs (such as blocking old clients) are accommodated in the specific configuration recommendations * the actual configuration related to best SSL/TLS practices from our current default SSL configs * hints on how to configure these in our past releases as well as with distributions that have their own idea of file layout/own defaults
Re: SSL/TLS best current practice
On 23 May 2015, at 12:50, Jeff Trawick traw...@gmail.com wrote: On 05/06/2015 07:22 PM, William A Rowe Jr wrote: Here is my proposed global config for httpd.conf.in for 2.4 and 2.2, which I believe mirrors the 'MUST' of RFC 7525. So new default configs are improved, and that's great. Any joint interest in maintaining a guide to implementing SSL/TLS best practices in the documentation for those that don't normally see our latest/greatest default configuration and/or need some extra prose around it? I can help with this. -- Tim Bannister - is...@c8h10n4o2.org.uk
Re: SSL/TLS best current practice
Thanks Christian. On 11/05/2015 01:57, Christian Seiler wrote: On 05/10/2015 03:26 AM, Noel Butler wrote: Can any SUSE and debian users confirm the current supported stable release supports 1.2? Currently, three Debian releases are still supported: - Debian Jessie (current stable) * released 2015-04 - main support will end 2018-05 - possibly LTS until 2020-04 * ships Apache 2.4.10 * ships OpenSSL 1.0.1k + patches * supports TLS v1.2 chipers - Debian Wheezy (oldstable) * release 2013-05 - main support will end 2016-02 - probably LTS until 2018-05 * ships Apache 2.2.22 + patches * ships OpenSSL 1.0.1e + patches * supports TLS v1.2 chipers - Debian Squeeze (oldoldstable) * release 2011-02 * only x86 architectures still supported (long term support, LTS) and there not all packages (but Apache and OpenSSL still are) - LTS will end 2016-02 * ships Apache 2.2.16 + patches * ships OpenSSL 0.9.8o + patches * only supports SSLv3 chipers (esp. no SHA2 family hashes) Note that Debian Jessie's Apache default configuration already comes with: SSLCipherSuite HIGH:!aNULL SSLProtocol all -SSLv3 Christian
Re: SSL/TLS best current practice
On 05/10/2015 03:26 AM, Noel Butler wrote: Can any SUSE and debian users confirm the current supported stable release supports 1.2? Currently, three Debian releases are still supported: - Debian Jessie (current stable) * released 2015-04 - main support will end 2018-05 - possibly LTS until 2020-04 * ships Apache 2.4.10 * ships OpenSSL 1.0.1k + patches * supports TLS v1.2 chipers - Debian Wheezy (oldstable) * release 2013-05 - main support will end 2016-02 - probably LTS until 2018-05 * ships Apache 2.2.22 + patches * ships OpenSSL 1.0.1e + patches * supports TLS v1.2 chipers - Debian Squeeze (oldoldstable) * release 2011-02 * only x86 architectures still supported (long term support, LTS) and there not all packages (but Apache and OpenSSL still are) - LTS will end 2016-02 * ships Apache 2.2.16 + patches * ships OpenSSL 0.9.8o + patches * only supports SSLv3 chipers (esp. no SHA2 family hashes) Note that Debian Jessie's Apache default configuration already comes with: SSLCipherSuite HIGH:!aNULL SSLProtocol all -SSLv3 Christian
Re: SSL/TLS best current practice
On 07/05/2015 12:17, William A Rowe Jr wrote: On May 6, 2015 9:09 PM, William A Rowe Jr wr...@rowe-clan.net wrote: On May 6, 2015 8:12 PM, Noel Butler noel.but...@ausics.net wrote: On 07/05/2015 09:22, William A Rowe Jr wrote: For trunk, I propose we drop TLSv1 and TLSv1.1 protocols and simply adopt the recommended cipher list illustrated below (!SSLv3) in the default extra/httpd-ssl.conf source, following the SHOULD recommendations. unless trunk is for the 2.6 release -1 Noel, that is precisely the purpose of trunk, always. The 'next' release. Might be 2.6, might be called 3.0. And if you pay particularly close attention, you'll note that trunk already presents itself as 2.5.0-dev, its version number when we first attempt an alpha toward 2.6 or 3.0, sometime is the future. yes, I had a bad (few) day then - flu Either way, using slackware on all my servers its trivial since the distro keeps pretty much up to date by design - unlike RH/debian and their kiddy versions who bring out new releases with 2+yo libs and other goodies, I'd just hesitate to drop them, wait and see whats capable in their current enterprise releases when the time comes to make that decision, since RH is most used enterprise release, I'm going to contradict myself here - since it's always been my belief that upstreams should never base their decisions on downstreams (like ASF does WRT deprecating 2.2) but if RH for example's new release at the time doesn't support 1.2, its pointless dropping 1.0/1.1 Dont get me wrong, I think RH, debian, and to a point even SUSE, are the ones who need to pull their finger out and modernise (been 10 years since I touched/looked at a BSD box so wont comment on the state of them) But... maybe... you are right... making the statement now that come 2.6 (I'd rather see it in a new major - like 3.x) that if those guys cant get their act together by then, they got nobody to blame but themselves.
Re: SSL/TLS best current practice
On 10/05/2015 11:08, Reindl Harald wrote: Am 10.05.2015 um 03:02 schrieb Noel Butler: Either way, using slackware on all my servers its trivial since the distro keeps pretty much up to date by design - unlike RH/debian and their kiddy versions who bring out new releases with 2+yo libs and other goodies, I'd just hesitate to drop them, wait and see whats capable in their current enterprise releases when the time comes to make that decision, since RH is most used enterprise release, I'm going to contradict myself here - since it's always been my belief that upstreams should never base their decisions on downstreams (like ASF does WRT deprecating 2.2) but if RH for example's new release at the time doesn't support 1.2, its pointless dropping 1.0/1.1 Redhat already supports 1.2, not only thew new RHEL7, also up-to-date RHEL6, only RHEL5 which is still supported is behind and that's just because that's the whole purpose of a LTS distribution Thats good to know, thanks you. Can any SUSE and debian users confirm the current supported stable release supports 1.2? If so, then by objection is withdrawn Bill :)
Re: SSL/TLS best current practice
Am 10.05.2015 um 03:02 schrieb Noel Butler: Either way, using slackware on all my servers its trivial since the distro keeps pretty much up to date by design - unlike RH/debian and their kiddy versions who bring out new releases with 2+yo libs and other goodies, I'd just hesitate to drop them, wait and see whats capable in their current enterprise releases when the time comes to make that decision, since RH is most used enterprise release, I'm going to contradict myself here - since it's always been my belief that upstreams should never base their decisions on downstreams (like ASF does WRT deprecating 2.2) but if RH for example's new release at the time doesn't support 1.2, its pointless dropping 1.0/1.1 Redhat already supports 1.2, not only thew new RHEL7, also up-to-date RHEL6, only RHEL5 which is still supported is behind and that's just because that's the whole purpose of a LTS distribution [root@localhost:~]$ rpm -q openssl openssl-1.0.1e-30.el6.8.x86_64 [root@localhost:~]$ openssl ciphers -v ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHASSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1 ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1 AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHASSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1 DHE-RSA-SEED-SHASSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 DHE-DSS-SEED-SHASSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-RSA-DES-CBC3-SHA SSLv3
Re: SSL/TLS best current practice
Here is my proposed global config for httpd.conf.in for 2.4 and 2.2, which I believe mirrors the 'MUST' of RFC 7525. This includes restoring the SSLProtocol -SSLv3 for 2.4 so that it is plainly visible, irrespective of system defaults. For trunk, I propose we drop TLSv1 and TLSv1.1 protocols and simply adopt the recommended cipher list illustrated below (!SSLv3) in the default extra/httpd-ssl.conf source, following the SHOULD recommendations. Comments? --- # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4 SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4 # Effective 2017, only TLSv1.2 ciphers should be in use. # Older ciphers should be disallowed as soon as possible, however # much older clients (such as IE6 SP2 on XP) may still be in use. # Replace the SSLCipherSuite and SSLProxyCipherSuite directives # above with these directives to restrict mod_ssl to TLSv1.2 ciphers # as soon as practical. # SSLCipherSuite HIGH:MEDIUM:!SSLv3 # SSLProxyCipherSuite HIGH:MEDIUM:!SSLv3 # As user agents such as web browsers are not configured for the user's # own preference of either security or performance, and in every case # this should be the prerogative of the web server administrator who must # manage cpu load, enforce server's preferred cipher order. SSLHonorCipherOrder on # SSL Protocol support: # List the protocol versions which clients are allowed to connect with. # Disable SSLv2 and SSLv3 by default (cf. RFC 7525 3.1.1). TLSv1 (1.0) # should be disabled as quickly as practical. By 2017, only the TLSv1.2 # protocol or later should remain in use. SSLProtocol all -SSLv2 -SSLv3 SSLProxyProtocol all -SSLv2 -SSLv3 On Wed, May 6, 2015 at 4:32 AM, Steffen i...@apachelounge.com wrote: Maybe already known. The SSL/TLS best current practice RFC has been approved : https://www.rfc-editor.org/rfc/rfc7525.txt Steffen
Re: SSL/TLS best current practice
On May 6, 2015 9:09 PM, William A Rowe Jr wr...@rowe-clan.net wrote: On May 6, 2015 8:12 PM, Noel Butler noel.but...@ausics.net wrote: On 07/05/2015 09:22, William A Rowe Jr wrote: For trunk, I propose we drop TLSv1 and TLSv1.1 protocols and simply adopt the recommended cipher list illustrated below (!SSLv3) in the default extra/httpd-ssl.conf source, following the SHOULD recommendations. unless trunk is for the 2.6 release -1 Noel, that is precisely the purpose of trunk, always. The 'next' release. Might be 2.6, might be called 3.0. And if you pay particularly close attention, you'll note that trunk already presents itself as 2.5.0-dev, its version number when we first attempt an alpha toward 2.6 or 3.0, sometime is the future.
Re: SSL/TLS best current practice
On 07/05/2015 09:22, William A Rowe Jr wrote: For trunk, I propose we drop TLSv1 and TLSv1.1 protocols and simply adopt the recommended cipher list illustrated below (!SSLv3) in the default extra/httpd-ssl.conf source, following the SHOULD recommendations. unless trunk is for the 2.6 release -1 Since we are told, every time the discussion of abandoning 2.2.x comes up, that too many distro's with LTS's and Enterprise versions still support and maintain these antique versions, many admins do also require those antique distro versions but elect to build current source of httpd, I would then -1 for removal of tls 1.0/1.1 (unless for the new major release where I'd agree with it) - because if there systems are that old, they may very well have issues with the removal of them, since their overall system/ssl libs are going to also be antiques :)
Re: SSL/TLS best current practice
On May 6, 2015 8:12 PM, Noel Butler noel.but...@ausics.net wrote: On 07/05/2015 09:22, William A Rowe Jr wrote: For trunk, I propose we drop TLSv1 and TLSv1.1 protocols and simply adopt the recommended cipher list illustrated below (!SSLv3) in the default extra/httpd-ssl.conf source, following the SHOULD recommendations. unless trunk is for the 2.6 release -1 Noel, that is precisely the purpose of trunk, always. The 'next' release. Might be 2.6, might be called 3.0. We cherry pick fixes to backport all the time, but trunk exists to shape the subsequent release. Since we are told, every time the discussion of abandoning 2.2.x comes up, that too many distro's with LTS's and Enterprise versions still support and maintain these antique versions, many admins do also require those antique distro versions but elect to build current source of httpd, I would then -1 for removal of tls 1.0/1.1 (unless for the new major release where I'd agree with it) - because if there systems are that old, they may very well have issues with the removal of them, since their overall system/ssl libs are going to also be antiques :) Which is where you should direct your attention to backport proposals, on 2.4 as well as 2.2, since these are now adopted by users.
