Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Message-ID: <27555686.42941286551292148.JavaMail.jira@thor>
Date: Fri, 8 Oct 2010 11:21:32 -0400 (EDT)
From: "Filipe Manana (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Subject: [jira] Updated: (COUCHDB-491) Support replication over SSL
In-Reply-To: <465934501.1251742052796.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/COUCHDB-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filipe Manana updated COUCHDB-491:
----------------------------------

    Attachment: COUCHDB-491.patch

The following patch is basically what I added for desktopcouch.

The issue that desktopcouch had was that, the replicator, when sending the request for a remote's _changes/, it blocked after receiving the response headers. Issuing the exact same request (including OAuth tokens, etc) with curl just worked.

Found that the reason was that we need to pass the option {is_ssl, true} to ibrowse as well as ssl socket options to specify if peer certification should be done, max certificate depth and client trusted certificates file (a file in PEM format).

Oddly enough this issue didn't arise when doing the initial  requests to verify if the target DB exists and remote replication checkpoint (by coincidence none of those requests was generating a response with a body).

The following patch adds 3 new .ini config parameters to the replicator section:

[replicator]
; set to true to validate peer certificates
verify_ssl_certificates = false
; file containing a list of peer trusted certificates (PEM format)obert
; ssl_trusted_certificates_file = /etc/ssl/certs/ca-certificates.crt
; maximum peer certificate depth (must be set even if certificate validation is off)
ssl_certificate_max_depth = 3

I feel the section for these options is right. Nevertheless the last 2 might be useful as well outside the replicator's scope, that is, to validate client certificates.

Robert Newson added sometime ago SSL support to CouchDB's httpd, and created the .ini section [ssl]. Even if client verification is added, it might be useful to specify different settings from the ones used by the replicator, so maybe duplicating them in the [ssl] .ini section is a good idea.

I would like to have feedback on this, and definitily I think the issue should be fixed for 1.1.

> Support replication over SSL
> ----------------------------
>
>                 Key: COUCHDB-491
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-491
>             Project: CouchDB
>          Issue Type: Improvement
>            Reporter: eric casteleijn
>             Fix For: 0.10
>
>         Attachments: COUCHDB-491.patch
>
>
> CouchDB currently does not support replication over SSL which is a problem when replicating non public databases between two CouchDB servers over the internet.
> It seems SSL support is almost there, though:
> If ssl is started from bin/couchdb, push replication to a couchdb that is behind an SSL proxy works (i.e. to an https:// url), but pull replication from same fails, because apparently the request is not encrypted at all. (At least nginx seemed to think it wasn't.)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.