Forum OpenACS Development: Proposed corrections to OpenACS default nsopenssl configuration

} else {

    #--------------------------------------------------------------------------------------------------
    # OpenSSL for Aolserver 4
    #--------------------------------------------------------------------------------------------------
    #
    # Configuration for nsopenssl v3.x modified by Richard Hamilton on 10-26-2010
    # (email: mailto:richard.hamilton@webteamworks.com), based on example configuration from README in
    # source code directory of nsopenssl.
    #
    # Note 1: nsopenssl.so v3.x supports multiple contexts for ssl connections in Aolserver v4.5
    #         so that you can configure multiple ssl listeners for each virtual server. For example,
    #         for each virtual server, you might wish to have different listeners for users and
    #         admins, and a third context for outgoing ssl connections (the 'client' context).
    #
    #         However, in OpenACS the security::locations proc has the nsopenssl context hard-coded
    #         as 'users'. Therefore, for Openacs up to the current version (5.6.0 as at 102610)
    #         you must only configure one context and it must be called 'users'. For this reason
    #         the example naming convention (of the form 'vs1_user_ctx') has not been used since
    #         it would be meaningless until OpenACS instances read their SSL context using ns_config.
    #         This forum post refers: http://www.openacs.org/forums/message-view?message_id=2983032
    #
    # Note 2: If you do configure more than one listener, each MUST have its own dedicated SSL key.
    #         This makes sense since otherwise there would be no point in opening up another port.
    #
    # Note 3: Code has been added that checks for the presence of the required key and certfiles for
    #         the OpenACS default context 'users'. The nsopenssl module will not load unless
    #         'users_cert.pem', 'users_key.pem', and './ca/users_cacert.pem' exist.
    #
    #         The default location assumed for key and certificate files is :
    #             /usr/local/aolserver/servers/${server}/modules/nsopenssl
    #
    #
    #--------------------------------------------------------------------------------------------------

    set httpsport_users $httpsport ;# Multiple contexts cannot share ports.

    ns_section "ns/server/${server}/module/nsopenssl"
        ns_param RandomFile /proc/kcore
        ns_param SeedBytes 1024
        # ServerPort is required by procs in acs-tcl/tcl/security-procs.tcl to find the https port.
        ns_param ServerPort           $httpsport_users
        # setting maxinput higher than practical may leave the server vulnerable to resource DoS attacks
        # see http://www.panoptic.com/wiki/aolserver/166
        # must set maxinput for nsopenssl as well as nssock
        ns_param   maxinput           [expr {$max_file_upload_mb * 1024 * 1024}] ;# Maximum File Size for uploads in bytes

    ns_section "ns/server/${server}/module/nsopenssl/sslcontexts"
        ns_param users        "SSL context used for regular user access"
    #    ns_param admins       "SSL context used for administrator access - not supported by OpenACS"
    #    ns_param client       "SSL context used for outgoing script socket connections - not supported by OpenACS"

    ns_section "ns/server/${server}/module/nsopenssl/defaults"
        ns_param server               users ;# Hard-coded into openACS security::locations proc
    #    ns_param client               client

    ns_section "ns/server/${server}/module/nsopenssl/sslcontext/users"
        ns_param Role                  server
        ns_param ModuleDir             ${homedir}/servers/${server}/modules/nsopenssl
        ns_param CertFile              users_cert.pem
        ns_param KeyFile               users_key.pem
        ns_param CADir                 ca ;# Directory containing certificate of signing authority
        ns_param CAFile                ca/users_cacert.pem
        # for Protocols                "ALL" = "SSLv2, SSLv3, TLSv1"
        ns_param Protocols             "SSLv3, TLSv1"
        ns_param CipherSuite           "ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP"
        ns_param PeerVerify            false
        ns_param PeerVerifyDepth       3
        ns_param Trace                 false


#    ns_section "ns/server/${server}/module/nsopenssl/sslcontext/admins"
    #    ns_param Role                  server
    #    ns_param ModuleDir             /path/to/dir
    #    ns_param CertFile              admins_cert.pem
    #    ns_param KeyFile               admins_key.pem
    #    ns_param CADir                 ca
    #    ns_param CAFile                ca/admins_cacert.pem
        # for Protocols                "ALL" = "SSLv2, SSLv3, TLSv1"
    #    ns_param Protocols             "SSLv3, TLSv1"
    #    ns_param CipherSuite           "ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP"
    #    ns_param PeerVerify            false
    #    ns_param PeerVerifyDepth       3
    #    ns_param Trace                 false

#    ns_section "ns/server/${server}/module/nsopenssl/sslcontext/client"
    #    ns_param Role                  client
    #    ns_param ModuleDir             /path/to/dir
    #    ns_param CertFile              client_cert.pem
    #    ns_param KeyFile               client_key.pem
    #    ns_param CADir                 ca
    #    ns_param CAFile                ca/client_cacert.pem
        # for Protocols                "ALL" = "SSLv2, SSLv3, TLSv1"
    #    ns_param Protocols             "SSLv3, TLSv1"
    #    ns_param CipherSuite           "ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP"
    #    ns_param PeerVerify            false
    #    ns_param PeerVerifyDepth       3
    #    ns_param Trace                 false

    # SSL drivers. It is possible to configure multiple driver connections within a single
    # virtual server, with each allocated to its own named SSL context.However this feature is
    # not supported by OpenACS. Each driver defines a port to listen on and an explicitly named
    # SSL context to associate with it.
    ns_section "ns/server/${server}/module/nsopenssl/ssldrivers"
        ns_param users         "Driver for regular user access"
    #    ns_param admins        "Driver for administrator access"
    #    ns_param client        "Driver for outgoing ssl connections"

    ns_section "ns/server/${server}/module/nsopenssl/ssldriver/users"
        ns_param sslcontext            users
        ns_param port                  $httpsport_users
        ns_param hostname              $hostname
        ns_param address               $address
        # following added per
        # http://www.mail-archive.com/aolserver@listserv.aol.com/msg07365.html
        # Maximum File Size for uploads:
        ns_param   maxinput           [expr {$max_file_upload_mb * 1024 * 1024}] ;# in bytes
        # Maximum request time
        ns_param   recvwait           [expr {$max_file_upload_min * 60}] ;# in minutes

#    ns_section "ns/server/${server}/module/nsopenssl/ssldriver/admins"
    #    ns_param sslcontext            admins
    #    ns_param port                  $httpsport_admins ;# Not set up in OpenACS config.tcl
    #    ns_param hostname              $hostname
    #    ns_param address               $address

#    ns_section "ns/server/${server}/module/nsopenssl/ssldriver/client"
    #    ns_param sslcontext            client
    #    ns_param port                  $httpsport_client ;# Not set up in OpenACS config.tcl
    #    ns_param hostname              $hostname
    #    ns_param address               $address
}

