Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.10
    • Component/s: None
    • Labels:
      None

      Description

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

      1. COUCHDB-491.patch
        3 kB
        Filipe Manana

        Issue Links

          Activity

          Hide
          Adam Kocoloski added a comment -

          Resolved and merged to the 0.10.x branch

          Show
          Adam Kocoloski added a comment - Resolved and merged to the 0.10.x branch
          Hide
          eric casteleijn added a comment - - edited

          Actually this is still not working in 1.0.1 or trunk. Filipe is working on this, but it does not seem this was ever really fixed before. The reason this escaped our attention for so long is that we worked around it on the server side, by forcing a 404 on _changes, so that clients would fall back to non-streaming replication. Of course this is no longer possible in 1.0

          Show
          eric casteleijn added a comment - - edited Actually this is still not working in 1.0.1 or trunk. Filipe is working on this, but it does not seem this was ever really fixed before. The reason this escaped our attention for so long is that we worked around it on the server side, by forcing a 404 on _changes, so that clients would fall back to non-streaming replication. Of course this is no longer possible in 1.0
          Hide
          Filipe Manana added a comment -

          While looking into this, found a bug in ibrowse when streaming chunked responses:

          http://github.com/cmullaparthi/ibrowse/issues/#issue/7

          I can't reproduce Eric's issues with SSL.
          However, without the following patch:

          http://github.com/fdmanana/desktopcouch-ubuntu-10_10/commit/49eb401b991f334ab06cc7a0f4031c7aafb927a7

          I couldn't get the pull replication to work.

          Investigating more about this.

          Show
          Filipe Manana added a comment - While looking into this, found a bug in ibrowse when streaming chunked responses: http://github.com/cmullaparthi/ibrowse/issues/#issue/7 I can't reproduce Eric's issues with SSL. However, without the following patch: http://github.com/fdmanana/desktopcouch-ubuntu-10_10/commit/49eb401b991f334ab06cc7a0f4031c7aafb927a7 I couldn't get the pull replication to work. Investigating more about this.
          Hide
          Filipe Manana added a comment -

          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.

          Show
          Filipe Manana added a comment - 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.
          Hide
          Filipe Manana added a comment -

          Patch COUCHDB-491.patch committed to trunk (revision 1023274).

          Show
          Filipe Manana added a comment - Patch COUCHDB-491 .patch committed to trunk (revision 1023274).

            People

            • Assignee:
              Unassigned
              Reporter:
              eric casteleijn
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development