Hi, > 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. Regards, James. > > B. > > On Wed, Sep 15, 2010 at 10:13 PM, James Jackson <[email protected]> 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: >> >> https://issues.apache.org/jira/browse/COUCHDB-878 >> >> 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.