What version of config.tcl are you working from?

cvs head doesn't seem to have the duplicate condition statement as far as I can tell: http://fisheye.openacs.org/browse/OpenACS/openacs-4/etc/config.tcl?r=HEAD

What are the logfile errors you were seeing that this proposal resolves?

Torben

Hardcoding the pem files to that location won't work for OSes that place aolserver somewhere else in the file hierarchy (such as freebsd).

The server should be able to read the pem files of any os when they are located within $serverroot, which is why the config.tcl currently references them at ${serverroot}/etc/certs by default.

The files need to be accessible by the running aolserver, and so should be given the usual file permissions for that.

If for some reason, it's decided to make these changes to config.tcl, a moduleroot variable should be defined early in config.tcl for this use, since aolserver modules are placed in various locations in various OSes and distributions.

cheers,

Torben

The context "admin" is basically there as a documented example, if one wants to have multiple contexts. It is commented out by default.

The client context is setup for outbound SSL connections. It's only activated if nsopenssl module is activated.

What messages do you see in the logfile that indicates there is a problem?

I'm all for documentation improvements. What is unclear? I can see how there should be a note in config.tcl nsopenssl/defaults section stating that a separate set of files must be used for each context.. What else?

No negative criticism was considered etc from here; I'm sorry if my message seemed that way. I'm earnestly trying to figure out what the problem is so we can fix it. I've been using nsopenssl since y2k, so I lack having a fresh look at it.

Similarly, the thread you reference is early nsopenssl 3.0 release from 2003. The issues seem to be dealt with already. The current config.tcl mirrors Scott Goodwin's example AFAICT. config.tcl also has ns_section "ns/server/${server}/module/nsopenssl/defaults"

I don't know that there's a simple way around removing the default contexts 'users' and 'client'. As I understand it, the full flexibility of nsopenssl is available as is. If one wants to define another context, define it by using the 'admin' context as an example.

There's some config.tcl files out there that show how to setup virtual servers using http, and some discussion of revising the OpenACS default config.tcl to use that format. I like the idea, especially if it adds flexibility to installations and doesn't just add more work.

