Re: [AOLSERVER] How to use nsopenssl 3.x?
On Tue, Sep 30, 2003 at 04:11:56AM -0400, Andrew Piskorski wrote: Since we didn't have any built in virtual server support at all in AOLserver 3.x, I imagine there are many people converting from 3.x to 4.0 who would be perfectly happy to have NO virtual server support for the time being, but who need a working nsopenssl in order to switch to 4.0. I myself fall into this group. I, and the company I work for, also fall into this category. We need nsopenssl before we can switch to 4.0. -Roberto -- +|Roberto Mello -http://www.brasileiro.net/ |--+ + Computer Science Graduate Student, Utah State University + + USU Free Software GNU/Linux Club - http://fslc.usu.edu/ + Do HD's sneeze when they catch a virus? -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] How to use nsopenssl 3.x?
On Mon, Sep 29, 2003 at 10:32:30PM -0400, Scott Goodwin wrote: 7. Virtual servers in AOLserver 4.0 adds a lot more complexity to the code -- virtual server state must be kept to ensure that one virtual server cannot access another virtual server's structures and data. I realize this must be awfully late in the coding to bring up, but: Would it greatly simplify or speed up things to release a first version of nsopenssl which works with AOLserver 4.0, but does NOT support virtual servers in any way? Since we didn't have any built in virtual server support at all in AOLserver 3.x, I imagine there are many people converting from 3.x to 4.0 who would be perfectly happy to have NO virtual server support for the time being, but who need a working nsopenssl in order to switch to 4.0. I myself fall into this group. Thanks for the feedback. I've decided to split nsopenssl into two modules. The nsopenssl module will now be entirely focused on AOLserver's comm-driven connections. The nshttps module will focus on creating and using SSL connections using a Tcl API. That sounds good. But do you plan to make this happen for the release of AOLserver 4.0 (whenver that might be), or at some later date, or? The only downside to separating the two modules is that a significant portion of the code will be duplicated. At this point I don't really That doesn't sound so good. care about that and will revisit whether I want to have both modules generated from (some) common files, or if I want to turn the common portions of both into a loadable library on its own after we have some experience with the modules in operation. In any case, both modules will retain their separate identities. Well, that also sounds reasonable. First get it working, then refactor. So, both the nsopenssl and nshttps loadable modules will remain part of the current nsopenssl project in CVS, share the makefiles, etc.? Since you'll want to refactor the code again soon anyway, I hope you'll keep the separation in the codebase between the two new loadable modules as close as possible... -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] How to use nsopenssl 3.x?
On Tuesday, September 30, 2003, at 04:11 AM, Andrew Piskorski wrote: I realize this must be awfully late in the coding to bring up, but: Would it greatly simplify or speed up things to release a first version of nsopenssl which works with AOLserver 4.0, but does NOT support virtual servers in any way? Virtual server support is already in the code and works for comm-driven connections. Since we didn't have any built in virtual server support at all in AOLserver 3.x, I imagine there are many people converting from 3.x to 4.0 who would be perfectly happy to have NO virtual server support for the time being, but who need a working nsopenssl in order to switch to 4.0. I myself fall into this group. AOLserver 4.0 not only supports virtual servers, every server you create *is* a virtual server, even if you run just one server. Thanks for the feedback. I've decided to split nsopenssl into two modules. The nsopenssl module will now be entirely focused on AOLserver's comm-driven connections. The nshttps module will focus on creating and using SSL connections using a Tcl API. That sounds good. But do you plan to make this happen for the release of AOLserver 4.0 (whenver that might be), or at some later date, or? For the AOLserver 4.0 release. /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] How to use nsopenssl 3.x?
Thanks for explaining the nsopenssl config section Scott. Let me give you some feedback of what I've found so far. Nsopenssl appears to perform well for the most part. However, nsopenssl writes several empty error messages to the log. Can't tell what they are related to. More importantly though making a client connection using ns_httpsopen results in the following error: [29/Sep/2003:18:14:58][20762.65541][-conn:demo::0] Error: : nsopenssl: error creating sslconn-ssl structure The server subsequently hangs and doesn't respond to requests anymore. /Bart -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] How to use nsopenssl 3.x?
Thanks for the feedback. I've decided to split nsopenssl into two modules. The nsopenssl module will now be entirely focused on AOLserver's comm-driven connections. The nshttps module will focus on creating and using SSL connections using a Tcl API. I've made the decision to split this effort in two for the following reasons: 1. The nsopenssl codebase is becoming unwieldy to develop and maintain. Having three types of SSL connections, one of which is the normal comm-driven type, makes the codebase rather complex. 2. The nsopenssl 2.x Tcl API supports Tcl commands that work with comm-driven conns, but that do not work with SSL conns generated by the nsopenssl Tcl API itself (I'm talking about ns_openssl_sockopen, ns_openssl_sockcallback, etc.). To support non-comm-driven connections I have to use thread-local storage to keep track of SSL conn structures, making the code even more complicated. 3. The https.tcl module is a hack. Based on recent discussions I've been watching here, it has problems, some of which originate with nsopenssl.so itself. https.tcl will be replaced with nshttps.so. 4. Most people who run nsopenssl only want the ability to drive AOLserver comm-driven connections anyway, and aren't interested in creating their own SSL servers and clients using nsopenssl's Tcl API. 5. The configuration file is becoming too complex in order to support SSL contexts separately from SSL drivers and connections. 6. Having nsopenssl focus on the comm-driven connections will allow me to focus on its performance. The performance of non-comm-driven connections is not a major issue since there are not as many of these types of connections, and there isn't a user sitting at the other end of them; usually you use these to connect to another SSL host. 7. Virtual servers in AOLserver 4.0 adds a lot more complexity to the code -- virtual server state must be kept to ensure that one virtual server cannot access another virtual server's structures and data. Having separate code bases will allow me to focus on the security of the comm-driven nsopenssl module much more effectively. 8. The non-comm-driven SSL connections rely on Tcl channels so that you can use puts, gets and friends on them. The channel code adds complexity to nsopenssl that is not required for the comm-driven connections. 9. Testing has become a pain. Every change requires that I test both the comm-driven connection capability and the non-comm-driven capabilities. While much of this testing can be automated, it is important that the comm-driven capability is extensively tested on its own. The only downside to separating the two modules is that a significant portion of the code will be duplicated. At this point I don't really care about that and will revisit whether I want to have both modules generated from (some) common files, or if I want to turn the common portions of both into a loadable library on its own after we have some experience with the modules in operation. In any case, both modules will retain their separate identities. For the confused, a comm-driven connection is one that is actually serviced by AOLserver core, over which I overlay the SSL portion. Non-comm-driven connections are those where the sockets and SSL overlays are both generated and maintained by the nsopenssl module itself. I have already gutted nsopenssl and I will be releasing the slimmed down, tighter version of nsopenssl first. nshttps will follow. /s. On Monday, September 29, 2003, at 09:28 PM, Bart Teeuwisse wrote: Thanks for explaining the nsopenssl config section Scott. Let me give you some feedback of what I've found so far. Nsopenssl appears to perform well for the most part. However, nsopenssl writes several empty error messages to the log. Can't tell what they are related to. More importantly though making a client connection using ns_httpsopen results in the following error: [29/Sep/2003:18:14:58][20762.65541][-conn:demo::0] Error: : nsopenssl: error creating sslconn-ssl structure The server subsequently hangs and doesn't respond to requests anymore. /Bart -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] How to use nsopenssl 3.x?
I'd like to experiment with nsopenssl 3.x on AOLServer 4.x. I'm aware that nsopenssl 3.x isn't production ready yet. Still, I'd like run some experiments but I'm not quite clear how to use the new design. Following the README file, I've configured nsd.tcl as per the 2.x instructions. However, I'm at a loss how to define contexts and drivers for virtual servers. The Design paragraph at the end of the README file mentions how the new workflow uses the contexts and drivers defined in nsd.tcl but doesn't include examples. Scott, would you be so kind to enlighten me? Thanks, /Bart -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] How to use nsopenssl 3.x?
Scott, would you be so kind to enlighten me?
Certainly. Important parts of my test config are at the bottom of this
message. Here's how it works:
At start time, nsopenssl reads the config sections for SSL contexts and
SSL drivers. Each SSL context and each SSL driver has a unique name
within that virtual server. You can reuse the same names in a different
virtual server, but not a good idea for readability perhaps.
SSL contexts define the characteristics of SSL instances you want to
create; they're essentially templates. You can have any number of
templates. An SSL template can be associated with an SSL driver, an
nsopenssl-created client or an nsopenssl-created server. Some confusion
exists about these last two. nsopenssl works in two modes: local and
nsd-driven. An SSL driver is tied to a core nsd connection, and all
bytes are piped through the AOLserver HTTP processing engine.
nsopenssl-created clients and servers are local to the nsopenssl module
and are not associated with the core server at all. Using the nsopenssl
Tcl API you can create incoming or outgoing SSL connections without the
core server's HTTP engine being involved. If there's still confusion
about the difference, let me know and I'll try to find a better way to
explain it.
An SSL driver can listen on one and only one port. But you can have
multiple drivers defined for a virtual server. Each driver most be
associated with a single SSL context. When a connection comes in on a
port that an SSL driver is listening in, it uses the SSL context it's
associated with to generate an SSL instance, which contains the info
about what ciphers are allowed etc.
In the config below I have two contexts and two drivers. One driver
I've labeled as a user access point, the other as an admin access point.
The main goals of this release are to be virtual-server compliant, to
decouple SSL contexts from SSL drivers and the nsopenssl-created
connections, and to ensure that you only need to load one copy of an
nsopenssl module to handle any number of virtual servers and ports.
Digest all this; more later if you need it. The config stuff at my site
is out of date for this new release. I'm moving my site to a new hoster
where I can run AOLserver.
/s.
config:
set vs1_servernamevs1
set vs1_serverdescVirtual Server 1
set vs1_httpport 7000
set vs1_hostname 127.0.0.1
set vs1_address 127.0.0.1
set vs1_pageroot ${homedir}/servers/${vs1_servername}/pages
# Global nsopenssl settings
ns_section ns/server/module/nsopenssl
ns_param RandomFile /some/file
ns_param SeedBytes 1024
...normal AOLserver stuff here...
#
# nsopenssl (HTTPS)
#
# Virtual Server specific nsopenssl configurations
# SSL contexts. Each SSL context is intended to be a complete definition
# of an SSL instance. An SSL context may be used by multiple drivers,
# sockservers and sockclients.
ns_section ns/server/${vs1_servername}/module/nsopenssl/sslcontexts
ns_param vs1_users_ctxSSL context used for regular user access
ns_param vs1_admins_ctx SSL context used for administrator
access
ns_section
ns/server/${vs1_servername}/module/nsopenssl/sslcontext/vs1_users_ctx
ns_param Role server
#ns_param ModuleDir /path/to/dir
ns_param CertFile server-cert.crt
ns_param KeyFile server-cert.key
#ns_param CADir serverca
#ns_param CAFileserverca.pem
ns_param Protocols SSLv3, TLSv1
ns_param CipherSuite
ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
ns_param PeerVerifyfalse
ns_param PeerVerifyDepth 3
ns_param Trace true
ns_param SessionCache true
ns_param SessionCacheSize 128
ns_param SessionCacheTimeout 300
ns_section
ns/server/${vs1_servername}/module/nsopenssl/sslcontext/vs1_admins_ctx
ns_param Role server
#ns_param ModuleDir /path/to/dir
ns_param CertFile server-cert.crt
ns_param KeyFile server-cert.key
ns_param CADir serverca
ns_param CAFileserverca.pem
#ns_param Protocols All
ns_param Protocols SSLv3, TLSv1
ns_param CipherSuite
ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
ns_param PeerVerifyfalse
ns_param PeerVerifyDepth 3
ns_param Trace true
ns_param SessionCache true
ns_param SessionCacheSize 128
ns_param SessionCacheTimeout 300
# SSL drivers. Each driver defines a port and a named SSL context to
associate
# with it.
ns_section ns/server/${vs1_servername}/module/nsopenssl/ssldrivers
ns_param vs1_users_drvDriver for vs1 regular user access
ns_param vs1_admins_drv Driver for vs1 administrator access
ns_section
ns/server/${vs1_servername}/module/nsopenssl/ssldriver/vs1_users_drv
ns_param sslcontextvs1_users_ctx
ns_param port 7001
ns_param hostname 127.0.0.1
ns_param address
