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.
The following subchapters describe how you can configure your LISTSERV Maestro server(s) to use SSL. 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. hey 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.
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.
|
•
|
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.
|
Normally, you should only secure the Maestro User Interface and/or the Administration Hub component with SSL, not the Maestro Tracker component. Because securing the Maestro Tracker component has several drawbacks, HTTPS is slower and takes more system resources than HTTP, so if you have a high tracking event volume, then using HTTPS puts a higher workload on the Tracker server. Also not all clients may be able to access HTTPS-URLs correctly, which could result in tracking events not being counted and recipients not being redirected to the intended target pages (in case of click tracking). Before you decide to also secure Maestro Tracker, you should take these possible drawbacks into account and evaluate, if they are worth the additional security gain in your situation.
Additional preparations need to be made if you have several components installed on the same server, but only want to secure some of them. For example, if you have all three components on the same server, but only want to secure LUI and HUB, but not TRK (which is recommended, as explained above). In such a case, you need to have at least two separate IP-addresses for the server, each with a separate host name. You would then use one host name and IP-address pair for the components that are to be secured (LUI/HUB) and the other pair for the components that are not to be secured (TRK).
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.
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 website:
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.
[maestro_install_folder]/java/bin/keytool –storepasswd
–keystore [maestro_install_folder]/java/lib/security/cacerts
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.
[maestro_install_folder]/java/bin/keytool –genkey
–alias NAME –validity DAYS –keystore KEYFILE -keyalg RSA
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.
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.
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.
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.
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:
[maestro_install_folder]/java/bin/keytool –import
–alias NAME –file INFILE –keystore KEYFILE -trustcacerts
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:
[maestro_install_folder]/java/bin/keytool –import
–alias NAME –file INFILE ‑keystore
[maestro_install_folder]/java/lib/security/cacerts
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.
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.
[maestro_install_folder]/conf/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 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:
KeystoreFile=KEYSTORE_PATH
KeystorePassword=PASSWORD
|
•
|
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.
|
|
•
|
PASSWORD: Replace with the password that you used for the keystore (as explained earlier, you must have used the same password for the certificate itself too).
|
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).
You may also have to edit the SecurePort entry in the same
tomcat.ini file. This entry specifies the port to be used for receiving client requests when using HTTPS protocol.
However, if the SecurePort 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
SecurePort entry is present, does it specify the correct port you want to use? 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 SecurePort entry, please see also Section 14.2.2
Configuring the HTTPS Port about other issues that apply when changing the HTTPS port (for example, adjusting certain HUB settings).
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: The above procedure describes what you need to do if you want to secure the whole server with SSL, i.e. all components that are installed on that server. If instead you only want to secure some components, then see Section 18.3.8
Mixing SSL and Non-SSL Access on One Server (Mixed Mode) for details of how to configure such a mixed mode.
Under normal circumstances, SSL does not work if the server has several different host names, which are mapped to the same IP-address. This is a technical limitation of SSL, not a specific limitation of LISTSERV Maestro.
The reason for this is, that SSL is supposed to encrypt all data that is being transferred between the server and the browser. Therefore, the SSL handshake (through which server and browser negotiate the encryption details) has to happen as the very first thing once a SSL connection has been established, before any other data is transferred (otherwise that data would not be encrypted). This means that not even the initial request itself (which contains the hostname that the request is directed to) has been transferred at this point.
Therefore, at the moment the SSL handshake is happening, the server does not yet know which host name the browser is trying to access. The server only knows the IP-address that the browser is connecting to. Because of this, the server must determine the certificate that is to be used for the SSL encryption based only on the IP-address. It can not select the certificate based on the host name that is contained in the request.
But if the IP-address is mapped to several host names, then the server will likely select the wrong certificate. Because if there are several certificates for the same IP-address (as is the case if there are several certificates for different host names, which however all are mapped to the same IP-address), then the server will simply pick one of them, with no guarantee that this will be the certificate that matches the host name that is contained in the request.
If you have such a server with multiple host names, you need to assign several IP-addresses to the server so that each host name can have its own dedicated IP-address, i.e. each IP-address that is assigned to the server must be used by only one of the server’s host names.
Then, you can create and install certificates for all these host names, and the individual IP-addresses will make sure, that for each SSL request that is directed to one of the host names, the correct certificate that matches the IP-address of that host name will be selected.
If you have multiple host names for the server, but want to SSL-secure the server for all these host names (and for all Maestro components), then you do this in the same fashion as described in the previous sub-sections, only that you need to have a separate IP-address for each host name, and you need to obtain a separate server certificate for each host name too, where you store all these server certificates in the same keystore file.
|
•
|
If you want to SSL-secure some host names, but not others, then for each host name that you want to secure, you need a separate IP-address. This means that this IP-address must only be used by this one host name. A secured host name is not allowed to share an IP-address with another secured host name, and it is not allowed to share an IP-address with one of the unsecured host names (but the unsecured host names may share one IP-address among them).
|
Depending on your scenario and according to the above pre-conditions you will have a list of host names that you want to secure, each of which must have a unique IP-address that is not used by any other host name. In the description below, we will call these the “secured host names” and “secured IP-adresses”.
With these secured host names and secured IP-addresses, you can then configure the SSL/non-SSL mixed mode more or less in the same fashion as when securing the whole server (as described in the previous sub-sections), except for the following differences:
|
•
|
In the tomcat.ini, instead of supplying “ SecureServer=true” (as you would if you wanted to secure the whole server), you now supply a comma-separated list of all the secured IP-addresses, like this:
|
Note: You must use this method of specifying the secured IP-addresses even if you have only a single secured IP-address.
|
•
|
Also, in the tomcat.ini, check the values of the settings Port (which defines the HTTP port used by all unsecured host names) and SecurePort (which defines the HTTPS port used by all secured host names). If any of these settings is not present, then the default port for the corresponding protocol will be used, so if you want to use a different port, make sure to specify the corresponding setting.
|
|
•
|
For the KeystoreFile setting in the tomcat.ini, supply the following value:
|
Note, that you specify only a single “KeystoreFile” entry in the tomcat.ini, even though there are several keystore files! When specifying this entry, you supply only the path and the common filename. LISTSERV Maestro will then automatically generate the actual keystore filenames from this setting by inserting each secured IP-address (with the separating “-“ character) between the path and the common file name part. So for each secured IP-address, the actual filename will become something like:
|
•
|
Finally, check the URL Settings in the HUB (on default level and/or group or user level) to check that the protocol, hostname, and port that is specified there matches your SSL/non-SSL configuration. Access URLs to secured host names must use “https://” while access URLs to unsecured host names must use “http://”.
|
The following table lists the SSL ciphers that are supported by LISTSERV Maestro. It also shows which ciphers are enabled as allowed ciphers by default, if the SSLCiphers setting in the tomcat.ini is not defined. If you want to define a different set of allowed SSL ciphers, add the SSLCiphers setting to the tomcat.ini and specify the cipher-names in a comma separated list as the value of the setting.
