couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Jackson <>
Subject Replication via SSL - certificate support and possible proxy bug
Date Fri, 10 Sep 2010 00:03:52 GMT
Hi all,

Just testing the water for if a patch would be welcome... We plan to run replication on remote
sites, which must be authenticated via SSL certificates (X.509). I believe to do this requires
very minimal changes. As an un-compiled, un-tested example, something like the following:

In couch_rep.erl:

do_init([RepId, {PostProps}, UserCtx] = InitArgs) ->
    % Parse SSL certificate options
    TmpCert = couch_config:get("ssl", "replication_certfile", nil),
    TmpKey = couch_config:get("ssl", "replication_keyfile", nil),
    SSLParams = case {TmpCert, TmpKey} of
        {nil, nil} -> [];
        {nil, _} -> [];
        {_, nil} -> [],
        {C, K} -> [{ssl_options, [{certfile, C}, {keyfile, K}]}]

    ProxyParams = parse_proxy_params(
        couch_util:get_value(<<"proxy">>, PostProps, [])),
    Source = open_db(SourceProps, UserCtx, ProxyParams, SSLParams),
    Target = open_db(TargetProps, UserCtx, ProxyParams, SSLParams, CreateTarget),

Note that all open_db functions now need an extra SSLParams parameter. Alternatively, this
could be tacked-on the the ProxyParams list, but then the name doesn't make sense... In couch_rep_httpc.erl:

open_db({Props}, _UserCtx, ProxyParams, SSLParams, CreateTarget) ->
    Db = Db1#http_db{options = Db1#http_db.options ++ ProxyParams ++ SSLParams},

I believe ibrowse should now take care of everything from hereon in. I note that there is
a patch from Monday which fixes a possible certificate authentication security hole (,
which also deals with ssl-related things in couch_rep_httpc.erl. This certificate functionality,
and the SSL verification from the patch, could be wrapped as a 'make_ssl_opts' function.

Additionally, I see that in db_exists, the calls to ibrowse:send_req do not pass the options
from the #http_db record; surely this means that the proxy (if specified), and the SSL authentication,
if implemented as above, will not be used for the initial PUT / HEAD requests?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message