Nsopenssl
An AOLserver socket driver module which implements SSL/TLS encryption on incomming sockets, and also adds an https client API.
See: SF CVS: nsopenssl/
Author: Scott Goodwin
Dossy's debugging notes:
SourceForge Bug: empty HTTPS request causes null ptr deref. Interim patches available for download attached to the bug.
Testing with:
$ openssl version OpenSSL 0.9.7d 17 Mar 2004
$ openssl s_client -connect panoptic.com:443 -showcerts -msg -ssl2 $ openssl s_client -connect panoptic.com:443 -showcerts -msg -ssl3 $ openssl s_client -connect panoptic.com:443 -showcerts -msg -tls1
1. If the certificate and key .pem files aren't in the modules/nsopenssl dir, the server will still start up (and logs an error) and will accept SSL connections, but causes the server to spin with the following error:
12/Aug/2004:16:41:495459.1088261040-nsopenssl:reader- Debug: SSLOp(19-0): SSL_ERROR_SSL: bytes = 199; total = 0; rc = -1 12/Aug/2004:16:41:495459.1088261040-nsopenssl:reader- Error: nsopenssl (server1): SSL error on reading data
Is it ever possible to service a SSL request if you don't have the server certificate loaded? If we can't load the cert, perhaps we shouldn't open the socket for listening and accept connections on it.
2. The example nsd.tcl that's provided in the nsopenssl specifies "SSLv3, TLSv1" for the server protocols. An SSLv2 client connection causes a similar SSL error as above. Adding "SSLv2" to the list seems to make SSLv2 requests work just fine.
3. "maxinput" for nsopenssl is configured differently than it is for nssock -- see TIP: configuring "maxinput" for nsopenssl which I'll include a copy of here:
In recent versions of AOLserver 4.0, there's a new config parameter for
socket drivers (nssock, nsopenssl) called "maxinput" that limits the
size of the HTTP request, defaulting to 1,024,000 bytes. For most
sites, this may be a suitable default to prevent resource-starvation
style Denial of Service attacks. However, if your application allows
for large HTTP requests (such as file uploads that exceed 1MB in size),
you will need to crank the knob on the "maxinput" parameter suitably
high for your needs.
For nssock, this is pretty straightforward:
ns_section "ns/server/${servername}/module/nssock"
ns_param maxinput expr 1024 * 1024 * 100
This would set "maxinput" to 100MB. However, if you're using nsopenssl,
you may think that a similar config section like this should work:
ns_section "ns/server/${servername}/module/nsopenssl"
ns_param maxinput expr 1024 * 1024 * 100
But, it doesn't! (Ross Simpson and I found this out the hard way, with
two hours of much gnarly debugging and head-scratching.) So, how DO you
set "maxinput" for nsopenssl?
Well, nsopenssl has a "ssldrivers" config section, that might look like
the following:
ns_section "ns/server/${servername}/module/nsopenssl/ssldrivers"
ns_param example "an example server"
That defines the ssldriver named "example". You set parameters for it
(like you do for nssock) in this config section:
ns_section "ns/server/${servername}/module/nsopenssl/ssldriver/example"
ns_param sslcontext example_ctx
ns_param port 443
# ... etc ...
ns_param maxinput expr 1024 * 1024 * 100
Yes, you define parameters like "maxinput" and "recvwait" and other
socket-related settings in THIS section! Yes, this is where those
settings belong.
Interesting bug: in at least nsopenssl (and perhaps nssock), if maxinput
is reached, the server seems to sleep or simply spin, instead of
returnig some kind of error ("400 Bad Request / request exceeds
maxinput" or somesuch). So, the diagnostic behavior is if you're
uploading a large file that exceeds maxinput, the browser just appears
to be still sending the file and it never finishes (until "recvwait"
seconds elapse, I believe).
Here's an issue that Bruno Mattarollo is experiencing on MacOS X 10.3.5 using the latest AOLserver and nsopenssl 3.0 beta code. See this gdb backtrace and look at Thread #4. Infinite loop that spins the CPU to 100%.
Here's a simple ADP page used to reproduce the nsopenssl-related hanging:
<% ns_sleep 10 %> test
http://listserv.aol.com/cgi-bin/wa?A2=ind0408&L=aolserver&P=32616
On 2004.08.24, Noah Robin <sitz@AOL.NET> wrote: ... > > FWIW, there's a file descriptor leak in beta 17. On Solaris, it > manifests as an ever-increasing number of connections in the BOUND > state, as reported by netstat. I know, 'cause I reported it to Scott, > who fixed it shortly thereafter. =)
