Securing Access with SSL

As described in the section regarding the use of non-standard ports and installing behind a firewall, the LISTSERV Maestro components can be configured in a way that users and/or administrators can access the Maestro User Interface and/or the Administration Hub with a web browser from anywhere on the Internet. This feature allows, for example, LISTSERV Maestro to be set up in an ASP-environment, where the customers access the application over the Internet.

Providing access to users from the Internet exposes the risk of unauthorized access. LISTSERV Maestro uses password authentication as a first barrier against intruders. However, network traffic is a public affair. Anyone with the right knowledge and access to certain nodes in the network may eavesdrop on the communication between the user’s browser and the LISTSERV Maestro server. Intruders may gain knowledge about the data that is sent to the user’s browser (for display) and sent back to the server (to trigger a certain action or to submit settings the user made). Even more dangerous, the intruder could find out the user name and password that the user or administrator employs for login, and could then log him/herself in with the same account.

If security is a concern, consider securing access to the LISTSERV Maestro servers with encrypted communication, so that intruders cannot listen in on the communication between browser and server, and cannot gain knowledge about the data exchanged or spy out passwords. All standard browsers support encrypted communication using Secure Sockets Layer (SSL), and the HTTPS protocol to access web pages, instead of the normal HTTP protocol.

LISTSERV Maestro also offers the possibility of using SSL for communication with the Administration Hub and/or the Maestro User Interface components. Since topics such as encryption, server certificates, and trusted authorities are so complex, an introduction is presented in Section 18.1 Introduction to Secure Communication to assist understanding the concepts involved, making the execution of the required steps easier. Implementation instructions start in Section 18.2 Which Components Should Be Secured?.

Securing access with SSL (HTTPS) as described in this section is a separate issue from authenticating and encrypting communication between the components of LISTSERV Maestro, even though the two have many similarities and can even be combined.

Note: To authenticate and encrypt the communication between the separate components of LISTSERV Maestro please refer to the L-Soft White Paper entitled Authenticating and Encrypting Communication between LISTSERV Maestro Components.

This section is intended to provide a short introduction about the basics of secure communication. Please see the many publications about this topic for more details.

For successful encrypted communication to take place, one partner holding an “encryption key” encrypts the data. The data is transferred to the second partner and decrypted using the same “key”. One requirement is that both communication partners know the encryption key so that the receiving partner may decrypt the data that was encrypted by the sending partner.

With online communication, however, this is more complex. Both partners (the browser and the server) are most likely communicating with each other for the first time, and do not have a common encryption key that is known only to them. So, when the connection is first established, the two partners must secretly decide at the spur of the moment on an encryption key that will be used for the rest of the communication (this is a simplified view of the matter, but it explains the basics).

Assuming that both partners have decided what key to use, they can now communicate in an encrypted manner. There is still the problem of being sure that each partner is actually communicating with the partner they think they are communicating with. An analogy to this problem can be found in real life. Suppose that two employees of two partner companies meet in a hotel to exchange confidential information. The two have never met each other, but they know each other’s names and home addresses. How can each of them be sure that the other person they meet in the lobby of the hotel is actually the person they are supposed to meet and not an impostor?

An impostor could act as a “man-in-the-middle”. He meets with employee A of corporation A-Corp in the lobby and poses as employee B of corporation B-Corp. Thus, he gains confidential information from A and goes into the bar where he meets the real employee B. Here he poses as employee A from A-Corp, gives the confidential information from the “real” A to B and receives similar information back from B. Finally, he goes back into the lobby relays the information he received from B to the “real” employee A. On his way from the lobby to the bar and back, he made copies of the information he was carrying. In the end, both employee A and B are unaware that they did not talk to their “real” counterparts, but to an impostor that acted as a “man-in-the-middle”, and the impostor goes back to his employer C-Corp with the confidential information he gained from their competitors.

