You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jason Rigby <si...@gmail.com> on 2005/03/12 01:52:34 UTC

Mod_SSL in binaries

Hi all,
I'm just curious as to the reasons that Mod_SSL is not included in
pre-compiled versions of Apache. I presume they're legal issues as I
recall a while ago that Microsoft, due to export restrictions, could
not release their High Encryption Pack for Internet Explorer however
they did over come this restriction possibly due to some legislative
change - nevertheless they were allowed to allow downloads of this
high encryption pack. If it is a matter of which countries are alowed
access to the ssl enabled software, perhaps an IP filter could be used
to allow or deny a particular user from downloading the ssl enabled
apache. I would like to see a pre-compiled binary with mod_ssl in the
future (as I'm sure many of us would :) ).

I guess for now I will have to continue compiling the ssl enabled
version of apache from the source...
Thanks,
Jason.

Re: Mod_SSL in binaries

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 07:47 AM 3/12/2005, Graham Leggett wrote:
>William A. Rowe, Jr. wrote:
>
>>In this case, the crypto provider is the Operating System distribution.
>>Don't quote me, but effectively, the Operating System provides the
>>crypto capability (or doesn't, based on legalities in the origin and
>>distribution countries.)
>>Microsoft Windows does not distribute OpenSSL.  It doesn't even
>>provide the WinSock SSL API which our mod_netware_ssl relies on.
>>So while their might be issues (I'm clarifying) for the most part
>>mod_ssl.so (with dynamic bindings) should not present an issue.
>
>My next question is "in light of this, may I make the mod_ssl binaries available alongside the other httpd RPMS as an when httpd is released?". Could we get the legal people to confirm whether this can be done?

If we answer for Win32, we answer for all platforms.  Because we
need to distribute libeay32/ssleay32 .dll files to be -useful-
on win32, everything we would do on Unix would be effectively the
same, or present fewer issues.

I will announce any conclusion I receive.


Re: Mod_SSL in binaries

Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe, Jr. wrote:

> In this case, the crypto provider is the Operating System distribution.
> Don't quote me, but effectively, the Operating System provides the
> crypto capability (or doesn't, based on legalities in the origin and
> distribution countries.)
> 
> Microsoft Windows does not distribute OpenSSL.  It doesn't even
> provide the WinSock SSL API which our mod_netware_ssl relies on.
> 
> So while their might be issues (I'm clarifying) for the most part
> mod_ssl.so (with dynamic bindings) should not present an issue.

My next question is "in light of this, may I make the mod_ssl binaries 
available alongside the other httpd RPMS as an when httpd is released?". 
Could we get the legal people to confirm whether this can be done?

Regards,
Graham
--

Re: Mod_SSL in binaries

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 08:20 PM 3/11/2005, Graham Leggett wrote:
>William A. Rowe, Jr. wrote:
>
>Is it correct to say that right now in the Unix domain, we are allowed to distribute a binary mod_ssl on condition it is dynamically linked to a crypto library (SSL) not included in the distribution?

In this case, the crypto provider is the Operating System distribution.
Don't quote me, but effectively, the Operating System provides the
crypto capability (or doesn't, based on legalities in the origin and
distribution countries.)

Microsoft Windows does not distribute OpenSSL.  It doesn't even
provide the WinSock SSL API which our mod_netware_ssl relies on.

So while their might be issues (I'm clarifying) for the most part
mod_ssl.so (with dynamic bindings) should not present an issue.

IANAL.

Bill


Re: Mod_SSL in binaries

Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe, Jr. wrote:

> Before you gripe at us (httpd) though, I suggest you ask why
> you can't get libeay32.dll/ssleay32.dll binaries from openssl.org?
> Providing users mod_ssl.so with no crypto is actually very easy
> after the BXA refined all the rules about 'hooks'.  In fact, those
> rules were (one of the reasons) why we never distributed EAPI.
> Relaxing them was the reason we were able to move forward with 
> a much more complete hooks implementation in httpd 2.0.

Is it correct to say that right now in the Unix domain, we are allowed 
to distribute a binary mod_ssl on condition it is dynamically linked to 
a crypto library (SSL) not included in the distribution?

Regards,
Graham
--

Re: Mod_SSL in binaries

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
[blind CC'ed to our board]

At 06:52 PM 3/11/2005, Jason Rigby wrote:

>I guess for now I will have to continue compiling the ssl enabled
>version of apache from the source...

I commented on this on the 25th of Feb, both with respect 
to releasing mod_ssl binaries (plus the ever critical ssleay32.dll
and libeay32.dll, which are not in our domain) and recording all
of the foundations' ECCN 5D002 code (so our end users are aware
when they obtain any code if it's subject to TSU 740.13(e).)

Simply, I have heard nothing back from the board or counsul.  
As an individual, we can't take action, it requires the advise 
of our counsel and direction by the board to ensure we follow
the ENC provisions of the BXA.  I'm not a lawyer, I don't play 
one on TV, and won't move forward without necessary decision 
making by the Foundation.

I will try to rekick the discussion on our legal discussion
list, wish me luck.

We (the open source community) are actually in -better- shape 
after the 12/9/04 changes to the crypto policy.  You can be 
reassured the odds just got better.

Before you gripe at us (httpd) though, I suggest you ask why
you can't get libeay32.dll/ssleay32.dll binaries from openssl.org?
Providing users mod_ssl.so with no crypto is actually very easy
after the BXA refined all the rules about 'hooks'.  In fact, those
rules were (one of the reasons) why we never distributed EAPI.
Relaxing them was the reason we were able to move forward with 
a much more complete hooks implementation in httpd 2.0.

Bill