SSL Legacy Renegotiation failure

Be sure to check out Troubleshooting SSL Issues as it provides a quick step by step guide that might fix your problem without getting too technical. If this is not enough to solve your issues, this page offers more in depth information.

Symptoms

You are hitting error notifications that contain: OpenSSL and SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED when calling out different APIs.

The feature is also called Secure renegotiations in some cases.

The source tool and target systems can vary a lot:

  • pip calls can fail when loading data from PyPI
  • Robocorp Vault calls can fail in robot runs
  • Calls to APIs like Salesforce can fail randomly.

Reason

Some servers or MITM Firewall setups seem to be still using the SSL Legacy Renegotiation methods, and now (09/2023), after OpenSSL has officially moved to v3, that by default considers this as an error, multiple tools are hitting this problem.

Legacy SSL renegotiation is an outdated and insecure method for establishing secure connections on the internet. To enhance security and protect against vulnerabilities, SSL Legacy Renegotiation has known vulnerabilities, such as the "Renegotiation Attack," which can lead to session hijacking and other security threats, so it's crucial to move to the latest TLS (Transport Layer Security) versions and adopt the new renegotiation system. Source: CVE-2009-3555

Solution

1. Address the Root Cause

Your first step should always be identifying and contacting the host system responsible for the error. Request that they update their systems to use the latest TLS version and adopt the new renegotiation methods. To identify the problematic host system, check the server hostname or URL provided in the error logs.

If you are behind a MITM Firewall or proxy, the source of the error can also be the firewall host.
> Troubleshooting and tools contains details and helper tools for your IT to identify the root cause based on the URL or hostname

2. Workaround

👉The workaround should be seen as a temporary solution, but unfortunately, there are still a lot of servers out there that have not enabled the secure renegotiation.

The workaround is to allow the legacy renegotiation.

The workaround needs to be set for different tool stacks, so at the moment, there are two steps:

  • Allow for NodeJS applications and tools
  • Allow for Python and libraries

2.1. Allow Legacy Renegotiation for NodeJS

  • Create a config file with the following content:

    • For example, on Windows: C:\programdata\robocorp-openssl\openssl.cnf

      nodejs_conf = openssl_init [openssl_init] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] Options = UnsafeLegacyRenegotiation
  • Add an environment variable OPENSSL_CONF that points to the config file

    • Example: OPENSSL_CONF=C:\programdata\robocorp-openssl\openssl.cnf

2.2. Allow Legacy Renegotiation for the Python tool stack

For the Python side and libraries, we have added support in our libraries and tools for an environment variable to set this config on the Python level for the Robocorp tool stack.

👉 Update the dependencies of your automations to support the latest libraries.

channels: - conda-forge dependencies: - python=3.10.12 - pip=23.2.1 - robocorp-truststore=0.8.0 - pip: - --use-feature=truststore - rpaframework==27.4.1 # or later - robocorp==1.0.0 # or later

Python 3.10.12 is enables the use of robocorp-truststore, which in turn enables:
--use-feature=truststore -flag that guides pip also to leverage system certificates.

👉 We recommend using the RCC profile to control the Python tool stack side

  • Requires RCC v16.5.0 or later

  • RCC profile supports legacy-renegotiation-allowed: true (example below)

    certificates: legacy-renegotiation-allowed: true
  • Setup Utility: The latest version also has UI support for setting this

  • You can also directly set the environment variable RC_TLS_LEGACY_RENEGOTIATION_ALLOWED=true

Tools and tests

This section is mainly meant for IT-level users to find the correct source host.

If you suspect a Man-in-the-Middle (MITM) firewall or proxy issue, use RCC to run rcc config diagnostics and check TLS versions and certificate provider names. Look for the "certificate issued by" field to identify potential MITM interference. For example, the output for files.pythonhosted.org should contain GlobalSign; otherwise, you are probably behind an MITM firewall.

We offer specialized tools to simplify the process:

  • From RCC v16.6.0, we have a direct command to test specific hosts TLS supports:
    • The command below tests the HTTPS port for files.pythonhosted.org and the IMAP connection to the Outlook email server.
    • rcc config tlsprobe files.pythonhosted.org outlook.office365.com:993
    • The output contains results for different TLS versions, used cipher and certificates, and other details that help the more complex troubleshooting cases.
  • In Setup Utility, you can define Additional diagnostic checks, and there is a separate tls -section support.
  • TLS Logging bot

You can also consider using readily available tools like curl, OpenSSL, or Wireshark to find more details on the target host.

Last edit: October 12, 2023