On a network, this “man-in-the-middle” attack is even easier to mount. The only thing that a server and a client know of each other is their network addresses, which can easily be forged. In real life, the two employees of A-Corp and B-Corp would probably request to see some picture ID with name and home address of their communication partner. They would then compare the picture on the ID with the person they are talking to and verify that the name and address on the ID matches the ones they have previously been told. If the ID matches the person, they would be confident that they are talking to the right person.

However, in doing so, they actually implicitly trust a third party that has not yet been involved. This would be the agency that issued the picture ID. By accepting the ID, they trust that the agency has created an ID that is hard to forge. They also trust that this agency has, in turn, verified that the person they issued the ID to really is the person he claims to be. If employee A had tried to use his library card for identification, then employee B would probably have rejected it as improper identification, because she would not trust either that the clerk in the library responsible for issuing the ID really did a thorough check of A’s identity, or she did not trust the security features of the ID, (these days anyone can create an authentic looking ID with the help of a color laser printer). Instead, she would probably request a “proper” ID like a passport or driver’s license.

With online communication, the problem of identifying the communication partner is solved very similarly. In the online world, “certificates” fulfill the role of a “picture ID” in real life. A certificate asserts that the owner of the certificate is, in fact, the entity it claims to be. For example, a certificate could assert that the server with the host name “host.somecorp.com” actually is a server that belongs to SomeCorp, and that it is not an impostor’s server.

How can such credibility problems be solved? Simply falsifying a file that states, “Yes, the server ‘host.somecorp.com’ is indeed a server belonging to the SomeCorp Corporation,” would not be cumbersome for an imposter. To guard against this, the certificate is digitally signed by a trustworthy authority, so that it now reads, “Yes, the server ‘host.somecorp.com’ is a server belonging to the SomeCorp corporation, and we, the people from TrustCorp have verified that this is indeed so.”

The digital signature is very useful because it prevents anyone from tampering with the certificate. If even a single letter (or byte) in the text of the certificate is changed, the signature will no longer match and the certificate will be invalid. However, a last problem remains: how to test the validity of the signature? The digital signature of the certificate was created using a signature key. The signature key consists of two parts, a private key and a public key. The signer (the signing authority) uses both parts to create the signature. The private key is held secret by the signer so that only the signer is able to use it to create a signature and a signature cannot be created with the public key alone.

The public key on the other hand is made public. It can be used by anyone who desires to test the validity of a digital signature that is supposed to come from the owner of the public key. With a certain algorithm, the signature is tested against the public key, producing a result that states (if the signature was valid): “Yes, the data signed by this signature has not been tampered with and it was signed with a private/public key pair, where the public key matches the public key that was used to test the signature.”

If the signature was not valid, the result could be, “The data was tampered with since it was signed,” in which case the data seen by the recipient is not the original data that the signer saw. Or, the result could be, “The data was signed with a private/public key pair, where the public key does not match the public key used to test the signature.” In this case the data was signed by someone else than the owner of the public key the recipient has. In both cases, the signature is invalid.

It is not possible to use any public key that is found anywhere (or given by any one), because who would then guarantee that the public key received really is a key from the entity it supposedly belongs? The origin of the public key that is used to verify the digital signature of a certificate has to be very reliable; otherwise, the “man-in-the-middle” would still have a chance to spy. The intruder would create his own public/private keys with a forged name of “TrustCorp” and his own certificate with a forged host name of SomeCorp. Then he would use his own private key to sign the certificate and would give others the public key claiming, “This is the public key of TrustCorp”. If this public key were used to check the validity of the forged certificate, a match would be made leading to the belief that the forged certificate is legitimate. As a result, the attacker would receive the communication and not the server of TrustCorp.

To verify a public key of the signing authority, most web browsers, like Microsoft® Internet Explorer, are already equipped with a list of trusted so called “root certificates.” It is not necessary to verify that these certificates indeed come from the entity they claim to, because the browser vendor has already verified this.

The full trust-chain when a browser is used to access a secured is described as follows:

•

The browser trusts any signed certificate with a genuine certificate traceable to one of the trusted root certificates. This can be a very short chain such as, for example, “a certificate signed with a root certificate” or a long chain such as for example, “a certificate signed with a certificate that was signed with a certificate … etc. … that was signed with a root certificate.”

