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

[PATCH] SSL layer for svnserve

From: Sigfred Håversen <bsdlist_at_mumak.com>
Date: 2004-10-18 20:03:48 CEST

I've added a SSL layer to svnserve, and I would like to have some comments
on the patch. Instructions how to run "make check" with self-signed certificate,
is below.

To start svnserve with SSL enabled :

$ svnserve --daemon --root /path/to/repo \
  --cert-file server_public_certificate \
  --key-file private_key_to_server_certificate

A client will use svn as usual. If the server certificate is
unknown, however, the user will be prompted for acceptance
of it :

$ svn co svn://localhost/repo repo

A SSL enabled svnserve will announce it's SSL functionality as a
"ssl capability" that is exchanged during the greeting phase between
server and client. After a SSL connection has been successfully setup,
the usual communication between svnserve and client is now encrypted.

Clients with SSL capability may connect to svnserve that has not
enabled SSL.

A few points to note for a SSL enabled svnserve :

  * svnserve will refuse clients that does not have SSL capability.
  * Since the realm is sendt as part of the greeting, this will not be
  * The client must at least use version 2 of the svnserve protocol.

Example of information leak (using strings on output from tcpdump on lo0) :

8N( success ( 2 2 ( ANONYMOUS ) ( edit-pipeline ssl ) ) ) L
8N( 2 ( edit-pipeline ssl ) 43:svn://localhost/repositories/basic_tests-15 ) M

To avoid sending "svn://localhost/repositories/basic_tests-15" would
require a change in the version 2 protocoll, or that less information is
sendt upon initial greeting.

The patch uses OpenSSL, and uses a BIO pair to handle the communication
between SSL and the network :

  Subversion | TLS-engine
     | |
     +----------> SSL_operations()
              | /\ ||
              | || \/
              | BIO-pair (internal_bio)
     +----------< BIO-pair (network_bio)
     | |
   socket |
The function writebuf_output in libsvn_ra_svn/marshal.c will use SSL
operations for transferal of data. Similarly for readbuf_input.
For this to work, svn_ra_svn_conn_t has to be extended with relevant
data that the SSL operations needs for each connection.

A so-called SSL context is used when setting up the SSL connection,
and ra_svn_session_baton_t and server_baton_t has a new such member.

On the server side, the SSL setup for each connection is handled
by serve() in svnserve/serve.c. For the client side this is
handled by ra_svn_open() in libsvn_ra_svn/client.c.

There are several other helper functions for managing the SSL
operations, as well as handling of certificates on the client side.

The patch was developed on an OpenBSD machine. So other *BSD/Linux
should be able to build. The enabling of SSL for svnserve should be
part of the configure, but I'm no configure guru. I quite simply replaced
in Makefile (on my system) the "LIBS = -lintl" with
"LIBS = -lintl -lssl -lcrypto" during development.

The "make check BASE_URL=svn://localhost" will work as usual for
svnserve not using SSL. However, when SSL is enabled, the tests
will hang waiting for user input to accept/reject certificate.

As a temporary solution, I hacked main.py to use /tmp/svnserve_config
as parameter to --config-dir, and autoprop_tests.py to only use
svntest.main.config_dir as config_dir.

For testing using "make check", I've attached two shell scripts :

"myservecheck" generates a self-signed certificate, and
then start a SSL enabled svnserve.

"mycheck" runs "make check", but uses "svn ls" to accept the
server certificate generated by "myservecheck".

With these scripts, all tests in "make check" passes.

Sigfred Haversen.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

  • application/x-shellscript attachment: mycheck
Received on Mon Oct 18 20:04:07 2004

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.