[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bug: Svn client will no longer connect to old SVN server

From: Mark Phippard <markphip_at_gmail.com>
Date: Mon, 15 Jun 2020 08:40:37 -0400

On Mon, Jun 15, 2020 at 5:05 AM Michael Back <mback_at_qti.qualcomm.com> wrote:

> Hello Subversion folks,
> When I upgraded to the latest version of my Linux OS (Ubuntu 20.04) and
> installed Subversion 1.13.0 client, svn could no longer connect to our
> company's old subversion server via https.
> Doing a checkout results in the same error.
> The server (I am told) is running RHEL 6.10 with OpenSSL 1.0.1.
> I understand that the old server is limited to using the old insecure
> TLSv1... I'm not IT though with no power to upgrade the server... and I
> just want to use our internal system. How do I configure the new svn to
> connect to the old server?

We ran into similar problems with one of our servers after upgrading to
Ubuntu 20.04.

There is no reason that your server cannot offer TLS 1.2 so the first thing
I would do is check whether it does or not. This script will list all of
the protocols and ciphers available on your server. Run it like this:

$ ./testssl.sh svn.apache.org 443
tls1_2: ECDHE-RSA-AES256-GCM-SHA384
tls1_2: ECDHE-RSA-AES128-GCM-SHA256
tls1_2: ECDHE-RSA-AES256-SHA384
tls1_2: ECDHE-RSA-AES128-SHA256
tls1_3: ECDHE-RSA-AES256-GCM-SHA384
tls1_3: DHE-DSS-AES256-GCM-SHA384
tls1_3: DHE-RSA-AES256-GCM-SHA384
... snipped

Here is the script

for v in ssl3 tls1 tls1_1 tls1_2 tls1_3; do
 for c in $(openssl ciphers 'ALL:eNULL' | tr ':' ' '); do
 openssl s_client -connect $1:$2 \
 -cipher $c -$v < /dev/null > /dev/null 2>&1 && echo -e "$v:\t$c"

In my case, our server did offer TLS 1.2 but the problem was that the DHE
cipher it offered was using a weak key and OpenSSL would reject it. If you
tried to connect using OpenSSL we would see this error:

$ openssl s_client -connect servername:443 > /dev/null
139712693810496:error:141A318A:SSL routines:tls_process_ske_dhe:dh key
too small:../ssl/statem/statem_clnt.c:2149:

We found this workaround that we could do on the client to tell OpenSSL to
accept the weak DHE key size.

diff -u /etc/ssl/openssl.cnf~ /etc/ssl/openssl.cnf
--- /etc/ssl/openssl.cnf~ 2020-04-28 11:13:02.410766406 -0400
+++ /etc/ssl/openssl.cnf 2020-04-28 11:13:15.922686018 -0400
@@ -15,6 +15,23 @@
 #oid_file = $ENV::HOME/.oid
 oid_section = new_oids

+# Reduce the security level a bit. Internal DHE keys are
+# too short, and Subversion+libserf seemingly won't fall back to another
+# cipher once they've agreed upon one that _should_ work (but
+# doesn't).
+openssl_conf = custom_conf
+ssl_conf = ssl_sect
+system_default = system_default_sect
+CipherString = DEFAULT:@SECLEVEL=1
+MinProtocol = TLSv1.2
 # To use this configuration file with the "-extfile" option of the
 # "openssl x509" utility, name here the section containing the
 # X.509v3 extensions to use:

So this solution is only going to help if you have the same problem, but
maybe you can follow the same path towards finding your solution.

Mark Phippard
Received on 2020-06-15 14:40:54 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.