Mailing List Archive: RFC: mod_ssl features to dump for 2.5

RFC: mod_ssl features to dump for 2.5

May 4, 2020, 6:49 AM

Post #1 of 7 (722 views)

I'd like to gauge consensus on removing the following mod_ssl features
for 2.5. I am +1 (more or less strongly) on removing all the following:

a) SSLInsecureRengotiation. If you haven't patched your clients for
CVE-2009-3555 there is no hope. This should definitely be removed.

b) SSLRequire - this has been deprecated since it was subsumed into the
better "Require expr" interface in 2.4.x.

c) Client-initiated renegotiation prevention mechanism. This was
introduced mostly as a temporary workaround for CVE-2009-3555, and as
the saying goes, there is nothing as permanent as a temporary
workaround. This already doesn't apply for TLSv1.3, and it doesn't
really add much for TLS < v1.3 so I think it can go completely.

d) SSLRandomSeed. This might have made sense in 1998 but at least with
OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd
should not be doing RAND seeding ever. Currently mod_ssl will splat
random stack data, time() and the pid into the RNG state for each new
connection. Unless someone can prove this is valuable and the OpenSSL
PRNG is somehow broken OOTB, I think this code + directive should be
dropped for OpenSSL 1.1.1+, including EGD support etc.

e) SSLCompression - enabling this has been considered (and documented
as) a bad idea for a good while. IMO we should have "SSLCompression
off" the hard-coded default and drop the directive.

Regards, Joe

Re: RFC: mod_ssl features to dump for 2.5 [ In reply to ]

covener at gmail

May 4, 2020, 6:59 AM

Post #2 of 7 (722 views)

Permalink

On Mon, May 4, 2020 at 9:49 AM Joe Orton <jorton@redhat.com> wrote:
>
> I'd like to gauge consensus on removing the following mod_ssl features
> for 2.5. I am +1 (more or less strongly) on removing all the following:
>
> a) SSLInsecureRengotiation. If you haven't patched your clients for
> CVE-2009-3555 there is no hope. This should definitely be removed.
>
> b) SSLRequire - this has been deprecated since it was subsumed into the
> better "Require expr" interface in 2.4.x.
>
> c) Client-initiated renegotiation prevention mechanism. This was
> introduced mostly as a temporary workaround for CVE-2009-3555, and as
> the saying goes, there is nothing as permanent as a temporary
> workaround. This already doesn't apply for TLSv1.3, and it doesn't
> really add much for TLS < v1.3 so I think it can go completely.

I am not familiar with this one in mod_ssl but I am familiar with the issue.
Does it generate distinctive log messages for TLS < 1.3 that are
useful for e.g. fail2ban?
Has OpenSSL caught up and can we directly kill client-initiated renegotiation?

>
> d) SSLRandomSeed. This might have made sense in 1998 but at least with
> OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd
> should not be doing RAND seeding ever. Currently mod_ssl will splat
> random stack data, time() and the pid into the RNG state for each new
> connection. Unless someone can prove this is valuable and the OpenSSL
> PRNG is somehow broken OOTB, I think this code + directive should be
> dropped for OpenSSL 1.1.1+, including EGD support etc.
>
> e) SSLCompression - enabling this has been considered (and documented
> as) a bad idea for a good while. IMO we should have "SSLCompression
> off" the hard-coded default and drop the directive.
>

+1 to the others they are long past any practical/transitional use

Re: RFC: mod_ssl features to dump for 2.5 [ In reply to ]

jorton at redhat

May 4, 2020, 7:53 AM

Post #3 of 7 (722 views)

Permalink

On Mon, May 04, 2020 at 09:59:24AM -0400, Eric Covener wrote:
> On Mon, May 4, 2020 at 9:49 AM Joe Orton <jorton@redhat.com> wrote:
> > c) Client-initiated renegotiation prevention mechanism. This was
> > introduced mostly as a temporary workaround for CVE-2009-3555, and as
> > the saying goes, there is nothing as permanent as a temporary
> > workaround. This already doesn't apply for TLSv1.3, and it doesn't
> > really add much for TLS < v1.3 so I think it can go completely.
>
> I am not familiar with this one in mod_ssl but I am familiar with the issue.
> Does it generate distinctive log messages for TLS < 1.3 that are
> useful for e.g. fail2ban?

Yes - APLOGNO(02042) is generated here.

> Has OpenSSL caught up and can we directly kill client-initiated renegotiation?

