Frequently asked questions about the TLS 1.0 deprecation process
Answer ID 8957   |   Last Review Date 09/19/2018

I've used the TLS 1.0 Log Scanner to check for TLS 1.0 traffic on my site and I'm not sure what the output means or what to do with it


TLS 1.0 Deprecation


The following is a list of frequently asked questions regarding the TLS 1.0 deprecation process.

Where can I find information on the TLS 1.0 deprecation policy?

The deprecation policy is outline in this answer.

Where can I find details on what the TLS logs mean?

The TLS 1.0 Log Scanner User Guide is a good place to start for an explanation of how to use the utility and what data you're likely to see in the CSV output.

What do I do about end user traffic?

If you see end user traffic in your logs, you will need to notify your customers that they need to update their TLS settings or browser version to continue using your site after the deprecation date.  The instructions for this will depend on each customer's particular browser and version, but you can also see this community post for some guidance on how to go about notifying your customers that they need to perform an update.

What do I do about agent console traffic?

If you are on the February 2014 or later version of Oracle Service Cloud, your agents will need to make sure they are on Microsoft .NET 4.5.2*.  If you are on a version older than February 2014, you will need to upgrade your site and ensure your agents are on Microsoft .NET 4.5.2.

*Please note that a fault exists with the Microsoft's ClickOnce application where it does not automatically detect the TLS protocol that is required at runtime. This can result in OSvC failing to start due to the Microsoft ClickOnce application failure when using Microsoft .NET version 4.5.2. For further details regarding this fault see Error while logging in: "Could not Start Application" right after TLS 1.0 was turned off.


Please Note:
Currently supported releases of the Service Cloud Application are fully compatible with, and will communicate via TLS 1.2 protocols. Customers are strongly urged to fully test their environment and their OSvC deployment within their environment prior to TLS 1.0 abandonment.

Oracle Service Cloud Technical Support is not responsible for any issues, including site downs resulting  from TLS 1.0 abandonment. Please ensure that you have tested fully within your environment.

If your agents use BUI, they will need to ensure that their browsers are up to date and configured to use TLS 1.1+, as the security protocol for BUI will be determined by the settings of the browser from which the application is being used.

What if I have questions about customizations?

For 'how to' questions regarding how to get customizations in compliance, your best resources are:

Oracle Service Cloud Technical Support is available only for troubleshooting issues with the Log Scanner utility or fielding non-'How To' questions, and will generally not be able to assist with recommendations for specific code changes.

The Log Scanner utility provided me with masked IP addresses, but I want specific IP addresses, how do I get these?

For security reasons we are not able to transmit full IP addresses in the Log Scanner output.  If you would like to identify specific users by their IP addresses, you may find your full web traffic information by downloading your web logs.

Why do I see the same chat traffic if I run the Log Scanner against a production site and a test site?

Chat traffic is made available to the Log Scanner utility in the form of /Chat/chat/*interface name*.  Since your test site and your production site will usually have the same interface names, only the site name and VHOSTs are different, the Log Scanner is unable to differentiate between chat traffic on one or the other.  In either case, chat traffic security protocols will be controlled by the user's browser settings, and the remediation path will be to have users upgrade their browsers or enable TLS 1.1+ in their browser settings.  You should not have to do any site-specific configuration or customization changes to address this traffic.

I am running tests and I don't see them in the Log Scanner

Due to the scale of the data being delivered, the log scanner only has data for IP ranges that generated over 100 hits in a week.  The recommendation here in testing is that you programmatically generate enough traffic from one source that it would show up in the logs.

The Log Scanner reported hits to API endpoints, what do I do?

Hits to API endpoints often fall into one of the following categories:

  • An integration to your site using cURL.  Most commonly these would show up as hits to the REST API or Custom PHP code, and may specify cURL in the user agent.  Remediation is to check for cURL requests in any custom code you have connecting to your site from an external source.  If you find those requests, be sure that the CURLOPT_SSLVERSION is properly set in the cURL header
  • An integration to your site using .NET.  This would usually take the form of an addin to the agent console, or a custom application run from the agent desktop.  You will need to review the .NET code to ensure that it's built against a version that supports TLS 1.1+ (.NET 4.0+), and make sure that your agents have at least that same version of .NET installed on their workstations.  You may also need to review your .NET code for HTTP bindings to see if they are explicitly using a deprecated security protocol.
  • An integration to your site using Java.  Often these would be identified with a user agent mentioning Axis.  This would usually take the form of a custom application run from the agent desktop.  JDK 6 update 111 and above use TLS 1.1 by default.  You should ensure any users of your addin have at least that version of Java installed and enabled on their workstation.  In addition, you may need to review any custom Java code you're running against your site to ensure that it is not explicitly using a deprecated security protocol.
  • Calls may originate from a JavaScript HTTP or Ajax request.  This is often the case with hits to your end user pages, the REST API or the Chat or Knowledge Foundation APIs, and the security protocol for these requests will be defined by the agent's browser - you can validate this by looking at the user agent associated with the request and verifying that it's in fact a browser.  The remediation for this would be the same as the remediation for the "What do I do about end user traffic" question above.

In general, for any custom connection to your site, from any source, you should work with your development team to review any custom code you have running on your site.  If you need assistance with updating code, please see "What if I have questions about customizations?" above.