In the real life example, employees A and B both needed picture IDs to verify each other. With online communication, this verification is often only one-sided. For most purposes it is enough that the client is certain about the server it communicates with. It is usually not required that the server is also certain about the client. Therefore, usually only the server has a certificate (which is, down the trust chain, signed by a trusted root certificate) and the client does not.

There are also real-world examples of this. If a car were purchased privately from its former owner, the buyer would most likely request to see a picture ID of the owner during the transaction. Otherwise she would risk unknowingly buying a stolen car. On the other hand, it is not a requirement for the former owner to see the buyer’s ID to check the car’s legitimacy.

To summarize the concepts introduced:

•	Server Certificate – This certificate asserts that a certain server (with the given host name) actually belongs to a certain organization, so that the server can be trusted and confidential data can be safely communicated. This certificate is digitally signed to prevent tampering and falsification.

•

Trusted Root Certificate – The trusted root certificate is used to sign the actual server certificate (or another certificate down the trust-chain is used to sign the actual server certificate). Usually the fact that a root certificate is installed together with trusted software (like the browser) already makes it a trusted root certificate. A root certificate can be received by other means (by email, for example). In that case, first verify the certificate before it is rated as “trusted.” To do this, compare the fingerprints on both the sent and received certificates.

•

Encrypted Communication – This is made possible with the help of an encryption key, which is secretly generated when the communication first begins. Verifying that there is no “man-in-the-middle” while negotiating the encryption key is achieved by verifying the communication partner’s certificate and matching its digital signature, to one of the trusted root certificates, further down the trust-chain.

Only the Maestro User Interface and/or the Administration Hub component should be secured with SSL - never the Maestro Tracker component. The Maestro Tracker component always requires use of normal HTTP; it cannot be configured to use HTTPS (because the collection of the tracking events needs to be fast, HTTPS is too slow for this).

As all components installed on one server share the same access method, it is necessary to select the access method for all components simultaneously. Therefore, if it is desired to secure the Administration Hub and/or Maestro User Interface components with SSL, they must be installed on a separate server (or separate servers) from the Maestro Tracker component (however, both may be on the same server, as long as they are both secured). Similarly, if only one component is to be secured (either the Administration Hub or the Maestro User Interface), then each component has to be secured on a separate server. This will permit security of one independent of the other.

To enable LISTSERV Maestro to use HTTPS by way of SSL, obtain a signed server certificate for the server to be secured. It is not possible to simply obtain any server certificate and use it on any server. The certificate is always bound to the explicit server name that was chosen when the certificate was created. If the LISTSERV Maestro component is moved to a different server (with a different name), or the server is renamed, then a new certificate for the new name would have to be obtained.

Obtaining a server certificate involves three basic steps:

•	Create a certificate-signing request (CSR) from that certificate and send it to a certification authority (CA). The CA first verifies that the requester is genuine, and then returns a signed version of the certificate to him/her.

Certificate administration happens with a command line tool called “keytool”, that is installed together with Java. For more information about this tool, and further discussion about certificates and secure communication, see the relevant documentation at Sun’s web site: http://java.sun.com/j2se/1.4/docs/tooldocs/win32/keytool.html

As a first step when starting to use certificates, be sure to secure the default keystore for trusted root certificates that is shipped with Java. The Java version that is installed together with LISTSERV Maestro includes a keystore that already contains trusted root certificates from some CAs (for example VeriSign and Thawte) This keystore is initially protected with the default password “changeit”, which should be changed as soon as possible after the installation of LISTSERV Maestro.

To change the password of the default keystore, execute the following command:

You will be queried first for the old password (which is changeit if it has not been changed since installation of LISTSERV Maestro), and then twice for the new password. Enter a new password with at least six characters, but longer and complex passwords are safer.

In Java, all certificates are stored in a “keystore,” which is usually a special file protected with a password.

To add a certificate to a keystore, execute the following command:

with the following replacements:

NAME: The name of the certificate. Can be any name that is not already in use in the keystore file specified (see below), but choose an informative name that helps in recognition of the certificate later.

