couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Jackson <>
Subject Re: CouchDB 1.1
Date Wed, 15 Sep 2010 21:22:26 GMT

> There's certainly a discussion on how to safely permit custom/local
> certificate authorities, I was just raising awareness that OTP
> defaults to allowing unknown_ca which I think we all see as a big
> security issue. The OTP motivation is explicitly "to make SSL as easy
> as possible" but it does throw out all the security of the protocol in
> the process, which is as bad as it gets.

Sure, I was just thinking that if there are plans to cut a release with SSL improvements,
it would make sense to get my patch submitted and reviewed to make the SSL support less incremental.

> Since the HTTPS support I added (by importing a new mochiweb with ssl
> support) adds a config variable for a ca.pem file, perhaps we can
> leverage that.

Certainly - no point in duplicating parameters. The replicator SSL verification could trivially
pick up this parameter instead of the identical one I've added.


> B.
> On Wed, Sep 15, 2010 at 10:13 PM, James Jackson <> wrote:
>> Hi,
>>> 1) The replicator allows ssl connections to hosts with self-signed
>>> certificates by default, obviating the security of the protocol. Since
>>> this is the OTP default (seriously), we probably want to get a patch
>>> upstream as well.
>> There is a patch for this here:
>> I have a local patch which folds this verification function with the added ability
for SSL replication sessions to be be authenticated by a key / cert pair; I haven't had a
chance to test it though (waiting on our authenticating front-end to be set up) so haven't
submitted the patch. If somebody is willing to test it, I can open up a ticket with the patch.
>> As essentially the patch builds SSL parameters for the http_db objects which get
passed around the replicator, it made sense to factor the verification and SSL certification
stuff into one 'get_ssl_parameters' function.
>> Regards,
>> James.

View raw message