How to enable SSL cert verification?

[Jens Alfke <je...@couchbase.com>]

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*. There appears to be no built-in list of root certs; and there seems to be a way to pass in such a list at startup, but my Erlang skills are very rudimentary so I can't figure out how I would configure CouchDB to do this. 

Even better would be if I could install a hook to do my own cert verification by calling into iOS's native security APIs, which will have up to date root sets and access to CRL and OCSP.

--Jens

* I.e. I'm focusing on CouchDB as an SSL client (replicating to/from another server) not as an SSL server in its own right.

Re: How to enable SSL cert verification?

[Jens Alfke <je...@couchbase.com>]

On Nov 1, 2011, at 9:54 AM, Filipe David Manana wrote:

Does the following ticket matches your needs as well?
https://issues.apache.org/jira/browse/COUCHDB-1208

Ah, that’s the ticket [sic]. Thanks. I’ve gone ahead and linked 878 to this as a potential dup. Someone with more Jira-fu may want to close it.

—Jens

Re: How to enable SSL cert verification?

[Filipe David Manana <fd...@apache.org>]

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 <je...@couchbase.com> 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."

Re: How to enable SSL cert verification?

[Jens Alfke <je...@couchbase.com>]

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