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
- Example:
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.
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.
- The command below tests the HTTPS port for
- 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.