Does the following ticket matches your needs as well? https://issues.apache.org/jira/browse/COUCHDB-1208
On Tue, Nov 1, 2011 at 4:46 PM, Jens Alfke <[email protected]> wrote: > > On Nov 1, 2011, at 9:06 AM, I wrote: > >> Having just gotten SSL working in Couchbase Mobile for iOS, I'm looking at >> the Erlang SSL API trying to figure out how to get it to properly validate >> server certs*. > > Jan kindly pointed me at issue COUCHDB-878*, which includes a patch that adds > config options to turn on cert verification and provide a root cert. This > doesn’t appear to have been committed even though the bug’s been open for > more than a year. Why not? As the description points out, this is a > significant security hole: > >> Description: "When doing an SSL replication, CouchDB does not check the >> certificate chain. This renders the SSL support absolutely useless since an >> attacker who is in the position of doing man-in-the-middle attacks can send >> an invalid certificate and gets all my data (push replication)." > > I wouldn’t say it’s _absolutely_ useless, as data is still hidden from anyone > but the remote peer; but it’s true that you have no assurance that the remote > peer is who you think it is. :-p > > I haven’t read the patch, but it doesn’t sound as though it’s enough for > general use, if it indeed only lets you specify one root cert (not a list of > them.) Even with a full root-cert list there would still be issues like > keeping that list up to date (remember all those CA compromises in just the > last few months?), and lack of support for cert revocation (CRL or OCSP). The > best solution would be a hook into a NIF that integrated with the OS’s > underlying native security library. > > —Jens > > * https://issues.apache.org/jira/browse/COUCHDB-878 > > -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
