For apps compiled using the iOS 9 SDK, Apple introduced new security requirements, forcing applications to support App Transport Security (ATS). Two of the requirements for ATS are the use of TLS version 1.2 and SHA-2. The purpose behind this is to improve the privacy and data integrity of connections between an app and web services by enforcing additional security requirements for HTTP-based network requests.
At Apple's 2016 Worldwide Developers' Conference (WWDC), it was revealed that starting January 1, 2017, ATS will be a requirement for all mobile applications submitted to the App Store.
Because of this, the OnBase Mobile Broker server must support a Handshake Protocol of TLSv1.2 and the certificate hashing algorithm must be SHA-2 with a digest length of at least 256 (SHA-256 or greater).
The current mobile applications that are built using the iOS 9 SDK and are therefore affected by this include:
- OnBase Mobile 16 for iPad
- OnBase Mobile Healthcare 16
- OnBase Mobile for iPad
- OnBase Mobile for iPhone
By January 1, 2017, all OnBase mobile iOS applications (iPhone and iPad) will be affected by this.
Action Required
By the end of 2016, ensure that the server hosting your OnBase Mobile Broker meets all of the ATS requirements.
Verifying your Mobile Broker Server
Option 1:
You can use the following website to test publicly-accessible Mobile Broker servers:
https://www.ssllabs.com/ssltest/index.html
After entering the hostname for the Mobile Broker server, the section titled "Handshake Simulation" lists "Apple ATS 9 / iOS 9" and will indicate if TLS 1.2 was successfully negotiated and which connection cipher suite was used. If the cipher suite used is listed below under the Technical ATS Requirements and TLS 1.2 was successfully negotiated, then the server is properly configured for ATS.
Option 2:
On a Mac running OS X El Capitan, run the following command in Terminal:
/usr/bin/nscurl --ats-diagnostics https://your.mobile.broker.server.hostname
After running the command, look for the section near the top labeled, "ATS Default Connection." A result of, "PASS," indicates the server is properly configured for ATS.
Option 3:
Use Internet Explorer to determine if TLSv1.2 has been enabled on the Mobile Broker. You can do this by restricting all communication from Internet Explorer to TLS1.2 under the Advanced Internet Options. By doing this, only web sites which respond with the appropriate protocol will be supported.
To test this out, go to Internet Explorer's Internet Options --> Advanced tab, uncheck "Use TLS 1.0", uncheck "Use TLS 1.1", and check "Use TLS 1.2." **
Then, browse out to https://your.mobile.broker.server.hostname/MobileBroker/ServiceToBroker.svc. If your Mobile Broker is running on a web server that does not support TLSv1.2, then you will get an error page similar to the following, displayed in the browser:
** Revert these settings back once you've tested this.
Option 4:
For Mobile Brokers which are not publicly-accessible, use Wireshark to monitor the communication to the Mobile Broker. You can use a Wireshark filter to display only TLSv1.2 packets with the following:
ssl.record.version == 0x0303
You will see packets that use the TLSv1.2 protocol if the server has been configured for TLS version 1.2. If you only see a Client Hello packet when monitoring requests coming into the Mobile Broker, then TLSv1.2 was not negotiated between the mobile device and the Mobile Broker.
More information about configuring the server for TLSv1.2 can be found here:
https://technet.microsoft.com/en-us/library/dn786418(v=ws.11).aspx
Technical ATS Requirements
- Server certificate must meet one of the following:
- Issued by a certificate authority (CA) whose root certificate is incorporated into the operating system
- Issued by a trusted root CA and installed by the user or a system administrator
- The negotiated Transport Layer Security (TLS) version must be TLS 1.2
- The negotiated TLS connection cipher suite must support forward secrecy (FS) and be one of the following:
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- 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) key with a size of at least 256 bits
- In addition, the leaf server certificate hashing algorithm must be SHA-2 with a digest length of at least 256 (SHA-256 or greater)