Great question. Looks like OpenSSL 1.1.1 added a new option flag,
SSL_OP_NO_RENEGOTIATION, which does exactly this, so we could use that
instead of the current code which has to track and intercept handshakes
manually. It also sends a TLS alert rather than simply aborting the
connection, so it's better behaved than the current code. I'll look at
switching over to this instead of dropping it instead. Thanks!

Regards, Joe

Re: RFC: mod_ssl features to dump for 2.5 [ In reply to ]

rpluem at apache

May 4, 2020, 8:23 AM

Post #4 of 7 (722 views)

Permalink

On 5/4/20 3:49 PM, Joe Orton wrote:
> I'd like to gauge consensus on removing the following mod_ssl features
> for 2.5. I am +1 (more or less strongly) on removing all the following:
>
> a) SSLInsecureRengotiation. If you haven't patched your clients for
> CVE-2009-3555 there is no hope. This should definitely be removed.

+1

>
> b) SSLRequire - this has been deprecated since it was subsumed into the
> better "Require expr" interface in 2.4.x.

+1

>
> c) Client-initiated renegotiation prevention mechanism. This was
> introduced mostly as a temporary workaround for CVE-2009-3555, and as
> the saying goes, there is nothing as permanent as a temporary
> workaround. This already doesn't apply for TLSv1.3, and it doesn't
> really add much for TLS < v1.3 so I think it can go completely.

+1 to the conclusion you did after Eric's post.

>
> d) SSLRandomSeed. This might have made sense in 1998 but at least with
> OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd
> should not be doing RAND seeding ever. Currently mod_ssl will splat
> random stack data, time() and the pid into the RNG state for each new
> connection. Unless someone can prove this is valuable and the OpenSSL
> PRNG is somehow broken OOTB, I think this code + directive should be
> dropped for OpenSSL 1.1.1+, including EGD support etc.

Do we drop it only for OpenSSL 1.1.1 or are there other older versions of OpenSSL where this is save to drop?
And if we drop how do we drop it? If we can only drop it for OpenSSL 1.1.1 I would be in favour
of sending a message to the log (INFO level) that it is just ignored. This avoids that a config working with OpenSSL < 1.1.1
fails with OpenSSL 1.1.1 but the same Apache version.

>
> e) SSLCompression - enabling this has been considered (and documented
> as) a bad idea for a good while. IMO we should have "SSLCompression
> off" the hard-coded default and drop the directive.

+1

Regards

Rüdiger

Re: RFC: mod_ssl features to dump for 2.5 [ In reply to ]

jorton at redhat

May 6, 2020, 3:44 AM

Post #5 of 7 (714 views)

Permalink

On Mon, May 04, 2020 at 05:23:23PM +0200, Ruediger Pluem wrote:
> On 5/4/20 3:49 PM, Joe Orton wrote:
> > d) SSLRandomSeed. This might have made sense in 1998 but at least with
> > OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd
> > should not be doing RAND seeding ever. Currently mod_ssl will splat
> > random stack data, time() and the pid into the RNG state for each new
> > connection. Unless someone can prove this is valuable and the OpenSSL
> > PRNG is somehow broken OOTB, I think this code + directive should be
> > dropped for OpenSSL 1.1.1+, including EGD support etc.
>
> Do we drop it only for OpenSSL 1.1.1 or are there other older versions of OpenSSL where this is save to drop?

From https://wiki.openssl.org/index.php/Random_fork-safety it seems like
there is some reason to believe the <1.1.1 RNG is not safe after fork
unless you help it.

I was looking at the Fedora default mod_ssl config which does have a
default "SSLRandom", but the example httpd-ssl.conf shipped does not. So
*maybe* configuring SSLRandomSeed is useful, but really if it is not
needed by default we should do something by default, which we don't.

(I feel like there should be a assumption in favour of correctness with
OpenSSL and any code which assumes incorrectness should have very strong
justification for its continued existence. Instead we have a tendency
to carry a lot of code merely because "we've always done it like this".)

> And if we drop how do we drop it? If we can only drop it for OpenSSL 1.1.1 I would be in favour
> of sending a message to the log (INFO level) that it is just ignored. This avoids that a config working with OpenSSL < 1.1.1
> fails with OpenSSL 1.1.1 but the same Apache version.

Very good idea, I'll do it like that. Thanks for the feedback!

Regards, Joe

