To align with security best practices, we will be disabling access to Evidence.com over Transport Layer Security (TLS) 1.0 and 1.1 in December 2017. This change will not be noticeable to most users since they are already using clients that support TLS 1.2. If you are accessing our APIs, you must verify that your API client supports TLS 1.2 and has it enabled.
What is TLS?
TLS, or Transport Layer Security, is a protocol that secures data transmitted between two applications. It is the standard security protocol used by all major browsers and other applications that require secure data transmission.
What is changing?
Starting in December 2017, Evidence.com will refuse all connections over TLS 1.0 and 1.1. Only connections over TLS 1.2 will be accepted.
How will this impact me?
For most users this will have no impact, other than a guarantee of stronger security. For customers using our APIs, please see below to determine if your API client will be impacted by this change.
Why is this changing?
TLS 1.0 and 1.1 are outdated versions of the TLS protocol. By restricting access to TLS 1.2, we are aligning with security best practices to protect against any vulnerabilities that may arise in these outdated protocols.
What browsers will be affected by this change?
No browser that is currently supported by Evidence.com is affected by the change. If you attempt to access Evidence.com using an older browser, you may receive a security error rather than our current outdated browser notice.
The following is a list of minimum browser versions for TLS 1.2 support:
- Internet Explorer 11+ (Reminder: Evidence.com is ending support for Internet Explorer 10 in July 2017)
- Edge, all versions
- Firefox 27+
- Chrome 38+
- Android 5.0+ (Lollipop) and some 4.4 (KitKat) clients
- Desktop Safari 7+ (OS X 10.9+)
- Mobile Safari 5+ (iOS 5+)
Will Axon's mobile operating system support be affected by this change?
- iOS:
- No iOS applications are affected by this change.
- Android:
- Axon View and Axon Capture have a minimum version of Android 4.4. They will be upgraded to force TLS 1.2, but will continue to support Android 4.4.
- Axon Device Manager currently supports Android 4.1 or higher. The minimum version will be increased to Android 4.4 to align with View and Capture.
Does this affect API access to Evidence.com?
Yes, depending on your platform or library. If your API client is running on an outdated protocol, you will need to upgrade to a client that supports TLS 1.2. The following is a list of common API clients and their support status:
| Platform or Library | Compatible | Compatibility Notes |
|---|---|---|
| Java (Oracle) | ||
| Java 8 (1.8) and higher | Yes | |
| Java 7 (1.7) | With Modifications | Enable TLS 1.2 using the https.protocols Java system property for HttpsURLConnection. To enable TLS 1.2 on non-HttpsURLConnection connections, set the enabled protocols on the created SSLSocket and SSLEngine instances within the application source code. Switching to IBM Java may be an effective workaround if upgrading isn't feasible. |
| Java 6 (1.6) update 111 and higher | Yes | Requires paid support. |
| Java 6 (1.6) and below (publicly available version) | No | Switching to IBM Java may be a possible workaround. |
| Java (IBM) | ||
| Java 8 (1.8) and higher | Yes | If your application or its libraries use SSLContext.getinstance("TLS"), you may need to use com.ibm.jsse2.overrideDefaultTLS=true. |
| Java 7 and higher, Java 6.0.1 service refresh 1 (J9 VM2.6) and higher, Java 6 service refresh 10 and higher | With Modifications | TLS 1.2 can be enabled by using the https.protocols Java system property for HttpsUrlConnection and the com.ibm.jsse2.overrideDefaultProtocol Java system property for SSLSocket and SSLEngine connections (IBM documentation). You may also need to set com.ibm.jsse2.overrideDefaultTLS=true. |
| .NET | ||
| .NET 4.6 and higher | Yes | |
| .NET 4.5 to 4.5.2 | With Modifications | Option 1: .NET applications may directly enable TLS 1.1 and TLS 1.2 in their software code by setting System.Net.ServicePointManager.SecurityProtocol to enable SecurityProtocolType.Tls12 and SecurityProtocolType.Tls11. The following C# code is an example: System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;Option 2: It may be possible to enable TLS 1.2 by default by setting the SchUseStrongCrypto DWORD value in the following two registry keys to 1, creating them if they don't exist: " HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" and "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319". Although the version number in those registry keys is 4.0.30319, the .NET 4.5, 4.5.1, and 4.5.2 frameworks also use these values. Those registry keys will enable TLS 1.2 by default in all installed .NET 4.0, 4.5, 4.5.1, and 4.5.2 applications on that system. It is thus advisable to test this change before deploying it to your production servers. This is also available as a registry import file. These registry values will not affect .NET applications that set the System.Net.ServicePointManager.SecurityProtocol value. |
| .NET 4.0 | With Modifications | To enable TLS 1.2, it is possible to install .NET Framework 4.5, or a newer version, and set the SchUseStrongCrypto DWORD value in the following two registry keys to 1, creating them if they don't exist: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" and "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319". These registry keys may enable TLS 1.2 by default in all installed .NET 4.0, 4.5, 4.5.1, and 4.5.2 applications on that system, so we recommend testing this change before deploying it to your production servers. This is also available as a registry import file.These registry values will not affect .NET applications that set the System.Net.ServicePointManager.SecurityProtocol value. |
| .NET 3.5 and below | No | |
| Python | ||
| Python 2.7.9 and higher | Yes | Compatible when running on an operating system that supports TLS 1.2. |
| Python 2.7.8 and below | No | |
| Ruby | ||
| Ruby 2.0.0 | Yes | Compatible when linked to OpenSSL 1.0.1 or better. Use :TLSv1_2 (preferred) symbols with an SSLContext's ssl_version to help ensure that TLS 1.0 or earlier is disabled. |
| Ruby 1.9.3 and below | With Modifications | It is possible to patch Ruby to add the :TLSv1_2 symbol and compile with OpenSSL 1.0.1 or higher. |
| Microsoft WinINet | ||
| Windows Server 2012 R2 and higher Windows 8.1 and higher |
Yes | |
| Windows Server 2008 R2 to 2012 Windows 7 and 8 |
With Modifications | Compatible by default if Internet Explorer 11 is installed. Otherwise, you will need to enable TLS 1.2 in Internet Explorer to ensure compatibility. |
| Windows Server 2008 and below Windows Vista and below |
No | |
| Microsoft Secure Channel (Schannel) | ||
| Windows Server 2012 R2 and higher Windows 8.1 and higher |
Yes | |
| Windows Server 2012 Windows 8 |
With Modifications | TLS 1.2 is disabled by default, but can be enabled by an application. Or, it can be enabled by default in the registry, either manually or with a registry import file. |
| Windows Server 2008 R2 Windows 7 |
With Modifications | Compatible in client mode. Otherwise, it can be enabled by default in the registry, either manually or with a registry import file. |
| Windows Server 2008 and below Windows Vista and below |
No | |
| Microsoft WinHTTP and Webio | ||
| Windows Server 2012 R2 and higher Windows 8.1 and higher |
Yes | |
| Windows Server 2008 R2 SP1 and 2012 Windows 7 SP1 |
With Modifications | Webio is compatible when KB3140245 is applied. WinHTTP can be configured for TLS 1.2 via registry settings. |
| Windows Server 2008 and below Windows Vista and below |
No | |
| OpenSSL | ||
| OpenSSL 1.0.1 and higher | Yes | |
| OpenSSL 1.0.0 and below | No | |
| Mozilla NSS | ||
| 3.15.1 and higher | Yes | |
| 3.15 and below | No |