On Monday, January 6th 2020, we will be conducting an 8-hour test of our upcoming Transport Layer Security (TLS) changes. These changes will be made permanent one week later, on Monday, January 13th.
We will be requiring TLS 1.2 or above for inbound connections to our APIs on each of the following domains:
bam.nr-data.net, the Browser agent collector, will begin accepting only HTTPS traffic. Unencrypted HTTP traffic has been unsupported since Browser agent version 998 (released in 2016), but with this change, all prior versions will no longer be able to connect unless using HTTPS.
What’s not changing?
APM Agent connections will be unaffected by these changes, although we do plan to announce a roadmap in the near future to require TLS 1.2 and above for these connections, as well.
Domains that are directly connected to by our customers’ customers devices—such as those used by the Browser agent and Mobile APM agent—will still support TLS 1.0 and 1.1 for the foreseeable future.
Am I affected?
Most customers will not be affected. Those customers accessing New Relic APIs on the above domains from unsupported operating systems may be unable to connect after the changes take effect. Affected operating systems include, but are not limited to:
- Windows Server 2008 (support available via optional Windows Update package)
- Windows 7 (support available via optional Windows Update package)
- Windows Server 2003 and earlier
- Windows Vista and earlier
- OS X 10.8 “Mountain Lion” and earlier
- RHEL 6.4 and earlier
TLS stacks reliant on the following may also be affected:
You can test whether a given system is affected by making HTTPS connections (via cURL, for example) to https://connection-test.newrelic.com. The TLS profile currently set on this host will be the profile used across our API tier in January.
Customers connecting over TLS 1.0 or 1.1 should upgrade to an operating system and/or TLS stack that supports TLS 1.2 or above in order to maintain connectivity with these APIs.
Customers accessing http://api.newrelic.com with clients not configured to follow redirects may also be impacted by this change. You should ensure that your clients specify the
https:// scheme (as opposed to
http://), or that they are configured to follow redirects, such as by using the
-L flag when using cURL.
Additionally, customers who have deployed Browser agents prior to version 998 (released in 2016) on pages served over unencrypted HTTP may no longer have clients accessing these pages report data to New Relic. We believe this circumstance to be unusual.
Why are you making these changes?
TLS (Transport Layer Security) is a protocol used to establish secure, encrypted connections. It is the successor to SSL (Secure Socket Layer), although the acronym ‘SSL’ retains some colloquial usage as a synonym for TLS.
TLS versions 1.2 and 1.3 are the current industry standards, and include protections that aren’t present in earlier versions of the protocol. TLS also has a history of downgrade attacks, where an attacker can force a client to use a less-secure protocol version if it is supported by the server.
By removing support for the less-secure versions of the protocol, we can help ensure that downgrade attacks aren’t possible, and that data sent over these connections cannot be intercepted or modified by an attacker.
Concerns with earlier versions of TLS are shared within the industry, with the Chrome, Edge, Firefox, Internet Explorer, and Safari browsers all requiring TLS 1.2 or greater beginning in early 2020. Furthermore, the PCI DSS and NIST frameworks no longer consider the use of TLS versions prior to 1.2 to be compliant. We believe that it’s important to keep pace with industry standards, and ensure that the data you send to us remains between you and us.