In order to continue our commitment to security, and to respond to evolving technology and regulatory standards for Transport Layer Security (TLS), New Relic has updated its TLS requirements for all endpoints to a minimum version of TLS 1.2 or above effective February 2, 2023 at 16:00 UTC .
- Customers who are already using TLS 1.2 or later have not been impacted by this change.
What’s changed?
We now require TLS 1.2 or above for all inbound connections effective February 2, 2023 at 16:00 UTC. This means customers using TLS versions 1.0 and 1.1 must update to TLS 1.2 or later to be able to connect to New Relic. This change affects all regions.
How am I affected?
If you are one of the customers still using TLS 1.0 or 1.1 you are no longer able to send data to New Relic after the change took effect. This affected your ability to continue using New Relic to monitor your applications.
In order to connect to New Relic you must upgrade to an operating system and/or TLS stack that supports TLS 1.2 or above.
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 have been affected:
Customers accessing http://api.newrelic.com with clients not configured to follow redirects may also have been 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.
Also important to note that any references to download.newrelic.com (aka yum.newrelic.com / apt.newrelic.com) sites should also be updated to use a HTTPS:// url. In an effort to help mediate this, a transition mechanism has been implemented to redirect to a secure version of the site from http:// to https://.
Why have we done this?
Transport Layer Security (TLS) 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.
Moving to TLS 1.2 or above isn’t simply the next step for Transport Layer Security; it’s an actual solution to serious security threats. 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.
How do I know if I’m affected
Once TLS 1.0/1.1 are disabled, New Relic’s ingest tier can no longer accept connection requests via the disabled protocol versions, and thus cannot generate telemetry about those failing connections. If an application has stopped reporting, check the application agent logs for connection errors to determine whether they are related to TLS.
An example error for a Java application is:
2023-01-18T21:43:33,974+0000 [1 36]
com.newrelic.agent.rpm.RPMConnectionServiceImpl INFO: Failed to connect to collector.newrelic.com:443 for hello-world-java:
javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
An example error for .NET is:
2023-01-18T21:43:33,896 NewRelic ERROR: [pid: xxxx, tid: xx] Unable to
connect to the New Relic service at collector.newrelic.com:443 :
System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
…
The following information refers to telemetry available leading up to the TLS EOL.
Although the NrIntegrationError events are no longer created after the EOL, you can still query them for any period of time up until 2023-02-02 18:00:00 UTC.
This can be done to determine applications environments that needed to be updated for TLSv1.2 at the time the older protocols were disabled.
Note that these events are subject to the default data retention period for custom events for your account, so be sure to run the query before March 1st, 2023 for accounts with 30 days of data retention.
APM Agents
The query for APM applications TLS versions that are part of the EOL. Run this in the parent account:
FROM NrIntegrationError SELECT count(*) WHERE category = 'Deprecated TLS Version'
**SINCE '2023-01-30 00:00:00 UTC' UNTIL '2023-02-02 18:00:00 UTC'** LIMIT MAX FACET appName, appId, tlsVersion
You can check out this quick tutorial video to learn how to view the TLS version used by the New Relic agent. https://youtu.be/SQijAjROeXg
Event API
The query for Event API ingest TLS versions that are part of the EOL. Run this in each account:
FROM NrIntegrationError SELECT * WHERE newRelicFeature = 'Event API'
AND message LIKE 'Event sent via deprecated TLS%' LIMIT MAX
Note that this query can be modified to facet by unique API key prefixes - for example:
FROM NrIntegrationError SELECT count(*) WHERE newRelicFeature = 'Event API'
AND message LIKE 'Event sent via deprecated TLS%' LIMIT MAX FACET apiKeyPrefix
How do I upgrade to TLS 1.2 or above
There is no single button or process to ensure TLS 1.2 compatibility. Depending on the platform and software solutions currently in use, the process may be extremely simple or very complex. If you have not done it yet, we advise you to quickly work closely with your IT and security teams on creating a migration plan, as soon as possible.
Alternative temporary workaround - Customer Proxy
With the Feb 2, 2023 deadline passed many organizations may find themselves in a bind to complete their transition to TLS 1.2 connections in a timely fashion. Some have discussed the possibility of creating a proxy to “convert” old connections to TLS1.2 connections.
The proxy should be a measure of last resort as to not put the organization’s connectivity security at risk and before pursuing a proxy solution organizations need to consider and exhaust all other options first. It’s important to understand that intercepting TLS traffic is not a service method that is recommended, endorsed, or warranted by New Relic and is to be done at customer’s own discretion and risk.
New Relic sales, customer adoption, customer success teams have access to recommended steps for customers to consider when adopting a proxy translation approach. Please seek your account teams for further information.
For more information please check out the EXPERIMENTAL GitHub Repository: https://github.com/newrelic-experimental/tls-proxy/blob/main/README.md
Need support?
For more information about this topic check out our documentation, reach out to your account team, or contact New Relic Support.