You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2011/08/02 22:39:46 UTC
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
On 7/31/2011 4:17 AM, Kaspar Brand wrote:
> Hi Rainer,
>
>> There was a similar discussion "RFC: drop support for OpenSSL < 1.0 in
>> trunk/2.3?" on this list in May/June 2010.
>
> Thanks for the pointer! (Too long ago for me to remember, but should
> have searched the archives, that's true.)
>
>> - drop support for OpenSSL < 0.9.7a
>> - drop support for non-OpenSSL/derivatives of OpenSSL
>
> Ok, then my next step is working on a patch which takes care of these
> two points, I guess.
+1
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by Kaspar Brand <ht...@velox.ch>.
On 11.08.2011 11:34, NormW wrote:
> On 11/08/2011 3:12 PM, Kaspar Brand wrote:
>> That's also fine with me, yes. Generally speaking, are there any rules
>> for handling this sort of version checks in httpd code (and when
>> aborting with #error is acceptable)?
> No idea if a 'rule' but a search of httpd-trunk *.c for #error shows 12
> 'samples' that might be worth a look.
Ok, based on the modules/session/mod_session_crypto.c "precedent", I
have added an "#if (OPENSSL_VERSION_NUMBER < 0x0090700f)" check to
modules/ssl/ssl_private.h in r1157575.
Additionally, mod_ssl will now emit a warning at runtime if httpd is
started with an OpenSSL library version older than the one it was
originally compiled against.
Kaspar
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by NormW <no...@gknw.net>.
On 11/08/2011 3:12 PM, Kaspar Brand wrote:
> Hi Gün,
>
>> perhaps we should just break compilation with a check in mod_ssl like:
>> #if OPENSSL_VERSION_NUMBER< 0x0090700f
>> #error mod_ssl requires at least OpenSSL version 0.9.7f!
>> #endif
>
> That's also fine with me, yes. Generally speaking, are there any rules
> for handling this sort of version checks in httpd code (and when
> aborting with #error is acceptable)?
No idea if a 'rule' but a search of httpd-trunk *.c for #error shows 12
'samples' that might be worth a look.
> (Nit: 0x0090700f is actually 0.9.7, 0.9.7f would be 0x0090706f.)
>
>> BTW. I admit that I did only tested compile, not runtime; though if
>> there are issues introduced with your changes they should come up with
>> all platforms, or?
>
> I would expect so, yes - as long as OpenSSL behaves the same on NetWare
> as on other platforms.
> Kaspar
Norm
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by Kaspar Brand <ht...@velox.ch>.
Hi Gün,
> perhaps we should just break compilation with a check in mod_ssl like:
> #if OPENSSL_VERSION_NUMBER < 0x0090700f
> #error mod_ssl requires at least OpenSSL version 0.9.7f!
> #endif
That's also fine with me, yes. Generally speaking, are there any rules
for handling this sort of version checks in httpd code (and when
aborting with #error is acceptable)?
(Nit: 0x0090700f is actually 0.9.7, 0.9.7f would be 0x0090706f.)
> BTW. I admit that I did only tested compile, not runtime; though if
> there are issues introduced with your changes they should come up with
> all platforms, or?
I would expect so, yes - as long as OpenSSL behaves the same on NetWare
as on other platforms.
Kaspar
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by Guenter Knauf <fu...@apache.org>.
Hi Kaspar,
Am 10.08.2011 08:54, schrieb Kaspar Brand:
> thanks for testing! I was wondering if there's some way to check for
> OPENSSL_VERSION_NUMBER>= 0x0090700f in the NWGNUmakefile (similar to
> what is done in configure). Just in case someone tries to compile
> against stone-age versions of OpenSSL/NTLS... but perhaps this is a very
> unlikely scenario, so not worth bothering about.
sure, that would be possible with some awk magic, but I really see no
need for that;
perhaps we should just break compilation with a check in mod_ssl like:
#if OPENSSL_VERSION_NUMBER < 0x0090700f
#error mod_ssl requires at least OpenSSL version 0.9.7f!
#endif
?
BTW. I admit that I did only tested compile, not runtime; though if
there are issues introduced with your changes they should come up with
all platforms, or?
Gün.
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by Kaspar Brand <ht...@velox.ch>.
Hi Gün,
thanks for testing! I was wondering if there's some way to check for
OPENSSL_VERSION_NUMBER >= 0x0090700f in the NWGNUmakefile (similar to
what is done in configure). Just in case someone tries to compile
against stone-age versions of OpenSSL/NTLS... but perhaps this is a very
unlikely scenario, so not worth bothering about.
Kaspar
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by Guenter Knauf <fu...@apache.org>.
Hi Kaspar,
Am 07.08.2011 22:23, schrieb Guenter Knauf:
> Am 07.08.2011 12:49, schrieb Kaspar Brand:
>> NetWare folks: please note that I didn't touch modules/ssl/NWGNUmakefile
>> so far - i.e. it still allows building with the "Novell NTLS SDK" (in
>> theory, at least). As I'm neither familiar with the NetWare platform nor
>> do I have a test environment, I'd appreciate if the experts could have a
>> look - and patch, if needed. Thanks!
> shouldnt be a prob - latest NTLS is based on OpenSSL 0.9.7m - so
> shouldnt be an issue; but I will check ...
compiles without issue with latest NTLS, OpenSSL 0.9.8r, and OpenSSL 1.0.0d.
Gün.
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by Guenter Knauf <fu...@apache.org>.
Hi Kaspar,
Am 07.08.2011 12:49, schrieb Kaspar Brand:
> NetWare folks: please note that I didn't touch modules/ssl/NWGNUmakefile
> so far - i.e. it still allows building with the "Novell NTLS SDK" (in
> theory, at least). As I'm neither familiar with the NetWare platform nor
> do I have a test environment, I'd appreciate if the experts could have a
> look - and patch, if needed. Thanks!
shouldnt be a prob - latest NTLS is based on OpenSSL 0.9.7m - so
shouldnt be an issue; but I will check ...
thanks!
Gün.
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by Kaspar Brand <ht...@velox.ch>.
On 05.08.2011 17:39, William A. Rowe Jr. wrote:
> On 8/5/2011 2:57 AM, Stefan Fritsch wrote:
>> On Friday 05 August 2011, Kaspar Brand wrote:
>>> On 03.08.2011 19:08, William A. Rowe Jr. wrote:
>>>> My thought, it probably should be a set of commits;
>>>>
>>>> * Drop SSLC (first patch)
>>>> * Drop OpenSSL < 0.9.7 (second patch)
>>>> * Drop ssl_toolkit_compat wrapper (third patch)
>>>> * Warn on 0.9.7 and some 0.9.8 flavors (last patch)
>>>
>>> Ok, I'll try splitting it into more digestible pieces. Do you
>>> suggest committing them at the same time then, or possibly wait a
>>> few days in between (in case someone wants to build from the
>>> interim versions)?
>>
>> I don't think waiting is necessary. People can always check out an
>> interim revision if they want.
>
> Precisely. This just makes it easier to follow the activity through
> svn history.
Committed as r1154683 (drop SSL-C support), r1154687 (remove
ssl_toolkit_compat layer), and r1154688 (require OpenSSL 0.9.7).
Right now, configure no longer warns about specific older OpenSSL
versions - it just checks for OPENSSL_VERSION_NUMBER >= 0x0090700f.
Keeping track of vulnerable versions would possibly require frequent
updates to acinclude.m4 (also in 2.2.x, of course), and second, I'm not
sure how many people really have a close look at the configure output.
NetWare folks: please note that I didn't touch modules/ssl/NWGNUmakefile
so far - i.e. it still allows building with the "Novell NTLS SDK" (in
theory, at least). As I'm neither familiar with the NetWare platform nor
do I have a test environment, I'd appreciate if the experts could have a
look - and patch, if needed. Thanks!
Kaspar
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 8/5/2011 2:57 AM, Stefan Fritsch wrote:
> On Friday 05 August 2011, Kaspar Brand wrote:
>> On 03.08.2011 19:08, William A. Rowe Jr. wrote:
>>> My thought, it probably should be a set of commits;
>>>
>>> * Drop SSLC (first patch)
>>> * Drop OpenSSL < 0.9.7 (second patch)
>>> * Drop ssl_toolkit_compat wrapper (third patch)
>>> * Warn on 0.9.7 and some 0.9.8 flavors (last patch)
>>
>> Ok, I'll try splitting it into more digestible pieces. Do you
>> suggest committing them at the same time then, or possibly wait a
>> few days in between (in case someone wants to build from the
>> interim versions)?
>
> I don't think waiting is necessary. People can always check out an
> interim revision if they want.
Precisely. This just makes it easier to follow the activity through
svn history.
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Friday 05 August 2011, Kaspar Brand wrote:
> On 03.08.2011 19:08, William A. Rowe Jr. wrote:
> > My thought, it probably should be a set of commits;
> >
> > * Drop SSLC (first patch)
> > * Drop OpenSSL < 0.9.7 (second patch)
> > * Drop ssl_toolkit_compat wrapper (third patch)
> > * Warn on 0.9.7 and some 0.9.8 flavors (last patch)
>
> Ok, I'll try splitting it into more digestible pieces. Do you
> suggest committing them at the same time then, or possibly wait a
> few days in between (in case someone wants to build from the
> interim versions)?
I don't think waiting is necessary. People can always check out an
interim revision if they want.
Re: mod_ssl and OPENSSL_NO_SSL_INTERN (Re: mod_ssl in trunk with
OpenSSL 0.9.7 as a minimum requirement?)
Posted by Kaspar Brand <ht...@velox.ch>.
On 23.12.2011 18:13, Dr Stephen Henson wrote:
> Your patch to trunk/2.4.x looks fine. You can simplify the clearing of the extra
> chain slightly by just unconditionally calling: [...]
Thanks, patch adapted and committed in r1222917 and r1222920, respectively.
Kaspar
Re: mod_ssl and OPENSSL_NO_SSL_INTERN (Re: mod_ssl in trunk with
OpenSSL 0.9.7 as a minimum requirement?)
Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.
On 23/12/2011 07:52, Kaspar Brand wrote:
> On 22.12.2011 17:53, Dr Stephen Henson wrote:
>> I've added a few new controls and one new function which should resolve this,
>> see last few commits.
>>
>> I deleted a couple of functions duplicating functionality too.
>>
>> Let me know if you need further details or it needs fixing.
>
> Thanks for the very prompt reaction. With the attached changes to ssl.h,
> works fine for me. If you agree with these, my plan would be to commit
> the attached patch to trunk/2.4.x. Comments welcome.
>
OK, thanks. I've fixed the two typos now.
Your patch to trunk/2.4.x looks fine. You can simplify the clearing of the extra
chain slightly by just unconditionally calling:
SSL_CTX_clear_extra_chain_certs(ctx);
which will just be a no op if the chain is empty.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shenson@opensslfoundation.com
Re: mod_ssl and OPENSSL_NO_SSL_INTERN (Re: mod_ssl in trunk with
OpenSSL 0.9.7 as a minimum requirement?)
Posted by Kaspar Brand <ht...@velox.ch>.
On 22.12.2011 17:53, Dr Stephen Henson wrote:
> I've added a few new controls and one new function which should resolve this,
> see last few commits.
>
> I deleted a couple of functions duplicating functionality too.
>
> Let me know if you need further details or it needs fixing.
Thanks for the very prompt reaction. With the attached changes to ssl.h,
works fine for me. If you agree with these, my plan would be to commit
the attached patch to trunk/2.4.x. Comments welcome.
Kaspar
Re: mod_ssl and OPENSSL_NO_SSL_INTERN (Re: mod_ssl in trunk with
OpenSSL 0.9.7 as a minimum requirement?)
Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.
On 22/12/2011 10:59, Kaspar Brand wrote:
> On 05.08.2011 07:41, Kaspar Brand wrote:
>> On 03.08.2011 19:29, Dr Stephen Henson wrote:
>>> In OpenSSL 1.0.1 (unreleased) and later there is a feature to make all SSL
>>> related structures opaque and only allow them to be accessed through functions.
>>> This is enabled by setting OPENSSL_NO_SSL_INTERN before including any OpenSSL
>>> headers.
>>
>> Thanks for this information, this definitely seems a desirable goal for
>> mod_ssl in the long term (pity it wasn't added to OpenSSL earlier).
>
> Ok, so now that OpenSSL 1.0.1 doesn't seem too far away, I had a closer
> look. With trunk/2.4.x, things are already in pretty good shape, I think.
>
>> I haven't had time to try getting mod_ssl to work with this option. It is
>> guaranteed to fail without some modification. There may well be some
>> functionality missing in OpenSSL too.
>
> For mod_ssl, after some tweaking, two things are basically missing with
> the current 1.0.1 snapshots:
>
> 1) access to the SSL_CTX's "extra_certs". Currently there's only
> SSL_CTX_add_extra_chain_cert(), but no way to get at the currently
> configured stack of certs, and no option to clear that stack. mod_ssl
> needs this for ssl_util_stapling.c:stapling_get_issuer(),
> ssl_engine_init.c:ssl_init_ctx_pkcs7_cert_chain(), and
> ssl_util_ssl.c:SSL_CTX_use_certificate_chain().
>
> 2) access to the SSL_SESSION's "compress_meth" (read-only). Used in
> ssl_engine_vars.c:ssl_var_lookup_ssl_compress_meth().
>
> Is there a chance to add these for the initial 1.0.1 release?
>
I've added a few new controls and one new function which should resolve this,
see last few commits.
I deleted a couple of functions duplicating functionality too.
Let me know if you need further details or it needs fixing.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shenson@opensslfoundation.com
mod_ssl and OPENSSL_NO_SSL_INTERN (Re: mod_ssl in trunk with OpenSSL
0.9.7 as a minimum requirement?)
Posted by Kaspar Brand <ht...@velox.ch>.
On 05.08.2011 07:41, Kaspar Brand wrote:
> On 03.08.2011 19:29, Dr Stephen Henson wrote:
>> In OpenSSL 1.0.1 (unreleased) and later there is a feature to make all SSL
>> related structures opaque and only allow them to be accessed through functions.
>> This is enabled by setting OPENSSL_NO_SSL_INTERN before including any OpenSSL
>> headers.
>
> Thanks for this information, this definitely seems a desirable goal for
> mod_ssl in the long term (pity it wasn't added to OpenSSL earlier).
Ok, so now that OpenSSL 1.0.1 doesn't seem too far away, I had a closer
look. With trunk/2.4.x, things are already in pretty good shape, I think.
> I haven't had time to try getting mod_ssl to work with this option. It is
> guaranteed to fail without some modification. There may well be some
> functionality missing in OpenSSL too.
For mod_ssl, after some tweaking, two things are basically missing with
the current 1.0.1 snapshots:
1) access to the SSL_CTX's "extra_certs". Currently there's only
SSL_CTX_add_extra_chain_cert(), but no way to get at the currently
configured stack of certs, and no option to clear that stack. mod_ssl
needs this for ssl_util_stapling.c:stapling_get_issuer(),
ssl_engine_init.c:ssl_init_ctx_pkcs7_cert_chain(), and
ssl_util_ssl.c:SSL_CTX_use_certificate_chain().
2) access to the SSL_SESSION's "compress_meth" (read-only). Used in
ssl_engine_vars.c:ssl_var_lookup_ssl_compress_meth().
Is there a chance to add these for the initial 1.0.1 release?
Kaspar
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by Kaspar Brand <ht...@velox.ch>.
On 03.08.2011 19:29, Dr Stephen Henson wrote:
> In OpenSSL 1.0.1 (unreleased) and later there is a feature to make all SSL
> related structures opaque and only allow them to be accessed through functions.
> This is enabled by setting OPENSSL_NO_SSL_INTERN before including any OpenSSL
> headers.
Thanks for this information, this definitely seems a desirable goal for
mod_ssl in the long term (pity it wasn't added to OpenSSL earlier).
> Ironically to support this you'd need to avoid some of the changes in this
> patch. For example:
>
> - l = strlen(SSL_CIPHER_get_name(c));
> - memcpy(cp, SSL_CIPHER_get_name(c), l);
> + l = strlen(c->name);
> + memcpy(cp, c->name, l);
After another look, this is actually a case where I can revert the
change in my patch - I overlooked that SSL_CIPHER_get_name is a macro
which is also defined by OpenSSL itself (at least in 0.9.7 or later).
The remaining ones probably need to stay for the time being, but let me
add that I would definitely prefer mod_ssl not fiddling with the
internals of OpenSSL (as an example, modssl_set_cert_info is rather
worrysome, IMO).
My plan was to do relatively mechanical macro replacement in a first
step, then try to identify code parts which can be replaced by calls to
OpenSSL (e.g. the CRL checking stuff), and in a third step, look at the
remaining places which are "messing" with OpenSSL's internals and
hopefully replace them with proper API calls whenever possible.
OPENSSL_NO_SSL_INTERN sounds like a very useful thing for this, although
backward compatibility will still make life hard, I guess.
Kaspar
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.
On 03/08/2011 18:08, William A. Rowe Jr. wrote:
> On 8/3/2011 11:23 AM, Kaspar Brand wrote:
>> Ok, so the initial version of that patch became relatively large:
>>
>> https://people.apache.org/~kbrand/mod_ssl-toolkit-support.v1.diff
>>
>> Even though trunk is CTR, I'm somewhat reluctant with simply going ahead
>> and would appreciate if people could comment on this approach (e.g. if
>> it's fine or splitting up would be preferred, etc.).
>>
>> In theory, the changes could be limited to the autoconf stuff - i.e.,
>> guard against OpenSSL < 0.9.7 and not detect BSAFE SSL-C any longer in
>> configure, and leave the mod_ssl code as is, mostly.
>>
>> I don't think that's what we want, however, so I tried to get rid of as
>> much of the macro cruft as possible (drop ssl_toolkit_compat.h, remove
>> obsolete ifdef'ed code and so on).
>
> My thought, it probably should be a set of commits;
>
> * Drop SSLC (first patch)
> * Drop OpenSSL < 0.9.7 (second patch)
> * Drop ssl_toolkit_compat wrapper (third patch)
> * Warn on 0.9.7 and some 0.9.8 flavors (last patch)
>
>
A data point for this effort which may be of interest...
In OpenSSL 1.0.1 (unreleased) and later there is a feature to make all SSL
related structures opaque and only allow them to be accessed through functions.
This is enabled by setting OPENSSL_NO_SSL_INTERN before including any OpenSSL
headers.
The advantage of this is that any application which can be compiled with this
option will retain binary compatibility through any changes to SSL internal
structures.
I haven't had time to try getting mod_ssl to work with this option. It is
guaranteed to fail without some modification. There may well be some
functionality missing in OpenSSL too.
Ironically to support this you'd need to avoid some of the changes in this
patch. For example:
- l = strlen(SSL_CIPHER_get_name(c));
- memcpy(cp, SSL_CIPHER_get_name(c), l);
+ l = strlen(c->name);
+ memcpy(cp, c->name, l);
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shenson@opensslfoundation.com
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by Kaspar Brand <ht...@velox.ch>.
On 03.08.2011 19:08, William A. Rowe Jr. wrote:
> My thought, it probably should be a set of commits;
>
> * Drop SSLC (first patch)
> * Drop OpenSSL < 0.9.7 (second patch)
> * Drop ssl_toolkit_compat wrapper (third patch)
> * Warn on 0.9.7 and some 0.9.8 flavors (last patch)
Ok, I'll try splitting it into more digestible pieces. Do you suggest
committing them at the same time then, or possibly wait a few days in
between (in case someone wants to build from the interim versions)?
Kaspar
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 8/3/2011 11:23 AM, Kaspar Brand wrote:
> Ok, so the initial version of that patch became relatively large:
>
> https://people.apache.org/~kbrand/mod_ssl-toolkit-support.v1.diff
>
> Even though trunk is CTR, I'm somewhat reluctant with simply going ahead
> and would appreciate if people could comment on this approach (e.g. if
> it's fine or splitting up would be preferred, etc.).
>
> In theory, the changes could be limited to the autoconf stuff - i.e.,
> guard against OpenSSL < 0.9.7 and not detect BSAFE SSL-C any longer in
> configure, and leave the mod_ssl code as is, mostly.
>
> I don't think that's what we want, however, so I tried to get rid of as
> much of the macro cruft as possible (drop ssl_toolkit_compat.h, remove
> obsolete ifdef'ed code and so on).
My thought, it probably should be a set of commits;
* Drop SSLC (first patch)
* Drop OpenSSL < 0.9.7 (second patch)
* Drop ssl_toolkit_compat wrapper (third patch)
* Warn on 0.9.7 and some 0.9.8 flavors (last patch)
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
Posted by Kaspar Brand <ht...@velox.ch>.
On 02.08.2011 22:39, William A. Rowe Jr. wrote:
> On 7/31/2011 4:17 AM, Kaspar Brand wrote:
>>> - drop support for OpenSSL < 0.9.7a
>>> - drop support for non-OpenSSL/derivatives of OpenSSL
>>
>> Ok, then my next step is working on a patch which takes care of these
>> two points, I guess.
>
> +1
Ok, so the initial version of that patch became relatively large:
https://people.apache.org/~kbrand/mod_ssl-toolkit-support.v1.diff
Even though trunk is CTR, I'm somewhat reluctant with simply going ahead
and would appreciate if people could comment on this approach (e.g. if
it's fine or splitting up would be preferred, etc.).
In theory, the changes could be limited to the autoconf stuff - i.e.,
guard against OpenSSL < 0.9.7 and not detect BSAFE SSL-C any longer in
configure, and leave the mod_ssl code as is, mostly.
I don't think that's what we want, however, so I tried to get rid of as
much of the macro cruft as possible (drop ssl_toolkit_compat.h, remove
obsolete ifdef'ed code and so on).
I successfully compiled trunk with the above patch against the following
OpenSSL versions (w/o warnings): 0.9.7, 0.9.8, 1.0.0d (NB: by 0.9.7, I'm
referring to the initial release in that series, not the 0.9.7a patch
release).
Finally, I also ran the t/ssl tests against the three versions with
these OpenSSL releases, and all of them passed.
Thanks for commenting on / reviewing the current patch version.
Kaspar