Re: modssl for Apache 2.0
R. DuFresne wrote: > > When is apache 2.0 coming out of beta and into primetime? April 6, 2002. -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Apache 2.0.* and SSL
Cliff Woolley wrote: > > On Tue, 9 Apr 2002, Mads Toftum wrote: > > > I too could add a whole lot of reasons to not migrate if you're doing SSL. > > Up to about a week before Apache went GA, there were substantial commits to > > SSL code which to me makes it an essentially untested module. > > While I can't wholly disagree with you, I will point out that the only way > we can ever really consider SSL "tried and true" is if the people > _from_this_group_ test it extensively and help us find the problems with > it. Your participation is vital... really! This, exactly, was one of my intentions when I opened this thread. BTW: Great article about 2.0, Cliff! (IIRC, it was Linux Magazine). -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Apache 2.0.* and SSL
Steve Gonzales wrote: > One list is enough for me. SSL theory doesn't change from 1.3.xx to > 2.0.xx; only the configuration and installation changes. There are many other issues, like the "-DEAPI" and 3rd party modules that cause Apache to crash. Anyway, the fact is that all of the discussions regarding 2.0 are done in the new-httpd list, and not here (at least till this thread). So it is clear that something must be done. Maybe a request to new-httpd subscribers to move the SSL discussions to here? -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Apache 2.0.* and SSL
By the way: I think that we should open a special mailing list for mod_ssl of Apache2. The current list focuses on 1.3, which is completely different than 2, and even comes in a very different way (as a patch, rather than a filter). The developers and maintainers are different. And the new mod_ssl is a part of Apache. On the other hand, the main list that currently deals with the new mod_ssl, is new_httpd, which is the main list of Apache developers: It deals with zillion things, very heavy, and doesn't focus on SSL at all. There must be a third list, specific for mod_ssl of 2.0. It must be announced to both of the current lists, so subscribers of both have chance to subscribe to the new list (I guess that in most of the cases it will be IN ADDITION to their current list, and not instead of it). I don't know if it should be served by the server of the other lists of Apache, or by Ralf's server; I guess that we should ask Ralf... -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Apache 2.0.* and SSL
Oops... The last message was intended personally for George Walsh, and not for the list... -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Apache 2.0.* and SSL
> Well said, and the written support from the group is long overdue, as > are the well deserved compliments. Thanks! -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Apache 2.0.* and SSL
Hi mod_ssl users, As most of you probably know, the development efforts of Apache 2 are going to result in a product, soon. The current betas are already stable, mature, fast, portable than ever, strong, and support many features that we have dreamed about for years, like filtering (I mention this feature, and not zillion others, because it is important specifically for SSL). Yes, it's true that some of us didn't like various things, and that the development process was not optimal and took too much time. But this effort comes (finally...) to a successful end, and I believe that everybody who uses SSL (including myself...) should do the migration. Contrary to past versions, this one is a dramatic change in the integration of SSL. No more patches, no more re-compilations with "-DEAPI", no more 3rd party modules which cause Apache to crash because these modules were not compiled using this flag, no more specific versions of mod_ssl per each version of Apache, no more repeating merges of the patches of mod_ssl. Now, thanks to the filtering feature, mod_ssl is separate, and doesn't depend on modifications in the core of Apache. Thanks to the White House, mod_ssl is not a national secret that can't be distributed, anymore. Thanks to the USPTO, mod_ssl doesn't depend on a protected patent anymore (it expired. RSA even gave up 2 weeks). And thanks to ASF, mod_ssl is a standard part of Apache. Any Apache that will be distributed in the future, will include SSL support (at least optionally), that can be enabled externally by installing OpenSSL and adding some directives to the httpd.conf. Ben did a great job by creating apache_ssl. Ralf did a great job too, by improving it, and his impressive efforts and skills that were invested in developing and maintaining mod_ssl. We all owe a great thank to Ralf for other Open Source projects that he does, or joins. Now it's time to make the next step, and migrate to Apache 2.0. It still requires some work and testing. It can happen if we all join this effort. I am not a member of ASF, but I'm convinced that everybody will accept you happily. -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: How a module can tell if a server is enabled to use SSL?
Look at the source of mod_info.c. An easier but uglier way would be to call ap_exists_config_define to check if "SSL" is defined. -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MOD SSL over NAT
Jim Lee wrote: > Response to Response: > Yes, the Firewall is configured to allow port 443. > > In fact we are able to reach our web server from outside(internet) by typing > in the following url. > > http://www.website.com:443 > > But the moment we try the following url, it fails > > https://www.website.com > > The same above steps works successfully from within out network(intranet) > without any problems. Both http and https work fine. > > Any clues would be higly appreciated. > > Original Posting: > On Sat, 2002-01-26 at 07:26, Jim Lee wrote: > We have an apache server with mod_ssl. > The SSL works fine within our network(intranet). > But for internet users, who access the apache server over NAT, the SSL does > not work. > > Response to Posting: > are you sure your nat setup is allowing traffic on port 443 (or whatever > port your ssl is running on)? try telneting to port 443 on the external > interface from someplace outside the firewall; if you can't you need to > reconfigure your firewall.. I had the same problem, and it resolved when I added an appropriate iptables rule with the flags: -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu I was told to add this rule by others who had the same problem too with SSL connections. I can't promise you that the problem is the same, nor that such a rule will end your troubles (and I even don't know if your firewall is based on iptables); I just tell from my experience. By the way: If this is the cuase of the problem, then most of the problems will be with SSL, but not only: a lack of such a rule, when there are conflicting MTU's, may have other effects. -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: question: is it possible to load mod ssl when apache isnt compiled whith modssl?
Arjen Halma wrote: > My question is: is it possible to load mod ssl when apache isnt compiled > whith modssl? > > I have a webserver Apache, but modssl is not compiled at the time it was > made. > > Now i want to add modssl is that possible whithout compiling a new > webserver? I use Debian If "isn't compiled with mod_ssl" means "isn't compiled with -DEAPI", then mod_ssl can work only if your Apache version is 2.0.* (well, theoretically you can port mod_ssl from the current model - zillion patches in the core of Apache - to the model that modules like mod_gzip are using, so it will not require patches in the core of Apache, but only the addition of a module. But this will be very hard to do, will take months to develop, and the result may be not as good as the current mod_ssl. And in any case, by the time you end such a project, Apache 2.0 will become the main version of Apache...). -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Decrypting Past Sessions
Hi, I want to DEcrypt an encrypted past session, that was logged in the middle of the SSL tunnel. I am the owner of the private key, however the dump of the original session was before being decrypted (it was in a reverse proxy, using the "experimental" feature of mod_ssl). The logged dump is, of course, old, so the decryption should be done "off-line" (I can use the secret private key for this purpose). Is it possible? If the answer is "yes", I have one more question: Is there an existing tool to do it? I prefer a free one (like from freshmeat or sourceforge), but a commercial tool that is well known will be OK too. Thanks, -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Best mod_proxy Stable Version
[The following questions relate to mod_ssl too; Please read on] What is the best *STANDARD* version of Apache, from the point of view of mod_proxy? (by writing "standard", I mean the standard source tree, excluding external patches like the one that was prepared for 1.3.19) Is it true that proxy features which already worked with old versions of Apache, don't work anymore with 1.3.19? (unless the special patch, which I wrote that is not an option, is applied) IIRC, since mod_proxy was not maintained quite well for some time in the past, some versions of it were not up-to-date, and had conflicts with the core Apache, which made mod_proxy not so good as in the past. Is it true? And if it's true, then what version exactly is recommended? Is 1.3.12 good enough? My questions may sound strange, so let me describe my status: I have a site powered by 1.3.12 + mod_ssl, with intensive use of mod_proxy, mainly as a reverse proxy. I want to upgrade it, but am afraid that the proxy stuff will not work well. Picking 1.3.19, and applying the special proxy patch of 1.3.19 into it, is not an option, since mod_ssl comes as a patch which should be applied into the standard Apache. There are versions of mod_ssl for almost any standard Apache, including the current (1.3.19) and mine (1.3.12), but not _1.3.19 + proxy-patch_. If it's possible to apply mod_ssl into the patched 1.3.19, then it's the best, and I'll be happy to hear about it from you. If not, I'd appreciate if anybody here has any expecience with the combination of mod_ssl/mod_proxy, and can recommend the best version of Apache to use. Thanks in advance, -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: [STATUS] (httpd-proxy) Sat Apr 28 07:06:44 EDT 2001
[I added modssl list in order to know if the upcoming 2.8.3 is going to support these important patches. Ralf?] Chuck Murcko wrote: > Doh! Try here: > > http://dev.apache.org/dist/patches/apply_to_1.3.19/ > > and > > http://dev.apache.org/dist/patches/apply_to_1.3-current/ > > Noted and fixed. These are going to move off dev.apache.org soon. OK. This is better. The good old "dist" directory... By the way: Were some of the patches already applied into the standard 1.3.20 CVS? At least patches from the first? Rodent of Unusual Size wrote: > > Rodent of Unusual Size wrote: > > > > >first HTTP/1.1 support patch complete; available at > > >http://dev.apache.org/patches/apply_to_1.3.19/ > > > > Are you sure? > > You are not aiming this at me, I hope.. I just mail > the existing STATUS file, I am not responsible for > its contents! Hey, it had to be fixed, and you were just the "immediate victim" ;-) -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
mod_gzip and SSL
Hi Kevin/Ralf/etc., Until recently, it was impossible to manipulate Apache responses (other than static content which a module can be written to serve) without patching the core Apache. Apache 2.0 tries to overcome this problem, but modules like mod_ssl had to insert many patches into the core source, a painful requirement, and also a dependency on any version of Apache, and need to update mod_ssl for any new version of Apache. mod_gzip pretends to solve this problem. According to its documentation, it manipulates not only statis files, but also the output of other modules. It comes as one C file (Apache module), without patching anything else. I'd appreciate if there are answers for my humble questions: 1. Am I wrong? Or the "trick" was finally found? 2. Can this trick be used for other purposes? (such as SSL; Such a trick may be used to avoid the EAPI patches which are inserted into the core source of Apache) 3. Does mod_gzip and mod_ssl (the current) run together? Or is there any conflict? 4. Is there any cost for this trick? (i.e. is EAPI/etc. more efficient?) 5. Can your trick be used to manipulate the input (a.k.a. HTTP requests) and headers too? 6. Is there any conflict with mod_proxy? Can mod_gzip run together with mod_proxy? Does it gzip its output too? (so you may add a reverse proxy to an existing web server, without touching it, but only speeding the output by compressing it externally) BTW: mod_proxy has been always HTTP/1.0 which is not supported by gzip, but recently ported to support 1.1 as well. Thanks in advance, -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
[Fwd: [Mod_gzip] mod_gzip and SSL]
Hi, Recently, I changed my e-mail address, so a message I posted on Friday to the list, was refused. The message was posted to another mailing list as well ([EMAIL PROTECTED]), and personally to Ralf and to a person in mod_gzip (Kevin). Kevin's answer, which may have a drammatic impact on the way we integrate SSL into Apache (currently - using EAPI patches, a painful process), contains the original message of me, so after resubscribing to the list with my new address, I prefer to post his response. I believe that their brilliant way to "filter" Apache content *DYNAMICALLY*, not with the long-awaited Apache2, but with the version that is going to serve us at least in this year (1.3.*), is a great alternative for EAPI. Think about a world without mod_ssl depending on a specific version of Apache. Think about a world in which you can pick a binary module, although it was not compiled with -DEAPI. Think about a world in which you can pick a binary pre-built Apache, and just add SSL into it. Think about a world without so many conflicts between mod_ssl and other modules. Think about a world without the need to run "patch" (or a similar command in WIN platforms) on the original Apache before building it. Or in short - imagine that most of the questions posted to this mailing list, will be avoided. So just read the forwarded message, and think about all these good things, -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel Hi Eli... This is Kevin Kiley > You wrote... > >Hi Kevin/Ralf/etc., > >Until recently, it was impossible to manipulate Apache responses (other >than static content which a module can be written to serve) without >patching the core Apache. Apache 2.0 tries to overcome this problem, but >modules like mod_ssl had to insert many patches into the core source, a >painful requirement, and also a dependency on any version of Apache, and >need to update mod_ssl for any new version of Apache. > >mod_gzip pretends to solve this problem. There is no 'pretend'. It does it. mod_gzip basically proves that it has ALWAYS been relatively 'easy' to filter any kind of data coming from Apache from within Apache itself and there really wasn't much need for an EAPI interface in the first place. The mod_ssl folks just thought there was. mod_gzip actually shows how easily the filtering can be done in several different ways and on serveral different levels. The very first version of mod_gzip ( December, 2000 ) did nothing more than add a 'gather buffer' onto the same code that executes CGI programs and that worked for just about all external CGI ( Perl, Python, ColdFusion, etc ). The internal streams coming from other modules that were actually part of Apache were another story and the second version ( January, 2001 ) added a little more 'smarts' to the same 'gather buffer' approach. The latest version ( 1.3.19.1a ) was released a few days after Apache 1.3.19 was released so it could be tested against the latest release of Apache and it actually uses an entirely 'new' approach that works fine for both internal/external data streams and/or static/dynamic content. It's a significant improvement over the 'gather buffer' approach but it's interesting to note that both approaches actually work AOK. >According to its documentation, >it manipulates not only static files, but also the output of other >modules. It comes as one C file (Apache module), without patching >anything else. > >I'd appreciate if there are answers for my humble questions: > >1. Am I wrong? Or the "trick" was finally found? You are not wrong... and it's not really a 'trick'. It simply uses standard Apache API calls and it works all the way back to Apache 1.3.1 and even farther than that if you are willing to simply compile it into the core. The only real limitation on the code as far as Apache version numbers go is that the current release ( 1.3.19.1a ) makes use of the ap_regexec() regular expression call to help 'filter' the request and response headers. Apache didn't add the 'ap_regexec' stuff until around 1.3.6 so if you want to use mod_gzip with something that pre-dates the addition of the regular expression calls you simply must comment out the references. >2. Can this trick be used for other purposes? (such as SSL; Such a trick > may be used to avoid the EAPI patches which are inserted into the > core source of Apache) mod_gzip can compress the output of mod_ssl just fine. It does it before SSL performs the encryption. I believe Tim Frank was t
1.3.20
Hi, Is there a development source or a snapshot of mod_ssl for a version of Apache, *NEWER THAN 1.3.19* ? (i.e. a CVS or a snapshot of 1.3.20) I want to play with some new features of Apache (such as HTTP/1.1 proxying), which were not supported by 1.3.19. I promise to contribute bug reports / impressions / fixes / etc. By the way: Does anybody know what are the plans regarding the final 1.3.20? Is it expected soon? Thanks in advance, -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: mod_ssl and Apache 2.0 ?
> A direct question to Ralf, will you port mod_ssl to Apache 2.0 ? > > API tends to move less (even if ap_r* are still discussed) and we may > see a first beta in some weeks. Hi, As the first who tried to give a detailed answer for a similar question in this list (about a year ago), let me say something (though I'm not going to repeat the whole explanation): There are some arguments regarding Apache 2.0. I think Ralf will be glad to detail. But one of the concensual issues, at least for purposes like SSL support, is the filtered I/O mechanism. This feature, was developed especially for things like compression, SSL encryption, spelling, and other filters which are applied on the output of the various modules of Apache. Actually, if mod_ssl was required to be developed from scratch, at least a half of the work (in my humble opinion) could be avoided. Apache 2.0 could be an amazing shortcut for development of SSL layer. No more patches, no more EAPI, no more seg faults of binary modules which were pre-compiled, and no more endless runnings after each minor version of Apache. The final Paradise. However, as we know ;-), mod_ssl is already working, alive and kicking. And since it proved itself in so many installations, and so many bugs and incompatibilities have been fixed, it will be silly to develop a new layer from scratch. Apache 2.0 is being developed for more than 4 years. I know that the porting of mod_ssl to 2.0 will take less time, but I believe it is important to start with it. Even esoteric modules are already finalizing their 2.0 port, after a long time of porting, and mod_ssl even didn't start this porting. I believe that mod_ssl is one of the most important and critical modules. And these days, that there are no more patents, neither US export limitations, it has the potential to become a standard part of Apache. I hope this effort will start and end soon. P.S. I want to thank Ralf for his excellent work! -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Apache 2.0 API and mod_ssl
Hi, I will try to be more risky than Ralf and to forecast something in the future of Apache: Currently, a major effort is focused in designing and developing a "multi-layered I/O" into Apache. This will allow to put different modules in separate layers, so the output of one module will be the input of another one, etc. For example, the output of PHP may include SSI commands (Server Side Includes, "shtml"), and so on. (I must admit that years ago, when I heard about Apache the first time, and I was told that it is very modular, I was sure that the modules lay in separate layers, and I was amazed and disappointed when I saw that the model is much more primitive and limited). *IF* this will become a stable and safe implementation, there will not be any need for EAPI or any other special API/hooks/whatever in Apache; Just build your own layer - SSL layer - and chain it as the last layer before passing the output to the client. I emphasized the "*IF*", because - as Ralf wrote - there is a long way for Apache2 yet to go (although I expect the first beta - not alpha - to be as stable as other web-servers, such as IPlanet and IIS). In addition, there is no guarantee that the layered I/O project will succeed. You probably read about "exciting" developments and new features of 2.0, like APR, MPM, etc.; Don't believe! MPM and the other features which are mentioned usually, insert a lot of crap into Apache and may even cause it to be unstable and too complex. The real surprises of 2.0 are the layered I/O, and the changes in the configuration model. If these 2 projects will succeed, we are going to have an amazing and powerful web server (much more than now), with cool features, and (finally!) ease and friendliness (the changes in the configuration model may ease the development of GUI tools for REAL management of Apache configuration). But these 2 projects are still in question. In any case, as Ralf wrote, it will not be clever to deal with 2.0 now, because its APIs are still in design. -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: How works the 'SSLPassPhraseDialog'
Jan Meijer wrote: > > > A hacker can copy your key, no matter if it is encrypted or not; It > > will just spend one more minute for him. > > Perhaps I'm missing something here, but if your key is encrypted and the > only way to decrypt it is to actally enter the passphrase manually (e.g. no > automatic start-up) the hacker can steal all he wants, but needs to trojan > some things as well to actually get to your key (unless of course you > encrypted it with 40 bits des, but only someone in the wrong country would > do that). Yes, you are missing something. The message before mine, to be more specific. A subscriber asked how to run Apache automatically (probably from his rc.d or init.d scripts), and was answered that he should write a program to supply this password to Apache. So I responded with my message, that having such a program makes PEM encryption useless. -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: How works the 'SSLPassPhraseDialog'
In short, as I claim always, there is nothing good in PEM, because you can't eat the cake and have it. You either have an un-encrypted file, or you have an encrypted file - but with another program that outputs this password. And you don't have to look for this program - just look at the appropriate rc.d script... A hacker can copy your key, no matter if it is encrypted or not; It will just spend one more minute for him. The only use for this PEM, is when it is transferred via non-secure ways, for example when it is e-mailed, or stored in another computer. Or may I miss anything? -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: About OpenSSL
Johann Bertscheit wrote: > I analyzed the difference in speed - and I found the reason: > for debugging purposes I set the SSLLogLevel to "debug" on WIN32 but not on cygwin. > When I set the SSLLogLevel back to "info" then the speed difference is gone. Wow... I wouldn't imagine that such a flag may cause a so big hit to the performance... Once, I thought of writing a monitoring tool for Apache to analyze bottlenecks (contrary to profile, not only CPU bottlenecks, but also I/O). I already wrote such a tool for other applications, and it worked great, and it could find the problem with logging immediately. However, I don't have any idea how to implement it in a multithreading environment, such as the WIN32 port of Apache. > The problem occurs when a switch of VirtualHosts occur! > I have 2 VirtualHosts configured in my httpd.conf. > - one on port 443 > - another on port 5443 > (- and the normal port 80) > Also I checked the dependency with SSLLogLevel, because I noticed that the >SSL-logfile > is garbled prior(!) the crash - It seems to be that 2 processes write in the logfile >without sync! > But even if I set SSLLogLevel to "warn" the crash occurs! > To reproduce the problem it seems you need two requests to a semi-complex html-page > (I have a frameset with 3 frames and with approx. 20 images) > first from http://host:443/page.html > then from http://host:5443/page.html > try it several times (maybe also with different pages) and the crash occurs! > ... > I use winnt 4.0. > > The following crash occurs while serving 'https://...' pages > (e.g. frameset with 3 frames and with approx. 20 images) > > The crash is not always reproduceable but occurs again and again. It looks exactly as a multithreading conflict. But I would expect a multi-threading problem to affect any compiler, so I'm not sure if this is the problem here too. To check it, you may try to set "ThreadsPerChild" to 1; It will slow your performance VERY heavily, so it will require you to spend about 100 times the average time needed to crash your Apache before, i.e. if Apache crashed once per a minute with the old configuration, with "ThreadsPerChild" set to 1, you will need a hour or two in order to be *100%* sure that the problem is over. If it is, we can look for a problem with lockings or static memory areas, conflicting with each other. If it is not, then the problem is probably with the compiler. It is still hard to imagine that there is a so critical bug in MSVC, so I think about another option: You wrote that you inserted various modifications into the sources; Is it possible that one of them resolved a multithreading/locking problem? And of course, there is a possibility that the Cygwin multithreading is simply better... One last possibility: You mentioned that your WIN32 version supported also mod_rewrite and mod_proxy, while the Cygwin version didn't; Did you access them when the crashes occured? Maybe the multithreading in them is buggy? Regarding your debugging stuff and stack: Seems that we need my patches urgently, so the debugging information will be more readable. I finished the migration to 1.3.12-2.6.2, so I'll submit the patches today later. Then, if you can apply the patches and re-build your WIN32 version, but with "installd" rather than installr, and provide us with the results of the debugger, it will be great. -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Win32 And OpenSSL
> I'm thinking there is a bug within OpenSSL or mod ssl. Reading your message twice, I couldn't understand what's wrong with mod_ssl. Of course, there is always the possibility that the OpenSSL 0.9.5 has a "trigger" which is activated by a bug in another place, but then why to blame mod_ssl and not Apache, the compiler, NT, etc.? The only component which you replaced and caused your build to work or to bomb, was OpenSSL-0.9.5. Since mod_ssl requires any OpenSSL higher or equal to 0.9.3, what's wrong with Apache-1.3.12 + OpenSSL 0.9.4 + mod_ssl-2.6.2 ? Let's start from OpenSSL. From your message, it looks obvious that THERE is the problem. Which reminds me that I was asked to re-submit my patches. One of them allowed debug mode to be compiled easily under NT. I'll try to do it today. Ralf, is it OK to work against 2.6.2? -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: About OpenSSL
Johann Bertscheit wrote: > ... Your message left us with too many questions... 1. Did you use the original sources, or had to modify them? If the original sources work with no change, then it is a great news! I always thought that some of these sources require Visual C++ under NT... 2. The versions you use look very ancient... (Apache 1.3.4/1.3.6, mod_ssl 2.1.7/2.2.7, PHP-3.0.7, PostgreSQL-6.4, mod_dav-0.9.8, etc.). Is there any special reason? 3. How is it possible that an executable compiled by Cygwin is 11 (!) times (1000%) faster than an executable compiled by Visual-C++? I never noticed that the VC++ binary was so slow... And it looks impossible that Microsoft, which has $billions to put in R&D, will let its flagship compiler to be 1000% slower. Even 20% slower would be hard to believe... Or there is a critical problem with mod_ssl/OpenSSL... If so, please provide us with more details, so we can fix them. OpenSA people, are you there? Did you have such problems? 4. You wrote that the WIN32 version crashes. Can you reproduce it? There are many WIN32 users in this list, and we don't face such problems. Can you hunt these crashes? Can you find their origin? Your story looks too amazing to be true, but if you tell it, we believe you. However, please provide us with more details, so we can check if these problems are our fault / MS fault / your machine fault / debugging flags fault / whatever. Thanks, -- Eli Marmor * ___ _ __ ___ ___ |__ _ _[EMAIL PROTECTED] * * | | | \ | | \| / |\/ El-Mar Software Ltd. * *| | | _) | | _) / | \ Tel.: 972-50-237338 * *___ Fax: 972-9-766-1314 * * \_ \ http://elmar.co.il * *_ __ \ \ ___ * * \___ \ \_\| _ \ __ \ \ \ \ | | * * \ \ | | \ \ \_\ \ \ \ \ | | * * \ \ | | _\ \ ) ) \ \ \_\_ * * \ \ |_| \___) (_/ \_\ \_\* * \ \___ * * \\* * * ** __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Problems building mod_ssl/2.6.0 with DSO
Ralf S. Engelschall wrote: > Yeah, sorry again, Eli. I know that your patches are still pending and > are still not comitted. It was certainly my fault in giving other stuff > more priority in the past (mainly because anything non-Unix related is > always low-priority for me ;). So, please excuse that you have to remind > me the third time. Would you please so kind and post to modssl-users > again (as a single all-in-one patch) your suggested patches? I'll try to assemble them again. It may take some time (maybe even two days), because the patches were against 2.4.0-1.3.9 and should be "upgraded". In addition, one of the patches (the patch which allows modules to be compiled without the "-DEAPI" flag) is not found, so I have to re-write it. I'm afraid that I never submitted it, but only explained it in this list or to you personally. I want to note that only SOME of the patches are specific for WIN32. In any case, I agree that this world could be much better without the need to port any stuff to WIN32 :-) -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Problems building mod_ssl/2.6.0 with DSO
Dag Wieers wrote: > > On Sun, 27 Feb 2000, Ralf S. Engelschall wrote: > > > I've compiled mod_sxnet for a long time. But beside the openssl header > > file transition to a subdirectory (I've updated sxnet.h for this > > now), it compiled fine. The above error actually means that EAPI is > > not correctly installed in your Apache. You seem to have messed up > > something. > > ... > > I'm wondering why the Apache Group didn't apply the EAPI-patches to Apache ? > Don't they agree or are they building something slightly different ? Or is > it against export-laws ? Which reminds me: One of my patches attacks this issue. It doesn't solve the problem of using an Apache which was not compiled with -DEAPI, but it solves the problem of 3rd party modules and modules which were not compiled with -DEAPI; It is probably the most annoying problem of mod_ssl users. Ralf, what is going with my patches? I remember that you apologized for delaying them to 2.5.0 ;-) I'm afraid that I must re-write them, because the base code was modified (my patches were against 2.4.0/1.3.9). If you want, I can collect all of them into one message (as I did in the previous two times that you asked me to do it...). -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: [MODSSL-USERS] SSLRequireSSL error
> > > apachectl -ssl configtest > > > apachectl -ssl start > > > apachectl -ssl graceful > > > > Is there anything wrong with the flag "startssl"? > > Yes. You can't "restart" or "graceful" with "startssl". That was > my problem... trying to "restart" an SSL server. Oops... My fault... I didn't read the original message and responded too quickly... -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: SSLRequireSSL error
> You have to enable the mod_ssl stuff. Use: httpd -DSSL -t > > I have posted a patch to this list some time ago which > adds a -ssl option to apachectl. This allows you to > SSL-ify any apachectl command by using: > > apachectl -ssl configtest > apachectl -ssl start > apachectl -ssl graceful Is there anything wrong with the flag "startssl"? -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Help! Help! Not able to use HTTPS with Netscape!
Just to ensure that it is not an idiotic problem of caching or permissions, check that your log directory and the directory where mod_ssl creates its files is writable by the user ID of Apache (it may be different than root, even when you use root to run Apache), and RE-RUN your Netscape! I have a similar problem any time I forget to close Netscape and re-run it after I fixed something in the https. -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Latest NetCraft Statistics
mod_ssl: 568701 Domains, 120659 IP Addresses -- Eli Marmor [EMAIL PROTECTED] El-Mar Software Ltd. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
A Patch to Allow non-EAPI Modules to be Linked In
Hi Ralf, After you finish finally to insert all of my other patches into the standard source tree of mod_ssl, I have a magic patch which can finally resolve the most annoying problem of many mod_ssl users: The conflicts with modules which were compiled without the patched header files (i.e. httpd.h) and/or without "-DEAPI". The trick is simple, and I already used it to extend the functionality of Xt Widgets (e.g. Motif, Xaw, etc.) with no need for recompilation or even for the source. The trick is based on allocating more than needed for any of the relevant structures (request_rec, conn_rec, server_rec), but passing only part of them to the caller (from the middle, so the extra space is in "negative" addresses relative to the beginning of the "real" structures, to avoid conflict with other extensions, such as the current EAPI). During the life cycle of the structure, the extra information (e.g. ctx) is accessed using a negative offset (of course, with the correct alignments; It's simple). When the structure should be freed, the "free()" function receives the ORIGINAL address which was returned by the original malloc. Of course, in our case it is even simpler, since the garbage collection of the pool mechanism does it automatically. It is recommended to include a magic number in the extra information so in case of a structure which was allocated not through the standard places (http_config.c, http_main.c, http_protocol.c, and http_request.c), a safety check can be done, and the extra information will be ignored. Together with my other patches, I think that it deserves a new major number - 2.6.0-1.3.12 :-) -- Eli Marmor * ___ _ __ ___ ___ |__ _ _[EMAIL PROTECTED] * * | | | \ | | \| / |\/ El-Mar Software Ltd. * *| | | _) | | _) / | \ Tel.: 972-50-237338 * *___ Fax: 972-9-766-1314 * * \_ \ http://elmar.co.il * *_ __ \ \ ___ * * \___ \ \_\| _ \ __ \ \ \ \ | | * * \ \ | | \ \ \_\ \ \ \ \ | | * * \ \ | | _\ \ ) ) \ \ \_\_ * * \ \ |_| \___) (_/ \_\ \_\* * \ \___ * * \\* * * ** __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MSVCRT.dll-LIBC.lib Conflicts under NT (Solution + Summary)
I wrote: > I'm curious to know if anybody else faced the following problem I > had today when I tried to compile Apache-1.3.9/mod-ssl-2.4.9 by MS > VC6 under NT4 (I don't know if it has anything to do with mod_ssl): > - > D:\eli\apache_1.3.9\src>nmake /f Makefile.nt _apacher > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > ... etc ... > > link.exe @C:\TEMP\nmb00228. > MSVCRT.lib(MSVCRT.dll) : error LNK2005: _exit already defined in >LIBC.lib(crt0dat.obj) > MSVCRT.lib(MSVCRT.dll) : error LNK2005: _fprintf already defined in >LIBC.lib(fprintf.obj) > > ... etc ... > >Creating library .\CoreR\ApacheCore.lib and object .\CoreR\ApacheCore.exp > LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other libs; use >/NODEFAULTLIB:library > .\CoreR\ApacheCore.dll : fatal error LNK1169: one or more multiply defined symbols >found > NMAKE : fatal error U1077: 'link.exe' : return code '0x491' > Stop. > NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~1\VC98\BIN\NMAKE.EXE' : return code >'0x2' > Stop. > - I found the answer, and send it to both mailing lists, so the next one who will search the archives for a similar problem, will find my original message and this one, and hopefully will overcome the problem as me: The cause of the problem was an object file which was compiled without the "/MD" flag (for multithreading; All the objects which are included in the link of Apache must be compiled with it, as it seems). I added the flag and re-compiled that object, and finally succeeded to link Apache (I used "_apached"). But then, when I tried to run the executable, it crashed, and the debugger sent me to a strange place (a system library, called from "file_cleanup()"; Don't try to find any connection between this function and the cause - it was probably a pointer overflow). I tried to learn something from the stack of the debugger, and after giving up, I tried "_apacher" and succeeded to run. So I looked at the differences between "_apached" and "_apacher", and found that instead of "/MD", "_apached" uses "/MDd"; I put this instead of the "/MD" as the flag of the blamed object, and this time I succeeded not only to link it, but also to run it (with "_apached"). Summary: Any C module or file which you want to link with the Apache, you must compile with "/MD". If you build a debugging version of Apache, use "/MDd". Omitting the "/MD" will cause the link to fail. Using "/MD" instead of "/MDd" or vice versa, will cause your built executable to crash. Note: I know that "_apached" is not officially supported by mod_ssl; I patched some files, like ApacheCore.mak and modules/ssl/Makefile.win32 and now it works beautifully. I sent Ralf the patches, so I hope he will combine them in the upcoming 2.5.1-1.3.12, together with my other waiting patches; Ralf ??? -- Eli Marmor [EMAIL PROTECTED] El-Mar Software Ltd. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
MSVCRT.dll-LIBC.lib Conflicts under NT
_fseek already defined in LIBC.lib(fseek.obj); second definition ignored MSVCRT.lib(MSVCRT.dll) : warning LNK4006: _fflush already defined in LIBC.lib(fflush.obj); second definition ignored MSVCRT.lib(MSVCRT.dll) : warning LNK4006: _fread already defined in LIBC.lib(fread.obj); second definition ignored MSVCRT.lib(MSVCRT.dll) : warning LNK4006: _realloc already defined in LIBC.lib(realloc.obj); second definition ignored MSVCRT.lib(MSVCRT.dll) : warning LNK4006: __isctype already defined in LIBC.lib(isctype.obj); second definition ignored MSVCRT.lib(MSVCRT.dll) : warning LNK4006: _strncpy already defined in LIBC.lib(strncpy.obj); second definition ignored MSVCRT.lib(MSVCRT.dll) : warning LNK4006: _atol already defined in LIBC.lib(atox.obj); second definition ignored MSVCRT.lib(MSVCRT.dll) : warning LNK4006: _sscanf already defined in LIBC.lib(sscanf.obj); second definition ignored MSVCRT.lib(MSVCRT.dll) : warning LNK4006: _tolower already defined in LIBC.lib(tolower.obj); second definition ignored MSVCRT.lib(MSVCRT.dll) : warning LNK4006: _ungetc already defined in LIBC.lib(ungetc.obj); second definition ignored MSVCRT.lib(MSVCRT.dll) : warning LNK4006: _fgets already defined in LIBC.lib(fgets.obj); second definition ignored MSVCRT.lib(MSVCRT.dll) : warning LNK4006: _memmove already defined in LIBC.lib(memmove.obj); second definition ignored MSVCRT.lib(MSVCRT.dll) : warning LNK4006: __close already defined in LIBC.lib(close.obj); second definition ignored MSVCRT.lib(MSVCRT.dll) : warning LNK4006: __read already defined in LIBC.lib(read.obj); second definition ignored MSVCRT.lib(MSVCRT.dll) : warning LNK4006: __write already defined in LIBC.lib(write.obj); second definition ignored Creating library .\CoreR\ApacheCore.lib and object .\CoreR\ApacheCore.exp LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other libs; use /NODEFAULTLIB:library .\CoreR\ApacheCore.dll : fatal error LNK1169: one or more multiply defined symbols found NMAKE : fatal error U1077: 'link.exe' : return code '0x491' Stop. NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~1\VC98\BIN\NMAKE.EXE' : return code '0x2' Stop. - Thanks in advance, -- Eli Marmor [EMAIL PROTECTED] El-Mar Software Ltd. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
NetCraft Stats, Jan 2000
10 million domains were "sampled". Apache is up 1% to 55.5%. Total Apache almost 60%. IIS down -0.9% to 22.9%. Total NT less than 24%. mod_ssl: 516950 Domains, 110230 IP Addresses mod_perl: 418742 Domains, 66239 IP Addresses PHP: 1271060 Domains, 391876 IP Addresses (is there anything wrong with the number of domains of the Apache modules? Although they are a little up absolutely, they are down relative to the whole Apache "market"... And only the IP numbers are really up). I would love to know the ASP's stats, to have the full picture. -- Eli Marmor [EMAIL PROTECTED] El-Mar Software Ltd. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Compile problems
John Kennedy wrote: > ... > Ultra2 running Solaris 2.6. We are using: > ... > Compiling using gcc-2.95.1-sol26-sparc-local package from > http://www.sunfreeware.com > > The following is the configure command: > > SSL_BASE="/var/local/src.jck/openssl-0.9.4" \ > ./configure \ > "--with-layout=Apache" \ > "--prefix=/usr/local/apache_1.3.9" \ > "--enable-module=ssl" \ > "--activate-module=src/modules/perl/libperl.a" \ > "--enable-module=perl" \ > "--activate-module=src/modules/php3/libphp3.a" \ > "--enable-module=php3" \ > > and this is the output: > > ... > + doing sanity check on compiler and options > ** A test compilation with your Makefile configuration > ** failed. This is most likely because your C compiler > ** is not ANSI. Apache requires an ANSI C Compiler, such > ** as gcc. The above error message from your compiler > ** will also provide a clue. > Aborting! > > Any ideas would be appreciated... setenv EXTRA_LIBS to "-lm" before invoking your configure command. Let me know if it doesn't solve your problem, because there is another option. Ralf: Don't the darling friends from ASF think about resolving this ancient problem? (I don't dare to suggest a patch; I can guess the flaming answers in advance: "It is resolved with 2.0, and 1.3 tree is too obsolete to invest in..."). BTW: Are you the original JFK or only the Junior? -- Eli Marmor [EMAIL PROTECTED] El-Mar Software Ltd. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: windows
Ralf S. Engelschall wrote: > > On Wed, Jan 12, 2000, Agrolan wrote: > > > I am working with apache 1.3 under win NT > > I want to creat a scure system > > > > is the modssl working under NT ? > > where can I get manual ? > > > > If not, who have any idea , what to do ? > > Read the INSTALL.W32 document in the mod_ssl distribution tarball and/or > go to www.opensa.org. I just wanted to add, that we (Ralf and me) discuss some patches that may ease the installation under WIN32. I can't talk on behalf of Ralf, so I can't promise you that 2.5.0 will include these patches, but I estimate that there is a high chance that soon (not the next version - 2.4.11, but the version after it - 2.5.0), the things under Win32 may be easier and better. Now, the big question is for you: Is it urgent for you (so you can't wait and must accept one of the solutions Ralf suggested), or not (so you may wait and maybe have a better/easier solution). In any case, OpenSA attacks not only the issue of the difficulties with SSL, but also other issues (like PHP, Perl, etc.), so if you are interested in an all-in-one Apache solution for Windows, I recommend it for you, no matter if you can wait or not. And the planned patches don't compete with OpenSA in any way, but only help them, and save them the need to deal with yet another problem in addition to the zillion problems that they have to resolve. I think that their project is great). (And for the people that have REALLY a lot of patience, maybe other issues will ease now, after the changes in the crypto policy of the American Govt. In my opinion, today is a historic day for the Open Source world). P.S. Try to look at the contrib directory, I think that there is a pre-built package for NT. -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
mod_ssl vs. Apache-SSL in Slashdot
Slashdot asks what is better: mod_ssl or Apache-SSL: http://slashdot.org/article.pl?sid=99/12/22/1711203&mode=thread -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: OT: How to Add a Module to Apache
As I already wrote, the most important issue is not having the same steps for building, but to have the same tree for both Windows and UNIX. It is easy to do, and has a lot of benefits. In your tree, you achieved this purpose, and I think it is possible to add support for UNIX, so build/installation of Apache plus so many modules and patches under UNIX will be as easy as Windows. And don't forget; Originally, it was Windows where the build was so hard... Daniel S. Reichenbach wrote: > > > > > > > Just run a single "nmake" in Apache_1.3.x\src and then "nmake > > > install" and that`s it. > > > > Although it is a very positive progress, it is not what I meant. I > > want a shared distribution for all the platforms, which can be built > > simply (1-2 steps rather than dozens of steps and packages to load > > from the net), under ALL of the platforms. Similar steps are not the > > important thing (though they may help; BTW: Why don't you create a > > batch file "make.bat" which will call nmake and translate its > > parameters to nmake's syntax?). The important thing is that the ease > > of build and installation that you achieved for Windows users, will > > be shared by the UNIX users too. > Hmm, little batch file could be done. If we do this, anyone could > type "make" on both Unix and Win32 and get the compiled Apache ? So > our "make.bat" would have to mimic the behaviour of a Unix makefile > and you could do things like "make install" or in the case of mod_ssl > "make certificate TYPE=..."? We would still have seperated builds. > In that case we need the .sh files from mod_ssl as batches, too. > > I`m not sure, if this is the right way. Would`t it seperate the build > process a bit more? Sounds like having the same things to do on all > plattforms, but all on different ways. > > How about Cygwin32? This sounds cleaner to me. We could change the > makefiles to detect Cygwin32 and then do the same things for Win32 > as under Unix. ? -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
A New Multi-Billion Business: SSL for Apache!
According to dozens articles I read in the recent days, the next trend in IPOs is Apache. The current trend, as all of you know, is Linux, and the total market cap. of Linux companies, jumped in a few months by about 1000% (!) to about $50 billion (RedHat alone is $20B). And what drives this new trend? After all, Apache is even not GPL'ed, but totally free, and technical support is given by many companies, such as Red Hat, LinuxCare, as well as voluntary mailing lists and news groups... You guessed true! SSL support, of course... According to http://news.cnet.com/news/0-1003-200-1498105.html?tag=st.ne.1002.tgif?st.ne.fd.gif.e as well as other sources: Covalent has more to offer than just technical support and consulting services, however. The company also sells an add-on to Apache that enables use of "the secure sockets layer" encryption technology, essential to private transactions such as credit card payments. P.S. If I sound sarcastic, I apologize; It was not my purpose... -- Eli Marmor [EMAIL PROTECTED] El-Mar Software Ltd. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: OT: How to Add a Module to Apache
Daniel S. Reichenbach wrote: > The next release will have a new build scheme, which could be > near to what Eli might want. The build can be done the Unix way. > Just run a single "nmake" in Apache_1.3.x\src and then "nmake > install" and that`s it. Although it is a very positive progress, it is not what I meant. I want a shared distribution for all the platforms, which can be built simply (1-2 steps rather than dozens of steps and packages to load from the net), under ALL of the platforms. Similar steps are not the important thing (though they may help; BTW: Why don't you create a batch file "make.bat" which will call nmake and translate its parameters to nmake's syntax?). The important thing is that the ease of build and installation that you achieved for Windows users, will be shared by the UNIX users too. Your project is too important to leave it only for Windows users... -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: OT: How to Add a Module to Apache
Daniel S. Reichenbach wrote: > Sorry me. Should have read to the end. You said that SSL_INC and > SSL_LIB could be defined as env vars under Win32. I would vote +1 for > it. The same is used in PHP4 for Cygwin32 integration in the makefiles. and [EMAIL PROTECTED] wrote: > I like the idea that the UNIX and NT mod_ssl patch/install scripts should > do the same thing, err, I mean produce the same results. I, on UNIX, add > mod_ssl to Apache, import into CVS, and then everyone, UNIX and NT > developers, checkout Apache + mod_ssl, and proceed from there. It's a minor > irritation that I have to do some bits by hand to properly add the NT > parts. I'm glad to hear that you like it. Actually, the following patch does 90% of the work. I still have to deal with src/modules/ssl/Makefile (the Windows' one is copied from Makefile.win32 with 4 patches, 2 of them depend on location - SSL_INC and SSL_LIB, and the other 2 are not needed - MOD_SSL_VERS_NUM and MOD_SSL_VERS_STR - because their values are already known when publishing the release, and the UNIX' one is generated during the build of Apache). In addition, I want to add commands to insert SSL stuff into httpd.conf-dist-win (currently, even configure.bat doesn't do it). I put it here not as a usual diff command, because I leave it to Ralf to decide where to put it in "configure" (if he wants it, at all): - # Eli Marmor's Addition: for i in `find $apache -name "*.mak"` do mv $i $i.orig sed -e "s+^CPP_PROJ=+CPP_PROJ=/DEAPI /DMOD_SSL=204109 +" < $i.orig > $i done mv $apache/src/Makefile.nt $apache/src/Makefile.nt.orig sed -e "/copy modulesproxy/i\\ copy modulessslApacheModuleSSL.dll \$(INSTDIR)modules" \ -e "/nmake \/nologo CFG=\"ApacheModuleRewrite - Win32 %LONG%\" -f ApacheModuleRewrite.mak$/a\\ cd ....\\ cd modulesssl\\ nmake \/nologo all" \ -e "/nmake \/nologo CFG=\"ApacheModuleRewrite - Win32 %LONG%\" -f ApacheModuleRewrite.mak clean/a\\ cd ....\\ cd modulesssl\\ nmake \/nologo clean"< $apache/src/Makefile.nt.orig > $apache/src/Makefile.nt # Till here. - Notes: = 1. Read what I wrote above about src/modules/ssl/Makefile. 2. "204109" should be modified from version to version. A dynamic calculation of it, has too many drawbacks, which I'll be glad to detail in a separate message. 3. The patch is against 2.4.9-1.3.9. 4. Because of some "bugs" of configure.bat, this patch is not 100% compatible with configure.bat. For example, configure.bat doesn't remove remaining "*.orig" files, contrary to configure. In addition, after adding my patch for httpd.conf-dist-win, configure will be much better than configure.bat. One last word to the OpenSA people: I believe that it will not be an impossible job to make OpenSA portable to UNIX. Windows was always harder for such stuff (Apache, mod_ssl, PHP, OpenSSL, etc.) to build and install, but UNIX is not for newbies too. Maybe I can help. -- Eli Marmor [EMAIL PROTECTED] El-Mar Software Ltd. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: SSL Configuration-How to?
I'll try to write an httpd.conf patcher for Windows, like the one for UNIX (currently, the only patch for Windows is a commented AddModule). -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: OT: How to Add a Module to Apache
> Under NT you can go to http://www.opensa.org/ and get Apache, mod_ssl, > OpenSSL and PHP4 with a comfortable installation for about 3MB. > Five to ten minutes download plus two minutes installation and that`s > it. That should be ok ?! I know OpenSA, and I'm even subscribed to its mailing list. I only thought that its good idea, the integration, may help Apache and mod_ssl too. Especially when you have one source tree for UNIX and Windows (which is very simple, as I already tried and explained). But I see that not all the people share my opinion, so maybe I should give up, and focus on the compromized idea (to make the patch scripts more compatible). -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: OT: How to Add a Module to Apache
f responding automatically, please read the previous message (about the modification to the patch scripts of UNIX and Windows), check yourself, check the issue of shared objects, check other considerations, and only then decide. I promise you that you will be surprised to find that things are simpler than they looks. -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: OT: How to Add a Module to Apache
I just re-read Cliff's message, and learned that his meaning was not what I thought before, after a (too) quick reading of it. So my response is not too much relevant. Sorry, -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: OT: How to Add a Module to Apache
After a long investigation, I found only one real conflict between UNIX and Windows: src/modules/ssl/Makefile. The Windows version is copied from Makefile.win32 during the mod_ssl patching procedure, while the UNIX one is generated automatically during the make of Apache. To avoid cases in which Windows tries to use the UNIX version, or vice versa (i.e. UNIX doesn't generate a new Makefile because it thinks that the Windows Makefile is its own Makefile), I suggest to not have anything in the joint source tree, so UNIX will continue to generate a new during the build of Apache, and we will have to add one more step to the installation of Windows: A copy of Makefile.win32 to Makefile. Of course, it is still MUCH shorter and simpler than the current list of steps. (BTW: This file, is where the SSL_INC and SSL_LIB, which I suggested to comment and to replace by environment variables in Windows, are defined). -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: OT: How to Add a Module to Apache
The answer is very simple. All the modules you mentioned (e.g. PHP) are separate modules. They can (and should) be built out of the tree of Apache. Even if you choose to build them in the source tree of Apache, you should do it at least in the separate directory "src/modules/extra", or by putting them in an independent directory of you and adding "--add-module" to the configuration command of Apache. So if you work in the "Right-Way"(TM), there should not be any conflict. Moreover, one of the motivations (which I didn't mention in my previous message due to lack of space and time), is the ease of merging YOUR stuff with a newer version of mod_ssl. When you have a module which is not only a module but makes some modifications in the original source tree of Apache, there is a high chance that the patch scripts of mod_ssl will fail to work on the modified sources of Apache. I develop such a project, and it is a nightmare for me. I found it EASIER to merge my patches from an old version of the patched tree of Apache (with mod_ssl patches) to a newer one, than to deal with the patch scripts. Actually, the only way that I can (without spending too much effort) to "upgrade" my stuff, is by merging the original (Apache + mod_ssl applied into + my stuff applied into) with the newer (Apache + mod_ssl applied into). So even in the case of modules which are not separate, my experience showed me that it was better to have a ready tree than patch scripts. Cliff Woolley wrote: > > >>> Eli Marmor <[EMAIL PROTECTED]> 12/11/99 06:33PM >>> > >Providing mod_ssl as a patched Apache source tree, instead of a > >separate patch. > > On the other hand, for current users of mod_ssl it'd be nice to just > have a patch against the previous version of mod_ssl's *already patched > source tree*. For example, if I run mod_ssl 2.4.8's patches against a > clean Apache 1.3.9 source tree and then add other packages to the Apache > tree (JServ, mod_php, mod_fastcgi, etc), it's annoying to have to start > all over again when mod_ssl 2.4.9 comes out. It'd be nice to just have > the things that changed between mod_ssl 2.4.8 and 2.4.9 as a patch so > that I could apply that to my already-configured tree and know that all > the patches will apply correctly. I know that most of the time you can > do this anyway because the EAPI doesn't change very often (it actually > *did* work for the 2.4.8->2.4.9 upgrade, for example), but when it > doesn't work and you get *.rej files in your Apache source tree, the > problems that ensue can be confusing. I know it's bitten me before! > > So what if a complete distribution of a pre-patched Apache source tree > were offered for first-time users and a patch upgrade from the previous > version of Apache+mod_ssl were offered for existing users? > > Does that make sense? I know I could make the above-mentioned diff on > my own in a separate location and then apply it to my main Apache source > tree, but I imagine I'm not the only one that would want it, which is > why I bring it up. What do you all think, is all this just too much > work? > > --Cliff -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: OT: How to Add a Module to Apache
Following to my previous message, I want to present a restructuring of mod_ssl, which was discussed in the past, but was rejected, due to reasons which are not relevant anymore: Providing mod_ssl as a patched Apache source tree, instead of a separate patch. First of all, let me detail the problems with the current structure of mod_ssl: 1. Very complex installation, and more steps, encouraging many users to give up. 2. The installed source tree of Apache, when running the patch script of mod_ssl, must be the original. Some users have a modified tree, and this leads to many problems. 3. Complex patch scripts, for different platforms (UNIX, Windows, etc.), written in different languages (shell, perl, etc.), and needing repeated modifications and maintainance (anomally). 4. Many tools are required. For example, in order to install mod_ssl under Windows, one must download perl, patch.exe, etc. So why wasn't it done before? 1. There was a hope, for a long time, that the Apache Group (later the ASF) would agree to adopt the patches and to insert them into the standard source tree. The chance is over, at least for 1.3.*. 2. Nobody thought that so many people (about 100,000), some of them ignorances, will use mod_ssl. When only experts used mod_ssl, it was acceptable to have a complex installation procedure. Now it is not, anymore. 3. There was a fear that including EAPI patches in the source tree of Apache would cause it to be blocked in U.S. because of the crypto limitations. Now, that these patches are used not only as hooks for crypto purposes, but also as hooks for naive purposes, this problem is over. In addition, this week the American government is going to relax crypto limitations, and there is a high chance that crypto HOOKS will be allowed (IANAL!). In the worst case, the unified source tree will continue to be distribtued in the same places and FTP sites that mod_ssl is currently distributed. 4. Having a short list of patches looked simpler for contributers and developers to maintain and improve than a huge source tree of Apache, that only 1% of it (or 5%, I really didn't check), is a part of mod_ssl. But this "developer-friendly" way, came at the expense of the "user-friendly". Moreover, using "diff" or "windiff" is the easiest thing, and I can't believe that there are developers who don't know how to use these tools. Having the original source tree of Apache and the patched source tree, makes it easy like 1-2-3 to build a diff. Currently, if A+P=S (A = Apache, P = mod_ssl patches, S = modified source tree of Apache with mod_ssl patches), we supply P, and users must apply it to A in order to get S. In the proposed way, we supply S, so users don't have anything to do in order to have a ready tree, while developers may want to do "S-A=P" (i.e. a simple diff), in order to get the patches without Apache sources. 5. There was a fear that somebody may think that mod_ssl tries to "compete" with Apache, by having its own tree. Now, with the spread of Linux distributions, this consideration looks passe, more than anytime in the past. The UNIX distributions, such as RedHat, SuSE, Debian, etc., don't compete with the Linux kernel, or other components of Linux. They only package these components, including the kernel, and sometimes even with public patches to the kernel (e.g. RedHat), to a more integrated distribution. These distros HELP the Linux kernel and the other components to gain more popularity. In the same way, a ready package of Apache with mod_ssl patches (and maybe also OpenSSL (and maybe even other modules, like PHP4, etc.)), will help Apache to gain even more popularity than now. 6. Differences between the environments (mainly UNIX and Windows): As I showed in my previous message, this point is not relevant anymore. It is easy to build a source tree which is good for all the platforms (though I didn't try OS/390 ;-). My final vision is to have an integrated source tree, including sub trees for Apache (including EAPI patches), PHP4, JServ (Jakarta?), Perl, OpenSSL, mod_perl, etc., with one simple command (like the "src/helpers/binbuild.sh"), that will build everything, without an installation process of zillion steps. You may look at this package as a Linux distribution, and the sub-tree of Apache as the kernel in the above distribution (I hope you understood the analogy). But this ambitious vision, can start with a small step, by integrating the mod_ssl patches into "our" own source tree of Apache, and supplying the patched source tree to users, rather than the patches separately. If you love this idea, I suggest to start it with 2.5.0-1.3.10 (assuming that 1.3.10 will be rolled on the 19th, or a few days af
Re: OT: How to Add a Module to Apache
I posted a proposal in the past about unifying the patch scripts of
UNIX and Windows. Ralf answered me that it would require users to
install Perl on their UNIXes. I still think that even if there are
two different scripts, they must do the same things (90% of what
they do is already the same), so after applying the patches, you'll
have the same source tree, no matter what OS you have (except for
SSL_INC and SSL_LIB in src/modules/ssl/Makefile, which can be
commented and replaced by environment variables, so the tree will
be portable, and directories and installations can be moved from
one place to another).
After this change, we will have the same source tree (after
applying mod_ssl patches into Apache tree) for all the platforms.
It will allow us to:
1. Apply the patches in one environment, move the source tree to
another, and build Apache there.
2. Distribute an FTP archive which will be good for all of the
platforms (of course, we may have more than one archiving
format; For example, some people don't have unzip under UNIX, so
a "tar.gz" (and maybe also ".tar.bz2") will be needed too.
There are not many modifications which should be done.
1. ".mak" files are patched only by the Windows script. Since the
patch is very simple, I don't see any reason why not to add it
to the UNIX script.
2. Windows' "patch" is not compatible with the UNIX one (it adds
carriage returns before line feeds). We should either remove
carriage returns from each file after applying patches into it,
or use patch flags to avoid CRs (are there such flags?), or use
another version of patch or another program.
3. Makefile.nt is not patched by the UNIX script.
4. The files modules/ssl/Makefile.{libdir,tmpl,win32} are not
created by the Windows script.
5. Some minor things.
It is really simple. If you don't think so, I can help and/or code
parts of this proposed patch.
I have a more revolutionary idea (deserves a "2.5.0" version...);
I'll post it on Sunday.
--
Eli Marmor
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]
Apache 1.3.10
I looked at the STATUS that Ken published today, and - surprise! - the EAPI patches of mod_ssl are back there! > * Ralf's [PATCH] to add EAPI (ctx, hook, mm, etc.) to the base package > Message-ID: <[EMAIL PROTECTED]> > Status: Jim +1, Mark +1, Dean +1, BenH +1, > Randy +1 (please choose name other than "hook") > Doug +1 on concept (untested), Lars +1 on concept, > Martin +1 (untested), Ken -1 for 1.3.7 (too controversial, > esp. w/KEAPI offered as well) Except for one "-1" which is not relevant anymore (because we passed 1.3.7 a long time ago), all the other opinions are "+1". Is there anything we missed? BTW: "I am not a lawyer", but since there are other uses for EAPI in addition to mod_ssl, it is not a crypto patch anymore, and there is no law against inserting it into the main source tree. In addition, there is a (small) chance that on December 15 the American government will relax its limitations on crypto in Open Source Software, so even mod_ssl+OpenSSL have the option to enter the open world. Well, the last thing (December 15) is more a wishful thinking, but I hope that at least the chance of EAPI to become standard on Apache 1.3.10, is more realistic... -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Statistics
I didn't see any announcement of Ralf (maybe because of the LLOONNGG delay of this mailing list), but the new statistics of NetCraft and E-Soft are available at his page: http://www.modssl.org/news/statistic.html (positive, of course!). I think that it will be better to make some changes in the pie-chart at the bottom of the page. Now, it rates Microsoft as the first, Apache/mod_ssl + Apache_ssl as the second, and c2.net as the third. Since c2.net is Apache too, and since different SSL implementations for Apache are counted together in any case (mod_ssl and Ben's), it will be more correct to show Apache+c2.net together. In such a pie chart, Apache will be the first, and Microsoft only the second. (BTW: Contrary to the other statistics, this one is updated only for August; I hope the latest statistics are better). -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
OT: How to Add a Module to Apache
It's off-topic, but was raised when I investigated how to unite the patch scripts of UNIX and Windows (of mod_ssl) into one script (Ralph - does it interest you? The current status looks anomal for me...). Anyway, I noticed that all of the current Apache modules use one of the following ways: 1. Either they focus ONLY on one platform (Windows *OR* UNIX), so their installation-script / patch-script, is simple. -- or -- 2. They are compatible with BOTH Windows AND UNIX, so their installation script is very complex. Isn't there a simple way to be compatible with both? Is there any guide how to add a new module to Apache so it will be supported by BOTH of the environments? Everybody knows how to use "--add-module", how to add directives, and so on, but the rules for Windows are completely different; You must modify Makefiles, ".def" files, etc. Does anybody have a good (or bad) answer for me? Should I send this question to the mailing list of Apache modules? Thanks in advance, -- Eli Marmor [EMAIL PROTECTED] El-Mar Software Ltd. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: OT: EAPI, DSO & stability
Of course, I posted my message before receiving Ralf's response to this thread. The delay in this mailing list is ve lnnnggg :-( In any case, my message is still relevant. -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: OT: EAPI, DSO & stability
> > Does someone know if there are any plans to incorporate
> > the EAPI into mainstream Apache?
>
> There were, but somehow it never got included.
> Someone on the apache list apparantly had a better solution,
> which also has not been incorporated...
>
> Status on that, Ralf?
My name is not Ralf :-), but...
As everybody agrees, it could be great. But chances are low, due to
politics. As you know, such a decision must be agreed by all of the
members of Apache Group, at least with "-0", but without any veto
(-1). It means that even if there is one competing project, there is
no chance to pass such a decision. It is a big loss, no matter what
SSL implementation for Apache is better, because currently mod_ssl
has much more users and its rising (in percents) is dramatic, so the
only result of excluding EAPI from the core source tree is
preventing Apache from ruling the SSL field (as it already does in
the non-SSL field).
But I thought about another idea: The EAPI stuff of mod_ssl can be
published not as a "patch" to the core source tree of Apache, but as
an already patched Apache. It means that "pkg.eapi/eapi.patch" and
"configure.bat" will not be needed anymore. To find the "sources" of
EAPI, one can "diff" the original Apache source and the patched one,
or to write a simple script that will look for ifdef's/idndef's/if's
whatever of "EAPI" etc.
I can promise you that soon after publishing merged packages, many
of the Apache's users will prefer to use these packages. The same
process happened with Linux: In its first days, users had to load
the kernel from one place, other parts from other places, and to
build everything. Now, most of the users just look for the most
integrated distrbution (which is, according to most users, RedHat).
I did a small investigation, and succeeded to build a source tree
which is good for both UNIX and Windows. Currently, there are some
files which are patched/created only by UNIX (pkg.eapi/eapi.patch),
some others which are patched/created only by Windows
(configure.bat), and some which even depend on specific local
definitions of the user's Windows system ("--with-ssl="). I merged
the procedures, and finally reached a status in which only one file
("src/modules/ssl/Makefile") should be created for Windows only and
with specific definitions for the local Windows (and even these can
be avoided by using environment variables for SSL_INC/SSL_LIB).
In my humble opinion, it is much better than maintaining three
separate packages (the original Apache, a script to patch Apache for
UNIX, and a Perl script to patch Apache for Windows), which is, no
doubt, an anomaly.
We can go even one more step, and wait for December 15, when the
government is expected (hopefully...) to give up the crypto
limitations on Open-Source Software. If it happens, we can also
merge the OpenSSL into this package, and then even things like
SSL_INC/SSL_LIB will not be needed anymore.
Maybe my ideas look too daring, but the current status in not
acceptable, and hurts the chances of mod_ssl to reach more users.
--
Eli Marmor
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]
Re: Digital Unix 4.0e and modssl
> has anyone gotten modssl 2.4.6 with apache 1.3.9 to work on Digital Unix 4.0e. > > I am having some problems. > > if you did get it to work would you tell me what compilers and patches (if any) > that you used. I don't have any experience with mod_ssl under Digital Tru64UNIX, but anytime I have problems porting anything to this platform, I try "-taso", and usually it works. The 64bit of this OS is different than all the other implementations of 64 bit. In any case, it will be useful to report a success or unsuccess to the list. In case of a success, it will be required to find the exact place that assume sizes which are wrong in Alpha. -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: I need help with this....
I forgot to write it in my original message, but you must get the following message in your error_log in this case: [Mon Oct 25 14:49:48 1999] [error] mod_ssl: Child could not open SSLMutex lockfile /your/path/logs/ssl_mutex.26336 (System error follows) It happens with the default permissions in a default installation (using Apache's "src/helpers/binbuild.sh" and "./install-bindist.sh"), so it is common. Otherwise, if it was a local problem because of local permissions, I would not write it. I wrote: > I don't know if the following reason is also the reason for the > problems in your case, but such a problem happens usually because of > a non-writable log directory or a log location which was mis- > configured. Sometimes the normal HTTP server can write to its logs > while the SSL stuff has problems (it sounds funny, I know! It must > be an idiotic thing, but I never had the time to examine it...). > Look at your log files (both access_log and error_log); You'll > probably find a warning about this problem. > > I can witness that I had the same problem (although there was no PHP > or Perl or FP in that installation), and after fixing the permission > problem, everything worked perfectly. -- Eli Marmor *** * ___ _ __ ___ ___ |__ _ _[EMAIL PROTECTED] * * | | | \ | | \| / |\/ El-Mar Software Ltd.* *| | | _) | | _) / | \ Tel.: 972-50-237338 * *___ Fax: 972-9-766-1314 * * \_ \ http://www.elmar.co.il * *_ __ \ \ ___ * * \___ \ \_\| _ \ __ \ \ \ \ | | * * \ \ | | \ \ \_\ \ \ \ \ | |* * \ \ | | _\ \ ) ) \ \ \_\_ * * \ \ |_| \___) (_/ \_\ \_\ * * \ \___ * * \\ * * * * __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: I need help with this....
I don't know if the following reason is also the reason for the problems in your case, but such a problem happens usually because of a non-writable log directory or a log location which was mis- configured. Sometimes the normal HTTP server can write to its logs while the SSL stuff has problems (it sounds funny, I know! It must be an idiotic thing, but I never had the time to examine it...). Look at your log files (both access_log and error_log); You'll probably find a warning about this problem. I can witness that I had the same problem (although there was no PHP or Perl or FP in that installation), and after fixing the permission problem, everything worked perfectly. BTW: You mentioned PHP; Does anybody know when PHP4-beta3 will be released? There were already 3 deadlines, but no sign for a final date... Brett Peters wrote: > > I had the same problem with a similar configuration... What's in your error > logs? > > Brett > [EMAIL PROTECTED] > > - Original Message - > From: Pete Navarra > To: [EMAIL PROTECTED] > Sent: Sunday, October 24, 1999 6:12 AM > Subject: I need help with this > > I have recently installed Apache 1.3.9, and mod_ssl 2.4.5 along with > FrontPage extensions, PHP, and mod Perl. Everything installed perfectly, > and I am having no problems except for one thing. When you try to connect > to my site using HTTPS, you get my certificate presented like it should, > however, once you accept the certificate, I get one of two errors saying > there is either no data to send (in Netscape), or that the DNS Server could > not be reached. ( in Explorer). It doesn't display my website, and pops up > with nothing. Any suggestions? -- Eli Marmor [EMAIL PROTECTED] El-Mar Software Ltd. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Legal Inclusion of mod_ssl in the Standard Distribution of 1.3.7
(I am not subscribed to neither mod_ssl list nor new-httpd lists, so please CC me to any reply. In addition, I'm afraid this message will be refused by these lists (some lists are closed for external posters to avoid spamming); In such a case, please forward this message to the lists). Following the new rule regarding to inclusion of encryption code in an Open-Source packages (which you can read about in zillion places like: http://www.news.com/News/Item/0,4,36217,00.html?tag=st.cn.1fd1.newstkr.ne and others), I propose the following: While Apache rules the web servers field, with about 60% (including its derivatives), and no rivals (IIS has only 24%, Netscape is close to zero), its presence is much weaker in the field of secure web servers, including sites of e-commerce, etc. IMHO, one of the reasons for this situation is that for newbies it is very hard to install SSL for Apache, while in the "competitors" it is already integrated. Contrary to other modules, this module is not part of the standard distribution of Apache, because of legal issues. Now, that these legal issues disappear, Apache has a great opportunity to change the picture. I don't know what is going with Apache 1.3.7 (where have the STATUS reports gone?), but I think it may be a real revolution if mod_ssl can be included with the standard distribution. It will remove one of the two areas where Apache loses in comparisons (the other is the friendliness), and will not only help Apache to gain a domination in the secure web servers field, but also will strengthen its existing domination in the field non secure web servers. Thanks for your attention, -- Eli Marmor *** * ___ _ __ ___ ___ |__ _ _[EMAIL PROTECTED] * * | | | \ | | \| / |\/ El-Mar Software Ltd.* *| | | _) | | _) / | \ Tel.: 972-50-237338 * *___ Fax: 972-9-766-1314 * * \_ \ http://www.elmar.co.il * *_ __ \ \ ___ * * \___ \ \_\| _ \ __ \ \ \ \ | | * * \ \ | | \ \ \_\ \ \ \ \ | |* * \ \ | | _\ \ ) ) \ \ \_\_ * * \ \ |_| \___) (_/ \_\ \_\ * * \ \___ * * \\ * * * * __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Access to request_rec from hooks?
Ralf S. Engelschall wrote: > > Is there any way to access the current request_rec from hooks like > > "ap::buff::write", "ap::buff::read"? > > Sure, read README.dsov.fig carefully! > There the internal structure of Apache+mod_ssl+OpenSSL > is shown in detail. > > In short: >BUFF => ctx => request_req > > In code (without error checks): >ssl = ap_ctx_get(buff->ctx, "ssl"); >req = (request_rec *)SSL_get_app_data2(ssl); Thanks! Next time I must RTFS before posing questions... Anyway, I have some more EAPI questions: 1. I've looked for examples of similar code in the source, and found that the returned value of SSL_get_app_data2(ssl) is ap_ctx, and it must be passed to ap_ctx_get(actx, "ssl::request_rec") in order to get the request_rec. Isn't it needed, or you just used a short way when you wrote your message and didn't want to detail everything? 2. I'm looking for a way to be notified when a BUFF is closed (or in other words: "ap::buff::close", just like "ap::buff::read" and "ap::buff::write"). Is there anything? Or should I use the close_connection_hook() and access the c->client from there? Or, a third option, just insert my hook as a patch into buff.c? (if anybody is curious, what I'm trying to do is just using EAPI for generic filter for HTTP documents. Sometimes a parser must look ahead before being able to decide what should be done with the contents passed through it, and in the next write hook call, the following contents resolve this question. But sometimes there is no more write, but the BUFF is closed, so the contents waiting for the next write must be flushed). BTW: My messages reach the list after a delay of MANY hours. It means that I'm recognized as a user who is not subscribed to the list. But I am subscribed. Can it be fixed? P.S. I forgot to say "happy birthday"... Thanks in advance, -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Access to request_rec from hooks?
Hello, Is there any way to access the current request_rec from hooks like "ap::buff::write", "ap::buff::read"? I thought of a minor patch to Apache to keep request_recs in globals, by some patches to http_request.c and http_main.c. The problem is that I'm not sure what is going under multi-threading environments (like NT). I think that it is possible that more than one request_rec is in process simultaneously, so the values of these globals are meaningless in multi-threading environments. Is it true? Is there another way to access the request_rec from hooks? Thanks in advance, -- Eli Marmor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
