Per Wikipedia, "Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It is used for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL."  (https://en.wikipedia.org/wiki/HTTPS , accessed 23 Jul 2020)

Many, if not most LISTSERV sites will want to secure their LISTSERV web interface using the HTTPS protocol.

There are two major and one optional components to making this change:

      1. Obtain and install a digital certificate on the web server running on your LISTSERV host machine, and ensure that your web server can be reached using the HTTPS protocol
      2. Configure LISTSERV and WA to serve HTTPS links
      3. (Optional) Enable HSTS for LISTSERV

Component One:  Obtain and install the digital certificate

The first component must be accomplished by the customer without assistance from L-Soft.  It involves obtaining a digital certificate which is in turn installed on the LISTSERV machine's web server, following which the web server must be configured to enable the HTTPS protocol.  Because there are several different approaches to this, we recommend careful research before starting this process.  Google (whose search engine has for several years given HTTPS sites preferred weighting) has a help page at this link which explains the process in some detail, although it does not provide specifics for different web servers.

Once your web server has been properly configured to use the HTTPS protocol, test it by navigating to a test page on your server using HTTPS.  (Most web servers provide a test page in the document root by default when they are installed.)  Ensure that you get the lock character in the address bar that indicates that you have connected securely.  For instance (see circled in red):

You may also test to ensure that your server certificate is correctly installed by using the SSL Checker found here.  If you want a more in-depth scan run of your server and its security protocols, you can try the SSL Server Test found here.  (The latter test is extremely in-depth and will take a couple of minutes to run.)

If all is well, you may then proceed to the second major component, which is configuring LISTSERV itself to serve HTTPS links via WA.

Component Two:  Configure LISTSERV and WA to serve HTTPS links

First, you'll need to change the WWW_ARCHIVE_CGI variable in your SITE.CFG file (Windows) or go.user file (unix) to use HTTPS.  This means you'll need to specify the full URL that points to WA.EXE (Windows) or wa (unix) instead of providing just a relative link.  For example, you may have (for Windows)

WWW_ARCHIVE_CGI=/scripts/wa.exe


In that case, you would need to change the setting to

WWW_ARCHIVE_CGI= https://listserv.yourhost.com/scripts/wa.exe


For unix, you will probably have

WWW_ARCHIVE_CGI=/cgi-bin/wa


In that case, you would need to change the setting to

WWW_ARCHIVE_CGI= https://listserv.yourhost.com/cgi-bin/wa


Note that the hostname (highlighted in yellow) will be the same as the value in the NODE= site configuration setting.

For both Windows and unix servers, you'll need to restart LISTSERV after making this change.

Note: While it is possible to change the value of WWW_ARCHIVE_CGI using the web administration interface, we recommend that this change be made manually in the top-level site configuration file, as explained above.


For LISTSERV 17.0 and later, it is no longer necessary to edit the SKIN template to enable HTTPS, as the template has been revised to detect whether or not you are using https.

Optional Component:  Enable HSTS in LISTSERV

Again, from Wikipedia:  "HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone. . . . The protection only applies after a user has visited the site at least once, and the way this protection works is that a user entering or selecting a URL to the site that specifies http, will automatically upgrade to https, without making an http request, which prevents the http man in the middle attack from occurring."  (https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security, accessed 23 Jul 2020)

The LISTSERV web interface can enable HTTP Strict Transport Security (HSTS), which directs browsers to only connect to the web interface using secure HTTPS connections. Unencrypted HTTP connections are automatically replaced with HTTPS connections at the browser level, preventing the transmission of unencrypted data to the server. The use of HSTS is also required for many US federal agencies by US BOD 18-01.

The LISTSERV site configuration variable, WWW_HSTS_MAX_AGE, when set to a non-zero value, causes WA to output the header "Strict-Transport-Security: max-age=x", where "x" is the non-zero variable setting.  For example:

Unix:

WWW_HSTS_MAX_AGE=31536000

export WWW_HSTS_MAX_AGE


Windows:

WWW_HSTS_MAX_AGE=31536000


(The number "31536000" is the number of seconds in one year, and is the recommended value.  The HSTS timeout in the web server's "Strict-Transport-Security: max-age" parameter is always declared in seconds.)

Again, this feature is intended primarily to address the US DHS directive BOD 18-01, but will enhance security for any LISTSERV site which uses the HTTPS protocol in the LISTSERV web interface.

Notes: WA functions named DEBUG-* (e.g., DEBUG-SHOW-VERSION) may not load the configuration file, and therefore might not output the Strict-Transport-Security: header.

Also note that if you already have the webserver configured for HSTS, the webserver HSTS value may override the setting provided by WA.

With HSTS enabled site-wide in IIS, you may find that:

- The "archives" directory no longer works correctly if it is implemented as an IIS virtual directory

- Some images served by WA.EXE may be broken

WWW_HSTS_MAX_AGE can be used to solve this problem rather than enabling site-wide HSTS in IIS.