Re: RFC: mod_ssl features to dump for 2.5 [ In reply to ]

jorton at redhat

May 6, 2020, 4:01 AM

Post #6 of 7 (714 views)

Permalink

On Wed, May 06, 2020 at 11:44:37AM +0100, Joe Orton wrote:
> On Mon, May 04, 2020 at 05:23:23PM +0200, Ruediger Pluem wrote:
> > On 5/4/20 3:49 PM, Joe Orton wrote:
> > > d) SSLRandomSeed. This might have made sense in 1998 but at least with
> > > OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd
> > > should not be doing RAND seeding ever. Currently mod_ssl will splat
> > > random stack data, time() and the pid into the RNG state for each new
> > > connection. Unless someone can prove this is valuable and the OpenSSL
> > > PRNG is somehow broken OOTB, I think this code + directive should be
> > > dropped for OpenSSL 1.1.1+, including EGD support etc.
> >
> > Do we drop it only for OpenSSL 1.1.1 or are there other older versions of OpenSSL where this is save to drop?
>
> From https://wiki.openssl.org/index.php/Random_fork-safety it seems like
> there is some reason to believe the <1.1.1 RNG is not safe after fork
> unless you help it.
>
> I was looking at the Fedora default mod_ssl config which does have a
> default "SSLRandom", but the example httpd-ssl.conf shipped does not. So
> *maybe* configuring SSLRandomSeed is useful, but really if it is not
> needed by default we should do something by default, which we don't.

^ Apologies for garbled grammar, I meant:

"if it IS needed by default, we should do something by default"

... and we *do* have something configured by default:

# Note: The following must must be present to support
# starting without SSL on platforms with no /dev/random equivalent
# but a statically compiled-in mod_ssl.
#
<IfModule ssl_module>
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
</IfModule>

but if OpenSSL does not have entropy source beyond that provided by
mod_ssl calling getpid() and time() it is IMO far better to fail to
start up.

So maybe we should still call RAND_status() and fail startup if the PRNG
is not initialized correctly?

Regards, Joe

Re: RFC: mod_ssl features to dump for 2.5 [ In reply to ]

giovanni at paclan

May 6, 2020, 4:04 AM

Post #7 of 7 (714 views)

Permalink

On 5/6/20 1:01 PM, Joe Orton wrote:
> On Wed, May 06, 2020 at 11:44:37AM +0100, Joe Orton wrote:
>> On Mon, May 04, 2020 at 05:23:23PM +0200, Ruediger Pluem wrote:
>>> On 5/4/20 3:49 PM, Joe Orton wrote:
>>>> d) SSLRandomSeed. This might have made sense in 1998 but at least with
>>>> OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd
>>>> should not be doing RAND seeding ever. Currently mod_ssl will splat
>>>> random stack data, time() and the pid into the RNG state for each new
>>>> connection. Unless someone can prove this is valuable and the OpenSSL
>>>> PRNG is somehow broken OOTB, I think this code + directive should be
>>>> dropped for OpenSSL 1.1.1+, including EGD support etc.
>>>
>>> Do we drop it only for OpenSSL 1.1.1 or are there other older versions of OpenSSL where this is save to drop?
>>
>> From https://wiki.openssl.org/index.php/Random_fork-safety it seems like
>> there is some reason to believe the <1.1.1 RNG is not safe after fork
>> unless you help it.
>>
>> I was looking at the Fedora default mod_ssl config which does have a
>> default "SSLRandom", but the example httpd-ssl.conf shipped does not. So
>> *maybe* configuring SSLRandomSeed is useful, but really if it is not
>> needed by default we should do something by default, which we don't.
>
> ^ Apologies for garbled grammar, I meant:
>
> "if it IS needed by default, we should do something by default"
>
> ... and we *do* have something configured by default:
>
> # Note: The following must must be present to support
> # starting without SSL on platforms with no /dev/random equivalent
> # but a statically compiled-in mod_ssl.
> #
> <IfModule ssl_module>
> SSLRandomSeed startup builtin
> SSLRandomSeed connect builtin
> </IfModule>
>
> but if OpenSSL does not have entropy source beyond that provided by
> mod_ssl calling getpid() and time() it is IMO far better to fail to
> start up.
>
> So maybe we should still call RAND_status() and fail startup if the PRNG
> is not initialized correctly?
>
I think we should fail startup, it's better to fail then to give the user a false sense of security and use a poor PRNG.

Giovanni