certificate-based authentication for https hgwebdir clients

[Matt Mackall]

On Tue, 2009-01-06 at 16:31 +0200, Dimitris Glynos wrote:
> 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.

This patch requires having the Python OpenSSL bindings installed, yes?
That's a little unfortunate. Calling out to the openssl executable (one
dependency which most people already have) might actually be preferable
to adding a library (one more dependency).

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

Hmm, what about hgweb? We pretty much have to support everything that hg
serve can do in hgweb. This would probably be better off as a config
option in any case.

>    [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

You apparently haven't heard about my hatred of underbars. This could
use a better name, but I'm not sure what.

> * 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).

That's probably fine. It's not as if servers are going to deciding
whether to trust unknown clients based on whether their certificates are
signed by Verisign.


I'm actually much more interested in the reverse problem: authenticating
servers to clients. We need cert authentication on at least one end to
prevent MITM attacks and in most cases the cert will live on the server
side. Given that we're probably not going to go to the trouble of adding
an audited list of trusted roots to hg like a browser does, it's
probably sufficient to add something like the above hashes to ~/.hgrc on
the client. Thoughts?

(Yes, folks, Mercurial's https support is vulnerable to MITM attacks,
but so are modern browsers! If you're paranoid, you should be using ssh
instead and manually exchanging host keys.)

-- 
Mathematics is the supreme nostalgia of our time.