You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
influxdb3 serve does not have support for specifying TLS options. At a minimum, I suggest being able to specify the private key and public certificate. InfluxDB 2.x OSS and 1.x Enterprise discusses this (2.x uses --tls-cert/--tls-key config/command line/env for this while 1.x uses https-certificate/https-private-key config options if you want to model it after a particular product).
Importantly, best practices indicate that the implementation needs to be able to support the private key being limited to reads by the user influxdb3 serve runs as (eg, in UNIX parlance, influxdb:influxdb ownership with 0600 permissions, root:influxdb ownership with 0640 permissions, etc (ie anything where other has no permissions). The private key should (of course) not be reachable via an API. I mention all of this in case there is a desire to store the certificate files in object store (which could possibly be made to work but it would be safer and simpler to support regular files).
While being able to specify the private key and the public certificate is the minimum requirement, being able to set the TLS minimum version (eg, via --tls-min-version or similar) as well as being able to specify the ciphers list is an often requested feature and it probably makes sense to implement them from the start. cc @gunnaraasen
I recommend using https://crates.io/crates/rustls since it has a compliant license, is widely used, we use it elsewhere and it puts us in a good position for FIPS certification down the line (see https://www.memorysafety.org/blog/rustls-with-aws-crypto-back-end-and-fips/ for some background). Conveniently, rustls also only supports TLS 1.2 and 1.3 and not earlier versions. These are both deemed safe in current practice (though we still should support --tls-min-version 1.3 (at least at some point)).
The text was updated successfully, but these errors were encountered:
influxdb3 serve
does not have support for specifying TLS options. At a minimum, I suggest being able to specify the private key and public certificate. InfluxDB 2.x OSS and 1.x Enterprise discusses this (2.x uses--tls-cert
/--tls-key
config/command line/env for this while 1.x useshttps-certificate
/https-private-key
config options if you want to model it after a particular product).Importantly, best practices indicate that the implementation needs to be able to support the private key being limited to reads by the user
influxdb3 serve
runs as (eg, in UNIX parlance,influxdb:influxdb
ownership with 0600 permissions,root:influxdb
ownership with 0640 permissions, etc (ie anything whereother
has no permissions). The private key should (of course) not be reachable via an API. I mention all of this in case there is a desire to store the certificate files in object store (which could possibly be made to work but it would be safer and simpler to support regular files).While being able to specify the private key and the public certificate is the minimum requirement, being able to set the TLS minimum version (eg, via
--tls-min-version
or similar) as well as being able to specify the ciphers list is an often requested feature and it probably makes sense to implement them from the start. cc @gunnaraasenI recommend using https://crates.io/crates/rustls since it has a compliant license, is widely used, we use it elsewhere and it puts us in a good position for FIPS certification down the line (see https://www.memorysafety.org/blog/rustls-with-aws-crypto-back-end-and-fips/ for some background). Conveniently,
rustls
also only supports TLS 1.2 and 1.3 and not earlier versions. These are both deemed safe in current practice (though we still should support--tls-min-version 1.3
(at least at some point)).The text was updated successfully, but these errors were encountered: