On Fri, Jan 16, 2015 at 10:35:46AM +0300, Navrotskiy Artem wrote:
> 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:
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.
Received on 2015-01-16 11:04:08 CET