Securing connections for IBM Connections mobile applications
Minimum HTTPS / TLS connection and certificate security requirements for IBM Connections for iOS and IBM Connections for Android.
In the coming months, IBM will be enhancing the IBM Connections for iOS and IBM Connections for Android mobile apps to require that a secure connection is used between the mobile app and the endpoint used for connecting to the IBM Connections server. This article provides the security requirements and step by step instructions for ensuring that your on-premises IBM Connections environment has adequate connection security in place in order to support these updated apps.
If your mobile users connect to IBM Connections Social Cloud, these steps do not apply, since this environment is already prepared for these updates. If you have deployed an IBM Connections server on your own premises 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 only apply to the server that the Connections mobile apps connect to directly. This may be an intermediate reverse proxy, such as an F5 or IBM Mobile Connect. When you enter the host name into your Connections mobile application to connect to your Connections service, this host name represents the server that the mobile app connects to directly, and this is the connection that must be secured.
It is important to note that failure to meet all the requirements listed below may result in your IBM Connections apps being unable to connect to your IBM Connections servers.
1. Mobile apps must connect using HTTPS and not the unsecured HTTP protocol.
2. The server certificate cannot 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 that the client is connecting to. For example, if the mobile app is connecting to connections.example.com, then the certificate must list connections.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
8. The leaf certificate hashing algorithm must be Secure Hash Algorithm 2 (SHA-2) with a digest length of at least 256 (SHA-256 or greater).
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 Connections server endpoint URL and then use the browser options to examine the certificate. The steps below use a fictitious Connections server URL called
https://www.example.org, 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 host name
https://www.example.org below, replace it with the host name used to connect to your Connections service.
1. Ensure that you cannot connect to your Connections server using HTTP. In your browser try to connect to
http://www.example.org/homepage. If this shows a login page, login and confirm the URL loaded after login uses the https protocol or loading the page fails to resolve to the Connections homepage or login prompt.
2. Ensure that the browser trusts the Connections 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 unsecure certificate. Make sure 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. Confirm that the server’s host name matches the Common Name (CN) listed in the Subject Alternate Names.
6. Verify 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 is signed with RSA encryption and the Certificate Signature value shows that it is 2048 bits.
You may need to deploy a more secure certificate to meet these security requirements. 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 using an MDM or other means. 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.
Finally, it is recommended that you ensure network traffic is sent over encrypted connections. The Knowledge Center topic Forcing traffic to be sent as encrypted connections will provide additional guidance.
Frequently Asked Questions (FAQs)
Q1: Why is Connections making changes to the minimum security requirements?
Cyber security is a critical focus for IBM and our Connections product. 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 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 Connections apps connect to a 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 website 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 Connections 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). If you are creating a self-signed certificate, review Configuring IBM HTTP Server for encrypted connections in the Connections Knowledge Center.
Q3. We are using a Mobile Device Management solution such as MobileIron for our Connections clients. Do I need to make sure that my Connections server meets the minimum security requirements even in an environment that is using MobileIron or VPN Tunneling?
Yes. Even though the tunnel would be encrypted, the application will understand that it is making an end-to-end connection only with the Connections server. The MDM’s tunnel encrypts the data for only a portion of this connection; it does not cover it end-to-end.
Q4. Why is my Connections for Android app running on an Android 7 device no longer able to connect to my Connections 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 Connections 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.
Note that these security requirements will likely change in the future as new security protocols and techniques are released. IBM will update this documentation as requirements change. IBM will also include the latest requirements in our Connections mobile product documentation.
If your company is using the IBM Verse, IBM Traveler ToDo or IBM Traveler Companion app, see a similar article on Securing connections for IBM Traveler athttps://www-01.ibm.com/support/docview.wss?uid=swg21989980.
If you have questions or concerns about these requirements, please contact us email@example.com.