Git clone fails with unsafe legacy renegotiation disabled in Bitbucket Data Center

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問


プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。

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.

*Fisheye および Crucible は除く

アトラシアンの製品はSSLに対応しています。しかし、アトラシアンのサポートはその設定に対して支援は行いません。つまり、アトラシアンではこれらに関するあらゆるサポートの提供が保証されません

設定に関してサポートが必要であれば、Atlassian Answers に質問をあげてください。

要約

Git clone fails with unsafe legacy renegotiation disabled error from OPENSSL3 environment

error:0A000152:SSL routines::unsafe legacy renegotiation disabled
Closing connection 0

環境

Bitbucket Data Center - 7.17.x and newer

Git client with OPENSSL3 version

Operating System - Fedora 36, Redhat Linux 9

診断

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:443

From the command output, you'll see Secure Renegotiation IS NOT supported

原因

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.

ソリューション

Configure the server (where SSL is offloaded) to support secure renegotiation as per TLS Renegotiation Indication Extension (RFC 5746)



最終更新日: 2023 年 10 月 24 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.