DAYS: Limits the validity of the certificate. The certificate will expire so many days after the day it was created. This can be any number of days. Usually, when the signing service from the CA is purchased, only a limited period during which the certificate shall be valid is paid for. Choose a number of days for this parameter, which is no shorter than the period purchased from the CA (a little padding here is probably a good idea, to be on the safe side). It is also possible to create a certificate that has a very long validity period (several years), if desired.

KEYFILE: The keystore file to which the certificate will be added. This can be a relative or a full path name. If the file does not exist, it is created. If it already exists, a certificate with the given “NAME” is added to it.

Choose a suitable location and file name for the keystore file that takes into account the special security considerations for this file as outlined below.

Be very careful with the keystore file into which the certificate has been created. Protect this file in two respects:

The tool will first prompt for the entry of the password with which the keystore is protected. If an existing keystore is being used, enter its password. If a filename of a keystore that does not yet exist is given, then a new keystore will be created and it will be protected with the password that was entered at the first prompt (choose a password with at least six characters, remembering that longer and more complex passwords are safer).

Next, the tool will prompt for the following information values. Press RETURN each time to simply accept the default value “Unknown”. However, some values must be entered for the certificate to work and some CAs require other values to be filled out. So it is generally a good idea to fill out all values with whatever fits best in each case (see below):

Here, the host name of the server to be secured with the certificate being created must be entered. Yes, even though the question reads “your first and last name,” it is necessary to enter the host name of the computer instead! This should be the same host name that will be used in the URLs to access the server. For example, if the URL is “http://maestro.mycorp.com/lui”, then enter the host name “maestro.mycorp.com” (without the quotes).

After the last question is answered, a summary of the input and a request for confirmation will appear. Type “yes” and RETURN to accept the input, or “no” and RETURN (or simply RETURN) to reject it (in this case enter the values again until they are satisfactory). After the input is confirmed, the tool takes a few seconds to generate the certificate. When it is done, enter a password at the prompt to protect the certificate. Although generally any password is usable, for the certificate to be usable with LISTSERV Maestro, the same password chosen for the keystore itself must be used. To do so, simply press RETURN without entering anything, so that the default is accepted.

At this point, the certificate has been created, but it is yet unsigned.

Once an unsigned certificate has been created, generate a certificate-signing request (CSR) from it, which can then be submitted to a certification authority (CA), for example VeriSign.

To generate a CSR for a certificate in the keystore, execute the following command:

with the following replacements:

NAME: The name of the certificate. This must be the name of the certificate that the CSR is created for (the same name that was specified when the certificate was created).

OUTFILE: The file into which the CSR will be written. If the file already exists, it will be replaced with the new file. This can be a relative or a full path name.

KEYFILE: The keystore file in which the certificate is stored. This can be a relative or a full path name.

The command will request the password of the keystore. After it is entered, the file specified as “OUTFILE” will be written. This file is a text file that contains the CSR in Base64-encoded form.

-----BEGIN NEW CERTIFICATE REQUEST----- tPnJhsLOuocsBYAmyM11qiZ5BEVWAnJfZ6kyN/XfT5NFxGIy9Uynz5kODfBwFUgiu98iQKWyMKC/bGFuZ2VuMQ8wDQYDVQQKEwZMLVNvZnQxEDAOBgNVBAsTB1Vua25vd24xDzANBgNVBAMTBnRlcHBp6E7Zyl9wkPyVpn1qbnbtXQGAablJInE9/LruaJ1NX1f/NVJgL4vPiDKsU4laGvJHBNhdj+F0uVb 3SIb3DQEBBAUAA4GBAB6XqdfJvhy7dTHijsHjw+c4ELQFI/TkHBvgp5NaCccQoNwwW9lnIeOik Db2lwWg56G6LiYfpVBss5+OOW2jXlq9CdNw1KLSDQ+kMtZjdVr8+iQ9gsqxvskCAwEAAaAAMA0GCSqGMIIBpjCCAQ8CAQAwZjELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxETAPBgNVBAcTCEVyYzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAz+hQRsqDWRLvmV4YD5+JaQEXn5qqJeyzkfg2PQoU2VPgHID0VnyTPt8r/t4uFk8p1NxjYkC4 -----END NEW CERTIFICATE REQUEST-----

Now submit this CSR to the desired CA. For example, VeriSign offers an online order form that contains a field into which the text from the CSR can be simply pasted. Other CAs may do this differently – please ask the CA for help if there is any question, or if anything is unclear. After the CA has received the CSR, it will first verify that the requester or company is indeed genuine, that is if the content of the certificate can or cannot be trusted. This usually happens using methods such as making phone calls, checking company registrations, or other types of research, and may take a few days. Once the CA has verified the validity of the certificate, it will either be returned as a signed certificate, or instructions on how to obtain the signed certificate will be supplied.

The signed certificate received back from the CA must be in X.509 format; either in binary or Base64 encoded form (please contact the CA if the certificate received does not match either of these formats). Once the certificate has been received, store it into a file (usually “*.cer”). Then execute the following command:

with the following replacements:

NAME: The name of the certificate. This must be the name of the certificate that the CSR was made for (the same name that was specified when the certificate and the CSR were created).

INFILE: The file that contains the reply from the CA with the signed certificate.

KEYFILE: The keystore file in which the certificate is stored. This can either be a relative or a full path name.

The command will load the certificate from the given file, check the signature of the signer (the CA) against a trusted root certificate of the CA and, if the signature matches, replace the unsigned version of the certificate that was in the keystore with the signed version.

There is one critical moment here – when the tool tries to check the signature against a trusted root certificate of the CA: If this check cannot be made because such a trusted root certificate of the CA cannot be found, the tool will abort with an error message. In this case, obtain a trusted root certificate from the CA first (see Section 18.3.5 Installing a Trusted Root Certificate for more details) and then repeat the import step described above. Java is already shipped with trusted root certificates of certain CAs, like VeriSign and Thawte. For other CAs, obtain and install a root certificate first.

This step is only required if the signed server certificate was obtained from a CA for which a trusted root certificate is not already shipped with Java. An error message during the import of the signed certificate will occur if this is the case. The required root certificate should be available from the CA. The certificate must be stored in a file, either in “DER encoded binary X.509” or “Base-64 encoded X.509” format. If there is access to such a certificate file, import it into the keystore with the trusted root certificates by executing the following command:

with the following replacements:

NAME: The name to be given to the certificate in the keystore. This name is not important for anything, except for recognition later. In addition, this name must not yet be in use in the keystore.

INFILE: The file in which the X.509 certificate from the CA is stored.

The password of the default keystore file will be queried for, which should have been set to something other than its default “changeit” earlier. See Section 18.3.1 Securing the Trusted Root Certificate Keystore for more information. The command will present the details of the certificate to be imported in a way similar to Figure 18-2.

Owner: OU=For VeriSign authorized testing only. No assurances (C)VS1997, OU=www.verisign.com/repository/TestCPS Incorp. By Ref. Liab. LTD., O="VeriSign, Inc" Issuer: OU=For VeriSign authorized testing only. No assurances (C)VS1997, OU=www.verisign.com/repository/TestCPS Incorp. By Ref. Liab. LTD., O="VeriSign, Inc" Serial number: 52a9f424da674c9daf4f537852abef6e Valid from: Sun Jun 07 02:00:00 GMT+02:00 1998 until: Wed Jun 07 01:59:59 GMT+02:00 2006 Certificate fingerprints: MD5: 40:06:53:11:FD:B3:3E:88:0A:6F:7D:D1:4E:22:91:87 SHA1: 93:71:C9:EE:57:09:92:5D:0A:8E:FA:02:0B:E2:F5:E6:98:6C:60:DE Trust this certificate? [no]:

