certificate-based authentication for https hgwebdir clients

Dimitris Glynos dimitris at census-labs.com
Tue Jan 6 08:31:35 CST 2009


Hello all,

I'm attaching a patch that enables hgwebdir to do basic certicate-based
authentication for clients, in https mode. By 'basic' I mean that the
client's certificate is checked against a list of registered certificates
and if it is not found in the list (or is invalid), the SSL session is
terminated.

A few words about the patch:

* A new option, '--require-client-cert', has been added to 'hg serve'.
   This turns on the client-authenticated handshake mode of SSL.

* A new section, 'https_clients', has been added to the hgwebdir config
   file, describing the client certificates that will be allowed to
   participate in SSL sessions. Each certificate is described by a
   key-value pair:
 	- The key is a 'nickname' given by the hgwebdir admin to this
 	  certificate.
 	- The value is the SHA1 digest of the certificate
 	  (i.e. openssl x509 -fingerprint -in cert.pem -sha1 -noout)
   An example follows:

   [https_clients]
   joe = 0F:12:42:32:42:24:12:12:12:12:45:23:24:23:24:25:23:23:23:11
   amy = 11:23:23:11:42:42:16:11:AE:15:A8:11:23:82:00:02:08:15:23:43

* A new section, 'https', has been introduced to the client's config file
   (.hgrc). This describes the certificates the client will be using during
   https sessions. Here's an example of this section:

   [https]
   cert_file = /home/joe/pubkey.pem
   key_file = /home/joe/privkey.pem

* Self-signed client certificates are considered OK (as far as certificate
   validity is concerned).

* I've added a short script that tests the client/server behaviour
   when the client provides:
 	- a registered certificate
 	- an unregistered certificate
 	- no certificate at all

What's the reasoning behind this?

There are times when you don't want to setup a full-blown webserver
with its own acl/authentication scheme, because you will be working
in an ad-hoc manner with others (i.e. no single repository will be
online at all times). Even more so, you might not want to provide
ssh accounts to third parties on the host serving the repository.

'hg serve' is perfect for these types of situations, but it is
really missing an authentication method to control access to
the repositories. This patch is a first step in this direction.
It provides a certificate-based authentication mechanism for https
and could be coupled with the existing framework for acl's, so that
certificate holders (see 'nicknames' above) are treated as regular
repository users.

...hoping this functionality makes it through to hg :-)

(On a more personal note) Best Wishes for a Happy New Year and a big 
THANK YOU for all your great work on Mercurial!

--
dimitris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client-auth-https.patch
Type: text/x-diff
Size: 15406 bytes
Desc: 
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20090106/24e3605f/attachment.patch 


More information about the Mercurial-devel mailing list