OpenSSL legacy SSL renegotiation problem

Symptoms

You are hitting random error notifications that contain: OpenSSL and SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED when calling out different APIs. 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 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. Temporary Workaround

๐Ÿ‘‰The workaround should be seen as a temporary solution:

The workaround is to enable the legacy renegotiation.

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. RCC profile has support for this starting from RCC v16.5.0:

certificates: legacy-renegotiation-allowed: true

...or you can set the environment variable: RC_TLS_LEGACY_RENEGOTIATION_ALLOWED=true

For the Python-level injection, we provide a forked package robocorp-truststore, which combines the ability to enable the OS certificate store and this workaround. So, for the dependency conda.yaml, you will need to update the following:

channels: - conda-forge dependencies: - python=3.10.12 # https://pyreadiness.org/3.10 - pip=23.2.1 # https://pip.pypa.io/en/stable/news - robocorp-truststore=0.8.0 # https://github.com/robocorp/truststore#truststore - pip: - rpaframework==27.1.0 # https://rpaframework.org/releasenotes.html

Troubleshooting and tools

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; if not, 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: September 21, 2023