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

Re: Subversion authentication security issue (svnserve, MITM)

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 16 Jan 2015 11:03:17 +0100

On Fri, Jan 16, 2015 at 10:35:46AM +0300, Navrotskiy Artem wrote:
> Hello.
>
> Subversion includes many types of connection:
>
> * svnserve - plain password over network
> * svnserve + ssh - secure, but unusable slow
> * http - plain password over network
> * https - secure
>
> In the case of svnserver default instead of the password hash is transmitted over the network, and this configuration looks like a safe.
> But this is not so, because the MITM-server can request SASL PLAIN-authorization. In this situation, the client is unable to authenticate the server and sends the password in plain text without warning.

Yes, using SASL on unprotected links is inherently unsafe.

PLAIN auth used to be rejected by the client but this was changed some
years ago to allow authentication with saslauthd to work, which requires
PLAIN authentication: http://svn.apache.org/r878279

I've never seen or heard of svnserve/SASL deployments on the internet.
svnserve/SASL is not widely used. We get only occasional reports of people
failing to set it up, few enough to make me believe that very few people
even try. SASL integration is not well documented so it's much harder to
configure than other options like HTTPS or SVN+SSH.

For svnserve over the internet, everyone should use SVN+SSH.

> Configuration svnserver + ssh even in local network adds more overhead to establish the connection (I have 0.3 seconds per connection). Console svn client reconnects too often (eg, svn status -u A.txt B.txt C.txt produces 6 serial connections).

You can improve performance by making use of SSH connection pooling.
See the ssh_config(1) man page:

     ControlMaster
             Enables the sharing of multiple sessions over a single network
             connection. When set to yes, ssh(1) will listen for
             connections on a control socket specified using the ControlPath
             argument. Additional sessions can connect to this socket using
             the same ControlPath with ControlMaster set to no (the
             default). These sessions will try to reuse the master instance's
             network connection rather than initiating new ones, but will fall
             back to connecting normally if the control socket does not exist,
             or is not listening.

> As a solution to this problem, it seems reasonable wrapping svnserver protocol SSL.
> This will, at least to check the validity of the server on the client side. And svnserver + ssl looks cheaper than svnserver + ssh in terms of overhead.

TLS support in svnserve would be great. Would you be willing to work on it?
It's not a very simple task because of backwards compatibility concerns with
svn clients that don't support TLS.

As a workaround you could use stunnel on the client and server.
https://www.stunnel.org/index.html
Received on 2015-01-16 11:04:08 CET

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

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