Securing connections for IBM Traveler mobile applications
Minimum HTTPS / TLS connection and certificate security requirements for IBM Verse for iOS, IBM Verse for Android, IBM Traveler Companion and IBM Traveler To Do mobile apps. **FAQ section added below**
In the coming months, IBM will be enhancing the IBM Verse for iOS, IBM Verse for Android, IBM Notes Traveler Companion and IBM Notes Traveler To Do mobile apps to require that a secure connection be used between the mobile app and the endpoint used for connecting to the IBM Traveler server.
This article describes the security requirements with step-by-step instructions for ensuring that your on-premises IBM Traveler environment has adequate connection security in place to support these updated apps.
If your mobile users connect directly to IBM SmartCloud Notes for Traveler and the Verse Mobile service, these steps do not apply, since this environment is already prepared for these updates. If you have deployed an IBM Traveler server on your own premises, or your company uses a SmartCloud Notes company configured for federated authentication using an identity provider, and you are using any of the above applications in your environment, then please continue reading.
IMPORTANT: The deadline for implementing these changes has been extended to give our customers more time to prepare. Many of the requirements in this article must be implemented because of Apple's announced intention to require apps submitted to the App Store to only use Apple Transport Security (ATS). The deadline for Apple requiring ATS has been extended beyond January 1, 2017. IBM will continue to collaborate with Apple, and look to communicate a new deadline at a later date. All of the minimum requirements listed in the article remain best security practices and are recommended regardless of any mandatory enforcement policies.
These requirements apply only to the server to which the IBM Verse, Traveler Companion or Traveler ToDo mobile apps are directly connecting. This may be the IBM Traveler server running on a Domino instance, or some other intermediate server or reverse proxy, such as an F5 or IBM Mobile Connect. When the user enters the host name into their IBM mobile application to connect to the Traveler service, this host name represents the server with which the mobile app is directly connecting, and thus is the connection that must be secured. In the diagram below, 2 connection scenarios are shown, one with mobile apps connecting directly to a Traveler server and another with the mobile apps connecting to a proxy server. The requirement here is to secure the connection between the mobile app and the first server it connects into.
It is important to note that failure to meet all of the requirements listed below may result in your Verse for iOS, Verse for Android, IBM Notes Traveler Companion and IBM Notes Traveler To Do apps being unable to connect to your Traveler servers.
1. Mobile apps must connect only using HTTPS and not the unsecured HTTP protocol.
2. The server certificate must not be expired or invalid.
3. The server certificate common name (CN )or a name from the server certificate's Subject Alternate Name (SAN) list must match the host name of the server with which the client is connecting. For example, if the mobile app is connecting to traveler.example.com, then the certificate must list traveler.example.com in the CN or SAN fields. A wild card certificate is allowed but the domain from the wild card must match the server's domain.
4. The negotiated Transport Layer Security version must be TLS 1.2. Since devices running Android prior to version 4.1 do not support TLS 1.2, they can no longer be supported.
5. The server certificate must be trusted and either issued by a certificate authority (CA) whose root certificate is incorporated into the device operating system or is a trusted root CA that has been installed by the user or a system administrator on the device.
6. The negotiated TLS connections cipher suite must support forward secrecy and be one of the following:
7. The leaf server certificate must be signed with one of the following types of keys:
- Rivest-Shamir-Adleman (RSA) key with a length of at least 2048 bits
- Elliptic-Curve Cryptography (ECC/ECDSA) key with a size of at least 256 bits
NOTE: If your users are using only Apple's built-in mail application to connect to a Traveler server and are not using any of the other IBM apps listed in this article, then the action date of January 1, 2017 does not apply to you. However, these requirements are all recommended practices even when only using the Apple built in mail application.
Validating your connection security using a browser
There are several methods for validating your server certificate. One is to use a browser to connect to your Traveler server endpoint URL and then use the browser options to examine the certificate. The steps below use a fictitious Traveler server URL called
https://www.example.org/traveler and a Firefox browser version of 45.3.0. These steps will vary based on which tool you use to examine the certificate, but they should be similar. Wherever you see the hostname
www.example.org below, replace it with the hostname used to connect to your Traveler service.
1. Ensure that you cannot connect to your Traveler server using HTTP. In your browser try to connect to
http://www.example.org/traveler . This should not resolve to a Traveler page or login prompt.
2. Ensure that the browser trusts the Traveler site. The green lock icon indicates success here, though hover over this icon to check that you have not already created security exceptions for this site that would be masking an unsecured certificate. Ensure no warnings display about your connection not being secure as the browser was making the connection.
3. Click the green lock icon to examine the certificate and select the right arrow to see more details. Click on the More Information button. This brings up the website identity page. This page also shows the cipher that is being used. Ensure that the protocol used here is TLS 1.2 and that the cipher is one of the ones required.
4. Verify that the certificate is not expired. Ensure that the current date/time is not outside of the range specified in the certificate's Period of Validity Before and After dates.
5. Ensure that the server’s host name matches the Common Name (CN) listed in the Subject Alternate Names.
6. Ensure that the certificate hashing algorithm is set to Secure Hash Algorithm 2 (SHA-2) with a digest length of at least 256 (SHA-256 or greater). The following example uses SHA-256 with RSA.
7. Ensure that the server certificate is signed with an RSA key of at least 2048 bits, or an ECC key of at least 256 bits. In the image in step 6, the certificate was signed with RSA encryption and the Certificate Signature value shows that it is 2048 bits.
How do I fix my environment?
If the server connection to your IBM Traveler environments fails one of more of the minimum security requirements, review this section for how to update and repair your system.
If your mobile apps are NOT connecting directly to a Traveler server and are connecting to an intermediate edge proxy instead, then contact the support team for your edge proxy to ensure that it can support the necessary protocols, ciphers and certificates. Your edge proxy could be an instance of IBM Mobile Connect, F5, a MobileIron Sentry, a Citrix Netscalar or many other types of edge proxies that provide connection services for IBM Traveler and other internal web sites.
If your mobile apps connect directly to a Traveler server, then follow these steps:
1. Ensure that you are running Domino 9.0.1 Fix Pack 5 or later. See Download Options for Notes and Domino 9.0.1 Fix Packs to find the latest available option. This version automatically supports and enables TLS 1.2 with the required TLS cipher protocols. You will not need to adjust the TLS ciphers to support the minimum security requirements, but if you require more information on configuring the required ciphers, see Domino TLS Cipher Security.
2. If your TLS certificate does not meet the minimum security requirements, then you will need to deploy an updated certificate. IBM recommends the use of an external certificate authority that is already supported by Apple iOS and Android mobile devices to avoid the need to install your private certificate on devices. Confirm with your certificate authority that the certificate that you are deploying meets the requirements listed above and is supported on the mobile devices that you are using. Follow the instructions from the article How to set up SSL using a third-party Certificate Authority (CA) for installing a third party certificate on your Domino/Traveler server. If you are considering using a self-signed certificate, review FAQ question #2 below on considerations for self-signed certificates.
3. If your Traveler server has only enabled the HTTP protocol (port 80) and has not enabled any HTTPS protocol, then you will need to take the keyring file that you generated in step #2 and use it to enable the HTTPS protocol. See the article How to set up SSL using a third-party Certificate Authority (CA) and follow the section called Steps for Configuring SSL on a Domino server to complete this task.
4. It is recommended that you ensure that HTTP Strict Transport Security is enabled at your server. If your mobile apps are connecting directly to a Traveler server, the article Domino HTTP Strict Transport Security (HSTS) will provide additional guidance.
5. Once you have upgraded your environment, repeat the validation checks to assure that the server now supports the minimum security requirements listed in this article.
Frequently Asked Questions (FAQs)
Q1. Why is Traveler making changes to the minimum security requirements?
Cyber security is a critical focus for IBM and our Traveler and Verse mobile products. Our development teams are continuously performing vulnerability and ethical hacking tests on our products to find potential security flaws. In order to help ensure that our products are as secure as possible when deployed, it is becoming more and more crucial that the environments they operate in be setup properly. For example, if you are using an expired or invalid SSL certificate or an older transport security protocol that is known to be vulnerable to attacks, then we can no longer ensure the security of your system. These issues can be exploited by attackers to gain access to your systems or to siphon out data that is exchanged with the mobile devices.
In addition, Apple has indicated that all apps distributed from the Apple iTunes app store must enable App Transport Security (ATS) starting in 2017. ATS requires as a minimum all of the requirements that we have listed in this article. In preparation for this change, IBM on-premises customers need to ensure that their environments also meet these minimum security requirements. IBM Connections Cloud (SmartCloud) already supports all of the requirements.
Q2. My Traveler clients connect directly to my Traveler server which is using a self-signed certificate. Can I continue to use self-signed certificates?
While it is technically possible to continue to use a self-signed certificate, this requires special care to ensure that you are still meeting the minimum security requirements. The server certificate must be trusted by the device, which means that either it was issued by a certificate authority (CA) whose root certificate is pre-loaded into the device operating system or the root certificate has been installed by the user or a system administrator on the device. As long as a root or intermediate root of the self-signed certificate is also distributed to the mobile devices that are connecting, then the self-signed certificate will be considered trusted by the app and the mobile operating system.
If you are using a Mobile Device Management solution in your environment, this environment will allow you to distribute certificates to mobile devices with relative ease. Otherwise, end users will be required to install these certificates in another manner, such as logging into an internal Web site and then manually downloading and installing the certificate. Because the latter method can be complicated for mobile users, we recommend using a certificate from an external Certificate Authority that is pre-loaded on the most popular mobile devices. However, if you are using an MDM provisioned secure tunnel, it is possible that your Traveler infrastructure is never external facing and some certificate authorities will no longer sell you a certificate unless the host name is externally accessible. In this case, it is appropriate to use a self-signed certificate and deploy that certificate to your mobile devices using an MDM.
The leaf server certificate hashing algorithm must be Secure Hash Algorithm 2 (SHA-2) with a digest length, sometimes called a “fingerprint,” of at least 256 (that is, SHA-256 or greater). You cannot use a self-signed certificate that was created using the old Lotus Notes Server Certificate Admin database since those certificates are not strong enough to meet the current minimum security requirements. If you are creating a self-signed certificate, it is recommended that you follow the steps in the article Generating a keyring file with a self-signed SHA-2 cert using OpenSSL and kyrtool.
Q3. We are using a Mobile Device Management solution to deploy a per app VPN for our Traveler clients. Do I need to make sure that my Traveler server meets the minimum security requirements even in an environment that is using a full VPN Tunnel?
Yes. Even though the tunnel would be encrypted, the application will make an end-to-end connection with the Traveler server. The VPN tunnel encrypts the data for only a portion of this connection; it does not cover it end-to-end.
Q4. We are using an application level AppTunnel and a MobileIron Sentry to provide mobile app access to our internal Traveler servers. Do I need to make sure that my Traveler server meets the minimum security requirements even in this environment?
No. If you are defining a MobileIron AppConfig setting with definitions for a MobileIron AppTunnel to allow the mobile app to establish a connection to the Traveler server using a MobileIron Sentry, then the SSL connection endpoint is with the MobileIron Sentry and not with the IBM Traveler server. The MobileIron Sentry functions just like an edge proxy in this case. It is possible to even use a secured encrypted connection between the mobile app and the sentry, and then use an HTTP only connection from the Sentry to the IBM Traveler server.
Q5. Why is my Verse for Android application running on an Android 7 device no longer able to connect to my Traveler server?
Android 7 removed the Rivest Cipher 4 (RC4) cipher from the OS due to several known vulnerabilities with this encryption algorithm. If the connection to the Traveler server is still using RC4 at the server, then a connection will not be possible with the device until the cipher is upgraded at the server. To resolve this issue, follow the remediation steps in this article to upgrade to TLS 1.2 and a more modern security cipher.
Q6. Are there any other tools I can use to validate that my connection and certificate are secure?
Yes. The example using a FireFox browser given in this article should be accessible in any environment. However, there are a number of publically available tools or sites that can be used to validate secure connections. A popular site is available from Qualys SSL Labs. Many of these sites only support the standard port 443, so if your Traveler environment is using a non-standard port, you can continue to use the FireFox method.
Q7. Is the IBM mail support for Microsoft Outlook (IMSMO) client impacted by any of these security requirements?
No. While these minimum security requirements are good best practices, the IMSMO client will not be making any security enforcement changes along these lines in the near future.
Q8. Can I get early access to the mobile apps that are enforcing the new security requirements?
Yes. Beta versions of the Apple apps will be released in January 2017 with ATS enabled. You can use these versions to validate that your environments are functioning properly before these apps are available on the Apple App Store. Updates to Verse for Android will follow later in the year.
The Apple iOS apps can be tested using Apple's TestFlight program, but you must be invited to participate by IBM. Please send an email to firstname.lastname@example.org with the following information for each tester that wants to participate:
-Tester's email address that is tied to their Apple ID
-Which apps to test (or all 3), Companion, ToDo or Verse for iOS
The beta program for Verse for Android is available for anyone wishing to enroll, and you can enroll directly from the Google Play website. Go to the IBM Verse page on Google Play, login with your Google Account, and then click the button called Become a Tester. At this point, if there is a beta version of the app available, you can update it automatically from your mobile device.
Note that these security requirements will continue to evolve as new security protocols and techniques are released. IBM will update this documentation as our products implement these changes. IBM will also include the latest requirements in our Verse Mobile and Traveler product documentation.
If your company is using the IBM Connections Mobile app, see a similar article on Securing connections for IBM Connections Mobile at http://www-01.ibm.com/support/docview.wss?uid=swg21993991.
If you have questions or concerns about these requirements, please contact us at email@example.com.
Translate this page: