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

See also: nsnss, nsssl

---

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:49][5459.1088261040][-nsopenssl:reader-] Debug: SSLOp(19-0): SSL_ERROR_SSL: bytes = 199; total = 0; rc = -1
 [12/Aug/2004:16:41:49][5459.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. =)

---