Git clone fails with unsafe legacy renegotiation disabled in Bitbucket Data Center
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Atlassian applications allow the use of SSL with our products, however Atlassian Support does not provide assistance for configuring them. Consequently, Atlassian can not guarantee providing any support for them.
If assistance with configuration is required, please raise a question on Atlassian Answers.
Summary
Git clone fails with unsafe legacy renegotiation disabled error from OPENSSL3 environment
error:0A000152:SSL routines::unsafe legacy renegotiation disabled
Closing connection 0Environment
Bitbucket Data Center - 7.17.x and newer
Git client with OPENSSL3 version
Operating System - Fedora 36, Redhat Linux 9
Diagnosis
Run the below openssl command from one of the client machines (with openssl3)
openssl s_client -debug -connect <BITBUCKET_BASEURL>:<HTTPS_PORT>
#For example:
openssl s_client -debug -connect git.mydomain.com:443From the command output, you'll see Secure Renegotiation IS NOT supported
Cause
Starting with OpenSSL3, and thus Fedora 36 and RHEL 9, TLS connections expect the server to send the renegotiation_info extension, specified in 2010 in RFC5746 in response to CVE-2009-3555. The server where SSL is offloaded (this can be your load balancer or proxy server in front of Bitbucket DC (if you've load balancer/reverse proxy configured)) does not support TLS Renegotiation Indication Extension RFC 5746.
From TLS Renegotiation Indication Extension (RFC 5746)
Secure Socket Layer (SSL) and Transport Layer Security (TLS)
renegotiation are vulnerable to an attack in which the attacker forms
a TLS connection with the target server, injects content of his
choice, and then splices in a new TLS connection from a client. The
server treats the client's initial TLS handshake as a renegotiation
and thus believes that the initial data transmitted by the attacker
is from the same entity as the subsequent client data. This
specification defines a TLS extension to cryptographically tie
renegotiations to the TLS connections they are being performed over,
thus preventing this attack.
OpenSSL3 contains a change to the default settings which requires support for secure renegotiation in a bid to improve security, as explained in the OpenSSL 3 migration guide. Secure renegotiation is now required by default for SSL/TLS connections to succeed. Since the load balancer/ proxy server in front of the Bitbucket server does not support secure renegotiation, the connection over SSL/TLS fails from the Open SSL3 clients.
Solution
Configure the server (where SSL is offloaded) to support secure renegotiation as per TLS Renegotiation Indication Extension (RFC 5746)