apache / apache/couchdb

Simplify TLS peer verification for replication

Open
#4,390 0 comments 0 reactions 0 assignees View on GitHub
enhancement needs-triage
Dominant language
Erlang
Stars
7k
Forks
1.1k
Avg merge
1d 16h
Merged PRs (30d)
9

Description

By default replicator TLS connections do not verify the TLS peer certificates https://github.com/apache/couchdb/blob/f8d489f3185accb9acd4d732330d52d9d05bb19a/src/couch_replicator/src/couch_replicator_parse.erl#L474-L478

It's probably for a good reason, Erlang < 25 doesn't even have a good way to load OS provided CAs. Only starting in Erlang 25 we have `public_key:cacerts_get()`. The certificates are loaded and cached in a permanent literal term and then it can be easily used as:

```
{ok, _} = httpc:request(get, {"https://erlang.com", []}, [{ssl, [{verify, verify_peer}, {cacerts, public_key:cacerts_get()}]}], []), ok.
```

The enhancement would be to make TLS peer verification a bit more ergonomic making it easy to use OS provided CAs. We could backport Erlang 25 cert loading code unto a compat `couch_util` function until we can have Erlang 25+ only required OTP version.

Another option is to use [certify](https://github.com/certifi/erlang-certifi), but that's another dependency to bring in and since Erlang already plans on providing the feature might as well use the OTP solution.

As for how to configure it, perhaps we could have have a special `ssl_trusted_certificates_file` value indicating we want to load the OS provided CAs, or a separate config option like `ssl_use_os_certificates = true | false`. Maybe even allow appending user's CA trusted certificated to the OS ones?

Contributor guide

Open the contributing guide

Research direction

Start at src/couch_replicator/src/couch_replicator_parse.erl around lines 474-478 to understand the current TLS peer-verification defaults. Review the proposed OTP 25 public_key:cacerts_get() approach and the possible couch_util compatibility or configuration options. Done means replicator TLS can use OS-provided CAs through a clearly defined configuration without requiring users to manage the certificates manually.

Written by the indexing model from the issue text.

Assessment

Tech stack
erlang
Domain
backend, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.