Simplify TLS peer verification for replication
- 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
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