The presentation contains details about the certificate, but these could have been forged. It also contains the certificate’s fingerprints, which can be used to verify that the certificate has not been falsified. For example, if the certificate was emailed (thus giving a potential attacker the possibility to “catch” the email before it reaches its destination, and replacing the certificate therein with his own certificate for a future “man-in-the-middle” attack), then it is advisable to call the responsible person from the CA, to verify the fingerprint of the certificate over the phone.

Once the certificate is believed to be genuine, answer [Yes] and RETURN to the question “Trust this certificate?” After this is done, the certificate is installed as a new trusted root certificate in the default Java root certificate store, and can now be used to import server certificates signed by the CA from which the root certificate was obtained, as described in Section 18.3.4 Installing the Signed Server Certificate.

Tip: Internet Explorer comes (as many browsers do) with an extensive list of trusted root certificates. It also allows those certificates to be exported to a file in the X.509 format required for import by “keytool”. Therefore, if a CA is chosen to sign the server certificate for which there is no trusted root certificate already in the Java default keystore, it is very easy to locate a root certificate by exporting it from Internet Explorer as described below. This description is for IE 5.0, 5.5 and 6.0; other versions may vary.

Go to Tools > Internet Options… > Content tab > Certificates… > Trusted Root Certification Authorities tab, and look for a matching root certificate (many CAs have several of these). This might have to be done by trial-and-error until a matching certificate is found. Select the certificate and click [Export]. In the Export wizard, choose either DER encoded binary X.509 (.CER) or Base-64 encoded X.509 (.CER) and supply a suitable filename. Next, complete the export. The file that is exported can then be imported into Java’s default keystore as described above.

Once you have imported the signed server certificate into your keystore file, you now need to make the LISTSERV Maestro server aware of this certificate, as a last step of securing your server.

On the server that you want to secure with SSL, edit the file “tomcat.ini”:

To enable SSL, you need to add a SecureServer entry with the value of “true”, like this:

Note: Setting this entry to “false” or any other value, or not specifying the entry at all, will have the effect that SSL will be disabled, in which case the description below does not apply either.

In addition to enabling SSL as described above, you also need to specify the information about the keystore file in which the server certificate is stored. You do so with the following two entries:

with the following replacements:

•	KEYSTORE_PATH: Replace with the absolute path to the keystore file (on Windows including drive letter) in which the signed certificate can be found. You can not use a relative path name but must supply the full path to the file.

Security Issue: As you see, the password to the keystore and the certificate therein is included as plain text in this file. This can be a security breach, if unauthorized persons have access to this file. You should therefore employ the appropriate operating system or file system security measures, so that only authorized persons can access the tomcat.ini file (since it is a file integral to the functioning of the server, you should have done this anyway, because tampering with this file, or other files in the installation folder, may stop LISTSERV Maestro from working properly).

Finally, you may have to edit the Port entry in the same tomcat.ini file. This entry specifies the port to be used for receiving client requests.

If this entry is not specified, the appropriate default port will be used, i.e. in case of HTTPS (which you have enabled by specifying “SecureServer=true”) the default HTTPS-port 443 would be used.

However, if the Port entry is specified, it overrides this default behavior.

Therefore, once you have enabled SSL, check if the port entry matches the now enabled HTTPS protocol: If a Port entry is present, does it specify the correct port you want to use even for HTTPS? If not, either remove the entry (to use the default port 443) or change its value to your desired port.

If you do change the Port entry, please see also Section 14.2.1 Configuring the HTTP Port about other issue that may apply when changing the HTTP port (or in this case the HTTPS port).

LISTSERV Maestro is now prepared for SSL access. Start (or restart) LISTSERV Maestro to make the changes effective.

You can access LISTSERV Maestro normally, only now you need to use “https:” URLs instead of the standard “http:”, because once you have enabled and configured SSL access as described above, the communication with all components on this server may now only happen via HTTPS anymore. Normal access to this server via HTTP is no longer possible.

Note: It is normally not a good idea to secure access to Maestro Tracker; therefore, if you want to secure your Administration Hub and/or Maestro User Interface components with SSL, then you must install them on a separate server from the Maestro Tracker component (however, those two may be on the same server, as long as you plan to secure both of them).