Re: licencing
On Thu, Oct 29, 1998 at 06:57:09PM +0100, Ralf S. Engelschall wrote: We already discussed this stuff recently (look inside the sw-mod-ssl archives for the details please). So it would be nice when one of the US citizens on this list who know the current state of their law better than me can write a short and compact entry for the mod_ssl FAQ. Perhaps someone of us finishes this possible skeleton: | Q: Can I use mod_ssl inside the United States? | A: Yes, but you have to buy BSAFE from RSA DSI for $3000...bla bla You need to buy the BSAFE development libraries (although 4.0 exists, only 3.0 is available for linux, but this is sufficient, since 4.0 seems to only add stuff that doesn't apply to SSL), for $295 (w/o tech support). Depending on your situation, RSA's licensing of BSAFE differs. One of the options is to pay a one-time licensing fee for a per-user license, and there's also some kind of an annual licensing fee structure (but it didn't apply to my situation so I ignored that bit). A one-time 100-user license is $3000, 250-user is $4000, 500-user is $6000, 1000-user is $9000--and it goes on from there. (Prices, subject to change, of course...) Then you need to integrate the BSAFE 3.0 libraries with SSLeay, similar to (but not the same as) how rsaref was compiled in. You'll also need to link things differently when you compile your Apache+mod_ssl/ApacheSSL. -- Jake Buchholz http://www.execpc.com/~jake ExecPC Senior Systems Administrator [EMAIL PROTECTED] __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: licencing
On Thu, Oct 29, 1998, Jake Buchholz wrote: On Thu, Oct 29, 1998 at 06:57:09PM +0100, Ralf S. Engelschall wrote: We already discussed this stuff recently (look inside the sw-mod-ssl archives for the details please). So it would be nice when one of the US citizens on this list who know the current state of their law better than me can write a short and compact entry for the mod_ssl FAQ. Perhaps someone of us finishes this possible skeleton: | Q: Can I use mod_ssl inside the United States? | A: Yes, but you have to buy BSAFE from RSA DSI for $3000...bla bla You need to buy the BSAFE development libraries (although 4.0 exists, only 3.0 is available for linux, but this is sufficient, since 4.0 seems to only add stuff that doesn't apply to SSL), for $295 (w/o tech support). Depending on your situation, RSA's licensing of BSAFE differs. One of the options is to pay a one-time licensing fee for a per-user license, and there's also some kind of an annual licensing fee structure (but it didn't apply to my situation so I ignored that bit). A one-time 100-user license is $3000, 250-user is $4000, 500-user is $6000, 1000-user is $9000--and it goes on from there. (Prices, subject to change, of course...) So the minimum you have to pay is $295+$3000 for a 100-user Apache+mod_ssl based webserver, right? Then you need to integrate the BSAFE 3.0 libraries with SSLeay, similar to (but not the same as) how rsaref was compiled in. You'll also need to link things differently when you compile your Apache+mod_ssl/ApacheSSL. Oh, that's interesting. Can you give me details so I can add BSAFE support to the INSTALL file and the libssl.module script (different -l, -L options, etc.)? What I at least need to know is: 1. Is BSAFE API compatible to RSAref? (when yes this mean SSLeay's RSAglue works, when not what else have to be used as the glue code) 2. What is the filesystem layout of the BSAFE dev libs package, i.e. where is the libxxx.a (for -L) and include files (for -I) and how are they named (xxx=bsafe for -l?, bsafe.h?) Can you give us some details? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: licencing
On Thu, 29 Oct 1998, a wrote: Hi all, So what is the deal with using mod_ssl and SSLeay for a site that is making some money? Does everyone actually buy a RSA license? Is it possible to? It all seems confusing. There is a commercial product coming out shortly that will use mod_ssl for $99. I'll send out a release closer to its publishing date. The current in-store date is Nov. 18. It'll be at CompUSA, Best Buy, Fry's, etc. Mark __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: licencing
On Thu, 29 Oct 1998, Ralf S. Engelschall wrote: On Thu, Oct 29, 1998, a wrote: So what is the deal with using mod_ssl and SSLeay for a site that is making some money? Does everyone actually buy a RSA license? Is it possible to? It all seems confusing. We already discussed this stuff recently (look inside the sw-mod-ssl archives for the details please). So it would be nice when one of the US citizens on this list who know the current state of their law better than me can write a short and compact entry for the mod_ssl FAQ. Perhaps someone of us finishes this possible skeleton: | Q: Can I use mod_ssl inside the United States? | | A: Yes, but you have to buy BSAFE from RSA DSI for $3000...bla bla | This is correct. BSAFE is a pain the the ass to work with and VERY spendy. The contracts on its use are also very restrictive. | Q: Ok, but can I use mod_ssl inside the United States without charge? | | A: In general no, because of RSA, RC4, etc. patents but there are some |exceptions (RSAref+private-site, goverment organisations, etc.) |Bla bla.. RSAREF can't be used for much of anything anymore unfortunately. They change the rules on it more often than pigs roll in the mud. Mark __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
mod_proxy Patch error
Hello,
I just tried to compile a SSL-patched (mod_ssl-2.0.13) apache version,
but *without* activating mod_ssl:
gcc -c -I../../os/unix -I../../include -DSOLARIS2=251 -DMOD_PERL
- -DUSE_HSREGEX -DSERVER_SUBVERSION=\"PHP/3.0.3\" -O2 -DFPX_CORE_PATCH
- -I/usr/local/include `../../apaci` proxy_http.c
proxy_http.c: In function `ap_proxy_http_handler':
proxy_http.c:251: `use_ssl' undeclared (first use this function)
proxy_http.c:251: (Each undeclared identifier is reported only once
proxy_http.c:251: for each function it appears in.)
Ralf: you missed one ifdef around lines 251-253 within proxy_httpd.c
(just checked with current developer version @ engelschall.com)
There are also missing some conditional Makerules, to prevent
to make the certificate stuff, if mod_ssl is disabled.
patch for mod_proxy: ('+' marks missing lines within the following patch)
***
*** 205,211
if (urlptr == NULL)
return HTTP_BAD_REQUEST;
urlptr += 3;
! destport = DEFAULT_HTTP_PORT;
strp = strchr(urlptr, '/');
if (strp == NULL) {
desthost = ap_pstrdup(p, urlptr);
- --- 248,257
if (urlptr == NULL)
return HTTP_BAD_REQUEST;
urlptr += 3;
+#ifdef MOD_SSL
! if (use_ssl)
! destport = DEFAULT_HTTPS_PORT;
! else
+#endif
! destport = DEFAULT_HTTP_PORT;
strp = strchr(urlptr, '/');
if (strp == NULL) {
desthost = ap_pstrdup(p, urlptr);
Thanks again for creation and working on mod_ssl.
Jan
__
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Patch for Win32
I saw a few posts in the archives looking for a port of Patch for win32. here is the one i used. (compiled fine, with some warnings. seems to work good in initial testing) binary and patched source http://www.halcyon.com/tzs/ Chris __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Patch for Win32
On Fri, Oct 30, 1998, Dave Paris wrote: Email over the exe and I'll create a self-extracting exe for you. Just let me know where it should default (expand) to. Oh, I was not precise enough. What I actually want is not only a self-extracting program. My favorite would be that when I run patch.exe it extracts itself (in memory on in current working dir) and immediately runs itself. So I can use the packed patch.exe similar to the unpacked patch.exe. At least under my C64 times the years ago this was common practice. Exists such stuff for Windows NT? Or did I misunderstand you and you mean exactly this? Then it should unpack into the current working directory because this is maximum portable, IMHO. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: mod_proxy Patch error
Hello again, There are also missing some conditional Makerules, to prevent to make the certificate stuff, if mod_ssl is disabled. Hm `make certificate' needs to know SSL_BASE and other stuff. This is only calculated when mod_ssl is actually enabled. So there is no chance to ru n `make certificate' when mod_ssl is not enabled. But I will add a check for this, so one gets an error message when one tries to run `make certificate' under this situation. Thanks for this hint, too. You misunderstood my request I think: It's (maybe also) the problem with 'make certificate', but also a problem for 'make all' (while trying to build the additional mod_ssl tools) [...] Thanks again for creation and working on mod_ssl. No problem. But look forward for 2.1b7 which gets released the next hours: It contains your DSO support where I then need your feedback and review again, You will get it very soon, but maybe not before Monday afternoon. (MET) Meanwhile I'm trying to get DSO mod_perl working at Solaris ... Jan __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Patch for Win32
On Fri, 30 Oct 1998 12:26:21 GMT, Ralf S. Engelschall [EMAIL PROTECTED] wrote: On Fri, Oct 30, 1998, Dave Paris wrote: Email over the exe and I'll create a self-extracting exe for you. Just let me know where it should default (expand) to. Oh, I was not precise enough. What I actually want is not only a self-extracting program. My favorite would be that when I run patch.exe it extracts itself (in memory on in current working dir) and immediately runs itself. So I can use the packed patch.exe similar to the unpacked patch.exe. At least under my C64 times the years ago this was common practice. Exists such stuff for Windows NT? Or did I misunderstand you and you mean exactly this? Then it should unpack into the current working directory because this is maximum portable, IMHO. Ralf, I don't see your point here. Why do you want to compress the patch.exe file? The tarball distribution is a compressed file itself. Do you have difficulty putting binary file into CVS? I notice you have patch's source files in ./etc and compile and run it for UNIX platforms. Can we do the same for Win32? The user must have the C compiler in any case. I can prepare the makefile and modify Configure.bat accordingly. -trung P.S. Info-ZIP can (almost) do what you want: compress the file, add a small executable stub to that. The resultant file is a self-extracting file, which extracts itself in a working dir. The catch is that the stub is of fixed size; for small files (like patch.exe), it's too big. patch.exe (~120K) - patch_exe.zip (~60K) ... unzipsfx.exe + patch_exe.zip ... patch_exe_zip.exe (~150K) Not good. __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ANNOUNCE: mod_ssl 2.1b7 (DSO support!)
A lot of fixed and enhancements took place between 2.1b6 and 2.1b7. The most
noticeable enhancement (as I mentioned a few days ago) is Dynamic Shared
Object (DSO) support for mod_ssl. Read http://www.apache.org/docs/dso.html for
more details about DSO and the top-level INSTALL file of mod_ssl and Apache
for installation instructions.
Also as already mentioned last time the DSO support for mod_ssl was not a
trivial change. No, actually I completely rewrote the SSL patch for the Apache
core code into a Extended API (EAPI) patch. This EAPI provides the necessary
flexibility to mod_ssl (and other modules) to both loosely couple those
modules with the Apache core code _and_ also allow loosely communication
_between_ modules. For instance when libssl.so is not loaded (LoadModule
directive) mod_proxy is not HTTPS-Client-aware. Once you load libssl.so
(without any chance for libproxy.so) you get HTTPS-Client support in
mod_proxy. Same for mod_log_config. Unless libssl.so is loaded the %{xxx}c
format is not known. Once you loaded libssl.so the %{xxx}c is available.
Please notice that this is pure _runtime_ and not _compile_ time ;-)
But now it's your turn. After Martin Kraemer and I yesterday have workaround
subtle compiler problems inside the hook mechanism it works fine. (really
interesting: under GCC passing a union and a va_list to a function results in
different values depended where the union is placed in the argument list,
etc.). What we now need is _YOUR_ feedback to make the stuff 100% stable for
2.1.0. So please grab this 2.1b7 stuff any try it out on your platform.
PS: Trung or others: It should be now possible to also build mod_ssl
as a .DLL under Win32. I've no experiences here, so I hope you
contribute a few patches to me which allows us to build mod_ssl
the same way other Apache modules are build.
BTW: With this last EAPI changes, mod_ssl now really has the correct name:
mod_ssl, i.e. it's now _really_ a stand-alone SSL _module_ ;-)
Because all SSL stuff is only done and provided here.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
Changes with mod_ssl 2.1b7 (09-Oct-1998 to 30-Oct-1998)
*) Fixed DBM access stuff: An invalid argument was given by the
NDBM emulation layer of DB under FreeBSD 2.2.6.
*) Moved all Crypto/SSL stuff from mod_log_config.c, mod_proxy.c and
proxy_http.c to the new ssl_engine_ext.c file. Now SSLeay is _ONLY_
needed for linking the mod_ssl code itself. There is no more any SSLeay
symbol reference outside mod_ssl.
*) Rewrote the ap_hook mechanism to provide support for loosly coupling
modules together, too. Also support is now provided for up to 8
arguments in function signatures.
*) Added support for a SSL Product ID. To the mod_ssl/x.x.x-y.y.y
string inside libssl.version you now can append a string product/x.x.x
and then you get -DSSL_PRODUCT=hex-value-of-x.x.x,
-DSSL_PRODUCT_NAME="product", -DSSL_PRODUCT_VERSION="x.x.x" and a HTTP
Server field similar to this one: ``Server: Apache/1.3.3 (Unix)
MyStuff/1.0.0 mod_ssl/2.1b7 SSLeay/0.9.0b''. This can be used by RH SWS
or the other forthcoming mod_ssl based SSL product to add the version
string without patching ;-)
*) The ca-fix tool is now generated at the `make certificate' step
on-demand only because it's only needed here. And when mod_ssl is not
enabled this tool cannot be build at all (no SSLeay stuff known).
*) Created a new ssl_engine_io.c source file which now contains
all I/O and buffer related code, i.e. the new EAPI-based stuff plus
the Win32/SSLeay functions for buffer I/O.
*) Because with the help of the EAPI we were now able to add Dynamic Shared
Object (DSO) support for mod_ssl. For this the
src/modules/ssl/Makefile.tmpl, src/modules/ssl/libssl.module and
top-level configure files were adjusted.
*) Replaced SSL code inside mod_log_config.c with EAPI based
code which mainly tries to lookup mod_ssl variables. For this the
ssl_engine_vars.c stuff now exports the ssl_var_lookup() function as the
"ssl::var::lookup" hook.
*) Replaced all hard r-connection-client-ssl references with the
now loosely based ap_ctx_get(r-connection-client-ctx, "ssl").
*) SSL patches - Generic Extended API patches:
Completely rewrote the Apache code patches: Instead of patching in SSL
specific hooks we now patch in an Extended API which provides mainly the
following new features:
- generic low-level hooks mechanism:
ap_hook_{init,kill},
ap_hook_{configure,register,unregister},
ap_hook_{configured,registered,call}
- buffer hooks:
ap::buff::{read,write,recvwithtimeout,sendwithtimeout}
- generic context mechanism:
Re: licencing
On Fri, Oct 30, 1998 at 09:58:57AM +0100, Ralf S. Engelschall wrote: On Thu, Oct 29, 1998, Jake Buchholz wrote: You need to buy the BSAFE development libraries (although 4.0 exists, only 3.0 is available for linux, but this is sufficient, since 4.0 seems to only add stuff that doesn't apply to SSL), for $295 (w/o tech support). Depending on your situation, RSA's licensing of BSAFE differs. One of the options is to pay a one-time licensing fee for a per-user license, and there's also some kind of an annual licensing fee structure (but it didn't apply to my situation so I ignored that bit). A one-time 100-user license is $3000, 250-user is $4000, 500-user is $6000, 1000-user is $9000--and it goes on from there. (Prices, subject to change, of course...) So the minimum you have to pay is $295+$3000 for a 100-user Apache+mod_ssl based webserver, right? If you're an ISP and want to have up to 100 virtual hosted secure servers, yes--I'm not sure what the price would be if you just wanted to run your own secure server without any virtual hosted customers; I'm assuming that a different licensing plan and price may apply. Also, the license (from what I've been told) doesn't apply to just one server. For instance, if you've got 10 servers, and 10 secure virtual host customers on each, you'd be covered by a 100-user license. Then you need to integrate the BSAFE 3.0 libraries with SSLeay, similar to (but not the same as) how rsaref was compiled in. You'll also need to link things differently when you compile your Apache+mod_ssl/ApacheSSL. Oh, that's interesting. Can you give me details so I can add BSAFE support to the INSTALL file and the libssl.module script (different -l, -L options, etc.)? What I at least need to know is: 1. Is BSAFE API compatible to RSAref? (when yes this mean SSLeay's RSAglue works, when not what else have to be used as the glue code) Similar? Yes. Drop-in compatible? Alas, no. Key defines are different, functions seem to be slightly different parameter-wise, and there's extra memory-manipulation code that it wants (analogues to memcpy, malloc, etc. that do extra checking.) Linking BSAFE to SSLeay requires "bsafeglue". 2. What is the filesystem layout of the BSAFE dev libs package, i.e. where is the libxxx.a (for -L) and include files (for -I) and how are they named (xxx=bsafe for -l?, bsafe.h?) I've got my BSAFE libraries in /usr/local/lib/bsafe, includes in /usr/local/include/bsafe (only really needed for SSLeay). I added '-L/usr/local/lib/bsafe' to the end of LDFLAGS1 and '-lssl -lcrypto -lbsafeglue -lbsafe -ltstdlib' to the end of LIBS1. Can you give us some details? I'd love to pass along more information (It'd make things easier for me to recompile each time a new version of SSLeay, Apache, or mod_ssl came out ;) but I'm not sure to what extent I'm allowed to help. (Seeing as how I'm in the states, yadda yadda...) Also, I was lucky enough to have found someone who had successfully linked SSLeay with BSAFE's RSA and RC4 routines--and that's the _real_ trick--so I'd need to ask his permission for any sharing along those lines. -- Jake Buchholz http://www.execpc.com/~jake ExecPC Senior Systems Administrator [EMAIL PROTECTED] __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ANNOUNCE: mod_ssl 2.1b7 (DSO support!)
On Fri, 30 Oct 1998 16:48:26 GMT, Ralf S. Engelschall [EMAIL PROTECTED] wrote: PS: Trung or others: It should be now possible to also build mod_ssl as a .DLL under Win32. I've no experiences here, so I hope you contribute a few patches to me which allows us to build mod_ssl the same way other Apache modules are build. Done. I'm going to make DLL the default for Win32, just like the other modules. The name is ApacheModuleSSL.DLL. Okay? Please, wait until Monday. I clean it up a little and send you a diff. (I've just added a few export declarations and modified the Makefile) -trung __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: licencing
On Fri, 30 Oct 1998, Jake Buchholz wrote: I'd love to pass along more information (It'd make things easier for me to recompile each time a new version of SSLeay, Apache, or mod_ssl came out ;) but I'm not sure to what extent I'm allowed to help. (Seeing as how I'm in the states, yadda yadda...) That is the joys of the laws here.. :/ Also, I was lucky enough to have found someone who had successfully linked SSLeay with BSAFE's RSA and RC4 routines--and that's the _real_ trick--so I'd need to ask his permission for any sharing along those lines. I was looking for info on this and ran across a page with a patch that took care of it for the most part. I'll look up the URL and see if I can re-find it. Most people I found that had done this integration were tight lipped on how they did it which was alittle frustrating, even with offers of consulting $$. Mark __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Re[2]: licencing
On Fri, 30 Oct 1998, Whit Blauvelt wrote: Will this product use it in a way that it can be incorporated into a custom-compiled Apache? The best product for many uses would put the minimum wrapping around RSA's stuff needed to have them consider it a valid license, and preserve the user's access to the maximal amount of code in the freeware tradition - and most importantly, it should allow the immediate upgrade of Apache as soon as a new version is released (which would probably require immediately-available compiled modules over the Net for registered customers?). If Mark's product is something less than that, I hope someone else is pursuing this business plan. Unfortunately, the source isn't included at this time. I'm going to re-read the license closer as its not that clear on what can be distributed and what can't. If it turns out I can distribute it, there will be an announcement to registered users. There will be upgrades made available as soon as new versions of mod_ssl and apache are available. They will be downloadable from my web site. It will be available for RedHat at first (and come with the full version of RedHat), but it will be ported to other UNIXes soon. Mark __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
In article [EMAIL PROTECTED] you wrote: [...a interesting discussion on the apache-ssl list with Ben Laurie whether assertions in server code are reasonable or not...] The discussion is pointless unless you can indicate a way in which it makes Apache-SSL function incorrectly. How about this scenario: | rse@en1:/e/apache/RELEASES/apache_1.3.3/src/modules/ssl | : ./gcache rse 12346 | [Fri Oct 30 22:28:26 1998] ./gcache started | [1] 29497 | rse@en1:/e/apache/RELEASES/apache_1.3.3/src/modules/ssl | : echo "hello" | socket localhost 12346 | request was 104 | assertion "!"Unknown request"" failed: file "gcache.c", line 166 | [1]+ Abort trap (core dumped) ./gcache rse 12346 | rse@en1:/e/apache/RELEASES/apache_1.3.3/src/modules/ssl | : So on a typical system an attacker who gained access to _any_ account (not necessarily the UID of the httpd or the gcache process) can simply dropping down gcache and this way all httpds by just sending garbage to the gcache port. And although you don't want to hear this: With mod_ssl's ssl_gcache program this doesn't happen because all assertions are already replaced with check which pass error codes to the callers. | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | : ./ssl_gcache rse 12346 | [1] 29897 | [Fri Oct 30 22:35:43 1998] ssl_gcache: started | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | : ps -ax | grep ssl_gcache | 306 ?? I 0:00.03 ssl_gcache 65534 12345 | 29897 p0 S 0:00.02 ./ssl_gcache rse 12346 | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | : echo "hello" | socket en1 12346 | [Fri Oct 30 22:35:54 1998] ssl_gcache: unexpected connect from 192.76.162.40 - |ignored | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | : echo "hello" | socket en1 12346 | [Fri Oct 30 22:35:55 1998] ssl_gcache: unexpected connect from 192.76.162.40 - |ignored | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | : echo "hello" | socket en1 12346 | [Fri Oct 30 22:35:55 1998] ssl_gcache: unexpected connect from 192.76.162.40 - |ignored | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | : echo "hello" | socket en1 12346 | [Fri Oct 30 22:35:56 1998] ssl_gcache: unexpected connect from 192.76.162.40 - |ignored | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | : echo "hello" | socket en1 12346 | [Fri Oct 30 22:35:56 1998] ssl_gcache: unexpected connect from 192.76.162.40 - |ignored | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | : ps -ax | grep ssl_gcache | 306 ?? I 0:00.03 ssl_gcache 65534 12345 | 29897 p0 S 0:00.02 ./ssl_gcache rse 12346 | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | : And now I ask me why _isn't_ this better? I don't understand it, Ben. IMHO this non-assertion way _is_ better, because it prevents the system from being dropped down (kind of DoS) by a local attacker Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re:[apache-ssl] Invalid method in request)
On Fri, 30 Oct 1998, Ralf S. Engelschall wrote: So on a typical system an attacker who gained access to _any_ account (not necessarily the UID of the httpd or the gcache process) can simply dropping down gcache and this way all httpds by just sending garbage to the gcache port. What does gcache do? What does someone gain by being able to gain access to it? Can they do anything beyond DoS attacks? | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | : ./ssl_gcache rse 12346 | [1] 29897 | [Fri Oct 30 22:35:43 1998] ssl_gcache: started | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | : ps -ax | grep ssl_gcache | 306 ?? I 0:00.03 ssl_gcache 65534 12345 | 29897 p0 S 0:00.02 ./ssl_gcache rse 12346 | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | : echo "hello" | socket en1 12346 | [Fri Oct 30 22:35:54 1998] ssl_gcache: unexpected connect from 192.76.162.40 - ignored Actually, Ben's code does the exact same thing in this case. In your previous example, you connected to localhost. __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