OpenACS has host-node mapping for serving multiple domains from one aolserver instance (incompletely implemented). Using virtual servers may be a cleaner way of accomplishing this, but I believe would lack sharing of db pools between instances.

https has an added requirement that each domain requires a different certificate/key (unless you're using self-signed certificates and don't mind the browser messages). Since CA cert/keys are an added cost, usually an organization splits the deployment into separate aolserver instances per key (and IP), to avoid any issues of two or more keys sharing the same IP address (different subdomains and/or ports). Often a requirement of a purchased key is that it runs on it's own IP for security reasons.

So, how is OpenACS limited with these contexts? Removing hard-coded things can be a good idea, but how is OpenACS limited by these hard coded contexts? What is the full flexibility of nsopenssl that OpenACS is not leveraging?

cheers,

Torben

Okay, I think we can address your last two points. I find it's less problematic during installation to append the CAcert to the end of the CA issued cert, but that's not a good reason to not do this.

So, uncomment the CA.pem line, and add a comment that CA.pem can alternately be commented out and appended to certfile.pem. By CA.pem, I assume you are referring to the CAFile and CADir values in ns/server/${server}/module/nsopenssl/sslcontext/users. CA.pem is currently only found in the Aolserver 3.3 nsopenssl part of config.tcl.

There's another clean up point that should be addressed at the same time:

removing '+SSLv2:' from users context CipherSuite.

Anything else?

A couple of other points to go towards this process:

1) This morning I tried to run the installer using a config.tcl based on the one shipping with 5.6.0 only to find that the installer couldn't talk to the db (PostgreSQL). The driver had loaded fine and reported successfully opening the pools in the error log. No errors appeared in the ns_log output.

However as soon as the installer tried to talk to the db to write the data structures, it discovered that it couldn't find psql.

I fiddled around for a while checking the env for the server, and finding nothing amiss then set up nscp and started poking around. I traced the problem to db_get_pgbin and ran through the proc stepwise in the control port.

The upshot is that I reckon that whoever last edited the master version of config.tcl was an Oracle user!! 😉

Why?

Please see lines 526 to 530:

http://cvs.openacs.org/browse/OpenACS/openacs-4/etc/config.tcl?r=HEAD

See anything missing? 😊

2) Lines 399-401 are not helpful guidance. It was on the basis of the 'fixes welcome' that I started this thread. I think the default config.tcl for OpenACS ideally should not announce that it will throw errors and invite fixes.

3) Lines 476-481. Personally I am not happy with the 'might stabilise'. I think we should avoid including settings that differ from defaults without a positive and proven rationale. This does not sound confident enough to earn its place.

Regards
Richard

When I said whoever last edited it, I didn't mean literally 'the last person to touch it'! I hadn't checked who it was, and I certainly wasn't trying to blame Gustaf!! God forbid! 😊

What is needed there is:

if { $database eq "oracle } {
    blah blah blah
  } else {
    ns_section "ns/db/driver/postgres"
    ns_param    pgbin        /usr/local/pgsql/bin
}

I also had assumed that the path to psql was derived from the PATH environment variable for the user Aolserver was running as, but today I learned from my efforts that this is not in fact the case. On my installations, when I run 'nsd -it /path/to/config.tcl -u user -g group' from inittab, and then log into nscp and type 'env get path', the value for PATH in the nsd environment is not the same as the PATH value that the user sees in a tty.

Correct me if I am wrong, but I conclude therefore that Aolserver therefore doesn't source the user's environment when launched from inittab with '-u user'. This would be analogous to the case of 'su user' vs. 'su - user'.

Consequently, this config parameter would seem to be essential. Adding it solved the problem for me!

Regards
Richard

On my distribution the PATH that the user switched Aolserver is passed is that niether of root nor the user to which it is switched.

I am sure that there probably is a way to do this with the environment variables, but why bother fiddling with that when a config entry specifically configures the server? In any case, if you want to configure a server to a specific version of PostgreSQL (i.e. also running an old ACS 4.6.3 site), this provides an elegant mechanism for doing it.

This config declaration certainly used to be in the config file and has been in my own config.tcl for over ten years.

Also, adding it completes the param structure and results in symmetry! 😉 Perhaps it is my obsessive nature, but why leave something out that has potential benefits just because it can be left out?

Regards
Richard

One more clarification, it's perfectly OK for you to have your config file do anything you want; I didn't mean to imply otherwise, what I meant was that the default config supplied by openacs should be free of having to do that.