RE: Ultrix Problem: Build Can't Find SSL Headers
On 5th.May.1999 Mads Toftum wrote You should have SSL_BASE=../openssl-SNAP-19990426 on the same line as the ./configure Sorry, but that failed in just the same way : = cut == In directory /data/arc/apache/mod_ssl-2.2.8-1.3.6 :- SSL_BASE=../openssl-SNAP-19990426 \ ./configure --with-apache=../apache_1.3.6 \ --with-ssl=../openssl-SNAP-19990426 \ --prefix=/usr/local/apache \ --disable-rule=SSL_COMPAT Configuring mod_ssl/2.2.8 for Apache/1.3.6 + Apache location: ../apache_1.3.6 (Version 1.3.6) + OpenSSL location: ../openssl-SNAP-19990426 + Auxiliary patch tool: ./etc/patch/patch (local) + Applying packages to Apache source tree: o Extended API (EAPI) o Distribution Documents o SSL Module Source o SSL Support o SSL Configuration Additions o SSL Module Documentation o Addons Done: source extension and patches successfully applied. Configuring for Apache, Version 1.3.6 + using installation path layout: Apache (config.layout) Creating Makefile Creating Configuration.apaci in src Creating Makefile in src + configured for ULTRIX platform + setting C compiler to cc + setting C pre-processor to cc -E + checking for system header files + adding selected modules o ssl_module uses ConfigStart/End + SSL interface: mod_ssl/2.2.8 + SSL interface build type: OBJ + SSL interface compatibility: disabled + SSL interface experimental code: disabled + SSL interface vendor extensions: disabled Unknown flag + SSL interface plugin: Configured DBM (-ldbm) Error: Cannot find SSL header files under /data/arc/apache/openssl-SNAP-19990426 + SSL library path: /data/arc/apache/openssl-SNAP-19990426 ./configure:Error: APACI failed = cut == ... and in fact it also failed the same way when I tried it without *any* declaration for SSL_BASE. But thanks for the help anyway. Nick Boyce [ Information Security Manager ] Systems Team, EDS Healthcare, Bristol, UK Internet email: [EMAIL PROTECTED] | tel: +44 117 989 2941 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: [BugDB] Ultrix Problem: Build Can't Find SSL Headers (PR#168)
But, when I try building mod_ssl-2.2.8_1.3.6, I get :- + SSL interface vendor extensions: disabled Unknown flag + SSL interface plugin: Configured DBM (-ldbm) Error: Cannot find SSL header files under /data/arc/apache/openssl-SNAP-19990426 + SSL library path: /data/arc/apache/openssl-SNAP-19990426 ./configure:Error: APACI failed Sure, you use a very recent snapshot of OpenSSL but a release version of mod_ssl. That doesn't work because of OpenSSL API changes for 0.9.3. OK - that explains a lot - thanks Ralf. HOWEVER, I'm sorry but having just had a look round the CVS part of www.modssl.org, I really don't think I'm capable of trying to assemble a working distribution - at least not without first learning all about CVS (I've never used it) and rsync (likewise). So is there any chance you could produce a Snapshot tarball or two, in the same way as the OpenSSL site does ? Otherwise I'm going to have to try to identify and back-port Ulf's Ultrix fixes from openssl-SNAP-19990426 into openssl-0.9.2b, or give up on an Ultrix secure web server for now. Thanks, Nick Boyce [ Information Security Manager ] Systems Team, EDS Healthcare, Bristol, UK Internet email: [EMAIL PROTECTED] | tel: +44 117 989 2941 -- From: Ralf S. Engelschall[SMTP:[EMAIL PROTECTED]] Sent: 06 May 1999 09:24 To: [EMAIL PROTECTED] Subject: Re: Ultrix Problem: Build Can't Find SSL Headers On Wed, May 05, 1999, Boyce, Nick wrote: I've raised this with Ralf E via the Mod_SSL Jitterbug system, but either I'm posting followup mail to the wrong address, or he's away right now, as it's all gone quiet. The address for replies is [EMAIL PROTECTED] But you're right, it should be written down somewhere in more detail. So I thought I'd try this on the list members, betting that this is a common problem : So far: openssl-SNAP-19990426 built OK "make -f Makefile.ssl links" done OK "make install" done OK But, when I try building mod_ssl-2.2.8_1.3.6, I get :- + SSL interface vendor extensions: disabled Unknown flag + SSL interface plugin: Configured DBM (-ldbm) Error: Cannot find SSL header files under /data/arc/apache/openssl-SNAP-19990426 + SSL library path: /data/arc/apache/openssl-SNAP-19990426 ./configure:Error: APACI failed Sure, you use a very recent snapshot of OpenSSL but a release version of mod_ssl. That doesn't work because of OpenSSL API changes for 0.9.3. You've to use also the latest mod_ssl CVS version. This compiles fine with the latest OpenSSL snapshot states. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: [BugDB] Ultrix Problem: Build Can't Find SSL Headers (PR#168)
On Thu, May 06, 1999, [EMAIL PROTECTED] wrote: [...] HOWEVER, I'm sorry but having just had a look round the CVS part of www.modssl.org, I really don't think I'm capable of trying to assemble a working distribution - at least not without first learning all about CVS (I've never used it) and rsync (likewise). So is there any chance you could produce a Snapshot tarball or two, in the same way as the OpenSSL site does ? /bin/done: ftp://ftp.modssl.org/snapshot/ Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Problems using https:
Having written an authentication module for Apache which has passed our testing and appears to be working fine we rebuilt Apache with mod_ssl. We can access non secure web pages as "http://server/" and "http://server/~user" but "https://server/" fails with the following error message: Netscape's network connection was refused by the server: ServerName The server may not be accepting connections or may be busy. Try connecting again later. We are running: Apache 1.3.4, OpenSSL 0.9.2b, mod_ssl 2.2.5-1.3.4 compiled with gcc 2.7.2.3 and linked with Solaris ld under Solaris 2.7 Our experience of mod_ssl is limited so we would be grateful if anyone can suggest our next course of action... Thanks! -- If it ain't opinionated, it ain't Rich Teer. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: Problems using https:
We can access non secure web pages as "http://server/" and "http://server/~user" but "https://server/" fails with the following error message: Netscape's network connection was refused by the server: ServerName The server may not be accepting connections or may be busy. Try connecting again later. I'm not an expert but ... This rather implies that your server machine has no process listening on port 443. I think you should post relevant details from your httpd.conf file(s) and/or output from "netstat -a | grep LISTEN" Are you sure you've modified the server config to cause it to expect SSL connections (as well as built it to be capable of them) ? Nick Boyce [ Information Security Manager ] Systems Team, EDS Healthcare, Bristol, UK __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Problems using https:
Fred Read writes: Fred We can access non secure web pages as "http://server/" and Fred "http://server/~user" but "https://server/" fails with the Fred following error message: Fred Netscape's network connection was refused by the server: Fred ServerName Fred The server may not be accepting connections or Fred may be busy. Fred Try connecting again later. What do the Apache log files say ? Do ls -lt /usr/local/apache/logs to get the files listed in order of when they were last modified and check out the files that got modified at about the time you got the error. If its possible do 'tail -f /usr/local/apache/logs/error_log' in one xterm and run Netscape and see what happens. Also do a similar thing with access_log in another window at the same time. Do a similar thing (tail -f) with error_log when you are starting the apache server. See if you are getting any errors on startup. Does it mention that it is starting Apache with mod_ssl ?? Are you sure the server is up and running ? What does 'ps -ef | grep httpd' show ? Fred We are running: Fred Apache 1.3.4, Fred OpenSSL 0.9.2b, Fred mod_ssl 2.2.5-1.3.4 Fred compiled with gcc 2.7.2.3 and linked with Solaris ld under Fred Solaris 2.7 Have you tried Apache 1.3.6 and mod_ssl 2.2.8-1.3.6 ? mehul -- "I dont want to start / Any blasphemous rumours / But I think that God's gotta sick sense of humour / And when I die I expect to find him laughing " - Depeche Mode "Blasphemous Rumours" __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Celebrity Deathmatch? (was Re: What is the difference between apache-ssl and apache-modssl?)
Thanks guys this is great stuff. Very entertaining.
Cheers, g-
"Ralf S. Engelschall" wrote:
On Wed, May 05, 1999, Ben Laurie wrote:
[...]
d) Apache-SSL supports DSOs.
Are you sure, Ben? At least I still cannot image how you support DSO while
Apache-SSL still uses direct symbol references between the Apache core and the
apache_ssl module (the big "no-no" for DSO). Either you mean something
different by DSO ("DSO support" usually means an apache_ssl.so can be built
and used) or my knowledge of DSO lacks some details.
I mean that any other DSO can be used.
Ahh, ok. Then you speak about different types of DSO support for Apache-SSL.
Sure, there is no reason why other modules cannot be used as a DSO with
Apache-SSL. But usually the question is whether Apache-SSL itself can use the
DSO mechanism, of course.
Since SSL can be disabled easily,
it isn't a big deal that Apache-SSL itself can't be a DSO. And nor can
mod_ssl in any useful sense of the word: you still have to patch Apache
in the first place.
Hmmm.. the actual point is flexibility, Ben: For instance ISPs usually have
very different customer requirements. So they want to make a generic Apache
installation and run various custom Apache instances out of this single and
shared installation. When you have to always built mod_ssl+OpenSSL into the
httpd, it's bloated up for all customers while usually only 10% of them really
need the SSL functionality. For these situations the DSO facility was mainly
added to Apache. Because it allows you to assemble the functionality under
startup-time and not under built-time. That's very important when you've to
administrate lots of webservers.
Sure, I know that you can argue with some copy-on-write and other Unix
VM-system related issues when it comes to final runtime differences. But keep
in mind that the stuff is usually not only a technical issue. Customers want
their server as clean and small as possible and don't accept any unused large
overheads (even when you can technically argue that it's not a problem).
And the
reason for the possibility to spawn an external program is to allow people to
plug-in smart card applications or similar stuff without patching mod_ssl. It
doesn't increase security, of course. But that's not the goal of this
feature...
It reduces security, which is why I don't support it.
Why does the possibility reduces security, Ben? It's same same as this: Just
because you've the possibility to remove the pass phrase from a private key
doesn't mean that security is reduced in general. It's only reduced when you
use this possibility. Same for the use of an external program. It's neither
more nor less secure then removing the pass phrase. But it's a different
approach which can help people in some situations. Sorry, I still cannot
accept the argument that this possibility itself makes anything less secure
than not having this possibility. As long as you don't use it, nothing
changes. And when you use it all you've to remember is that nothing will
change from the security point of view - only the technical approach changes.
h) replacing gcache with DBM seems a backward step to me.
You've still not said "why"? Because of the DBM key/value size restrictions?
Or because of the lower access? The size restriction is actually no real
problem, because it only means some very large certificate chains cannot be
cached. The lower access might be an argument, but keep in mind that for
mod_ssl 2.3.0 I've already written a shared memory based alternative which
beats both gcache and DBM caches in performance, of course. BTW, the reason
why I've replaced gcache with a DBM approach was not performance: It was
stability.
Because DBM is a single-user facility, so it is highly inefficient.
You speak about the mutex issue? Hmm... in practice I was never able to find
the processes blocking very long. So when it comes to efficieny I would count
more the disk I/O overhead. But even for this a good DBM library needs only 2
seeks plus a small read I/O burst. But sure, it's slower than gcache, no
doubt.
Although gcache was a bit troublesome at first, there is no stability
problem I know of, and I use it for many production systems.
Fine. Yes, and gcache can be very interesting when it also comes to some
tricks (for instance running the cache on a different server). But in general
I wanted to avoid spawned processes and DBM was the only possibility until
shared memory exists. For mod_ssl 2.3.0 I'll go the shared memory way now I've
implemented the MM library. This way I can provide at least again maximum
efficieny and performance.
Also, I notice that parts of that FAQ were written by me, yet strangely
there is no credit [...]
Correct. The reason is that you already get proper credit on more prominent
locations (even directly on the website welcome
Re: modssl + modperl + Apache 1.36
Hello again, I was wondering if anybody had been able to look at this. I'm still experiencing the same difficulties, and nothing shows up in the error logs, nada. The code only partially parses, and it's really baffling me. I have confirmed the code works ok under plain mod_perl. If you need anymore information, I'm willing to provide. Any suggestions? Justin On Mon, 3 May 1999, Justin K. Ream wrote: Date: Mon, 3 May 1999 10:30:49 -0700 (PDT) From: Justin K. Ream [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: modssl + modperl + Apache 1.36 Hello all, Has anyone had any success combining modssl and modperl? With modssl-2.2.8 (for 1.3.6) and modperl 1.1.9, my code does get handled correctly. I'm using the Apache::ePerl module for mod perl, and it seems that with a large dynamic index page I'm doing, only about half my code gets parsed. Only a few options show up in my select lists, my DSN's show up (bad! Nono! user accounts and passwords). With plain mod perl, everything works fine. I have the proper Files and Directory directives setup, I believe. Any help would be much appreciated as secure traffic is pretty important to a project I'm working on (I work for an HMO). I followed the instructions under "Apache + mod_ssl/OpenSSL + mod_perl/Perl". Directory /foo/bar/html Options Indexes FollowSymLinks ExecCGI AllowOverride None Order allow,deny Allow from all /Directory PerlModule strict CGI Apache::ePerl Apache::DBI Apache::Registry DBI Files ~ ".+\.phtml$" SetHandler perl-script PerlHandler Apache::ePerl /Files Thanks, Justin -- __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
US Appeals Court rules crypto export rules unconstitutional
Not sure how far this will go, but the Ninth Circuit has specified that source code is protected free speech in support of Professor Bernstein's original victory. http://www.news.com/News/Item/0,4,0-36217,00.html __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
