Section 12
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, as such, 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 12.1 Introduction to Secure Communication of this guide to assist understanding the concepts involved, making the execution of the required steps easier.

12.1 Introduction to Secure Communication

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. Basically, for successful encrypted communication to take place one partner holding an "encryption key" encrypts the data. It 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. Let's say 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 from each other is their 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.

But, 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. With accepting the ID they trust that the agency has created an ID that it 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/she claims to be. If employee A had tried to use his/her library card for identification, then employee B would probably have rejected it as improper identification, because he/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 he 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). So instead he 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. The role of a "picture ID" in real life is fulfilled by so called "certificates" in the online world. 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 intruder. 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 (e.g. 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 simply 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/she would use his/her 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 below:

• The browser vendor receives root certificates from the signing authorities, verifying their validity.

• The browser vendor trusts that the root certificates are genuine.

• 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."

• The browser trusts any server that has a browser trusted 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-word 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 he/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 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 e-mail, 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.