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

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-CHACHA20-POLY1305
tls1_2: ECDHE-RSA-AES128-GCM-SHA256
tls1_2: ECDHE-RSA-AES256-SHA384
tls1_2: ECDHE-RSA-AES128-SHA256
tls1_3: ECDHE-ECDSA-AES256-GCM-SHA384
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"
 done
done
=====================

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
..snipped...
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

+### CUSTOMIZATION
+#
+# 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
+[custom_conf]
+ssl_conf = ssl_sect
+[ssl_sect]
+system_default = system_default_sect
+[system_default_sect]
+CipherString = DEFAULT:@SECLEVEL=1
+MinProtocol = TLSv1.2
+### END CUSTOMIZATION
+
 # 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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/