It's nice and easy to connect to an AWS RDS instance with Elixir Ecto over SSL/TLS, as long as you're not worried about verifying the database server's certificate. You just add a ssl: true setting when your configure the Ecto Repo, like this snippet from a config/releases.exs file for a hypothetical "myapp":
# config/releases.exs
config :myapp, MyApp.Repo,
hostname: System.get_env("DB_HOSTNAME"),
database: System.get_env("DB_DATABASE"),
username: System.get_env("DB_USERNAME"),
password: System.get_env("DB_PASSWORD"),
ssl: true
That's probably good enough for most cloud environments; but if you want to defend against a sophisticated attacker eavesdropping on or manipulating the SSL connections between your DB client and the RDS server, you also need to configure your Ecto Repo's ssl_opts setting to verify the server's certificate.
Unfortunately, this is not so straightforward. You need to either write your own certificate verification function (not trivial), or use one supplied by another library — like the ssl_verify_fun.erl library.
To use the :ssl_verify_hostname verification function from the ssl_verify_fun.erl library, first add the library as a dependency to your mix.exs file:
# mix.exs
defp deps do
[
{:ecto_sql, "~> 3.5"},
{:ssl_verify_fun, ">= 0.0.0"}
]
end
Then add the following ssl_opts setting to your Ecto Repo config:
# config/releases.exs
check_hostname = String.to_charlist(System.get_env("DB_HOSTNAME"))
config :myapp, MyApp.Repo,
hostname: System.get_env("DB_HOSTNAME"),
database: System.get_env("DB_DATABASE"),
username: System.get_env("DB_USERNAME"),
password: System.get_env("DB_PASSWORD"),
ssl: true,
ssl_opts: [
cacertfile: "/etc/ssl/certs/rds-ca-2019-root.pem",
server_name_indication: check_hostname,
verify: :verify_peer,
verify_fun: {&:ssl_verify_hostname.verify_fun/3, [check_hostname: check_hostname]}
]
Note the RDS server hostname (which would be something like my-rds-cluster.cluster-abcd1234efgh.us-east-1.rds.amazonaws.com) needs to be passed to the server_name_indication and check_hostname options as a charlist. The above example also assumes that you have downloaded the root RDS SSL certificate to /etc/ssl/certs/rds-ca-2019-root.pem on your DB client hosts.
I'd also suggest pulling out the generation of ssl_opts into a function, to make it easy to set up multiple repos. This is the way I'd do it with out our hypothetical "myapp" repo: I'd add one environment variable (DB_SSL) to trigger the Ecto ssl setting (with or without verifying the server cert), and another environment variable (DB_SSL_CA_CERT) to specify the path for the cacertfile option (triggering cert verification):
# config/releases.exs
make_ssl_opts = fn
"", _hostname ->
[]
cacertfile, hostname ->
check_hostname = String.to_charlist(hostname)
[
cacertfile: cacertfile,
server_name_indication: check_hostname,
verify: :verify_peer,
verify_fun: {&:ssl_verify_hostname.verify_fun/3, [check_hostname: check_hostname]}
]
end
db_ssl_ca_cert = System.get_env("DB_SSL_CA_CERT", "")
db_ssl = db_ssl_ca_cert != "" or System.get_env("DB_SSL", "") != ""
db_hostname = System.get_env("DB_HOSTNAME")
config :myapp, MyApp.Repo,
hostname: db_hostname,
database: System.get_env("DB_DATABASE"),
username: System.get_env("DB_USERNAME"),
password: System.get_env("DB_PASSWORD"),
ssl: db_ssl,
ssl_opts: make_ssl_opts.(db_ssl_ca_cert, db_hostname)
With this verification in place, you'd see an error like the following if your DB client tries to connect to a server with a SSL certificate signed by a CA other than the one you configured:
{:tls_alert, {:unknown_ca, 'TLS client: In state certify at ssl_handshake.erl:1950 generated CLIENT ALERT: Fatal - Unknown CA\n'}}And you'd see an error like the following if the certificate was signed by the expected CA, but for a different hostname:
{bad_cert,unable_to_match_altnames} - {:tls_alert, {:handshake_failure, 'TLS client: In state certify at ssl_handshake.erl:1952 generated CLIENT ALERT: Fatal - Handshake Failure\n {bad_cert,unable_to_match_altnames}'}}
Posts
