Send SNI information when connecting via TLS #7
Conversation
lava
force-pushed
the
topic/openssl-sni
branch
from
2b55680
to
7703f97
Compare
Without this setting, OpenSSL would only validate that the certificate has a valid signature from a trusted CA, but not that it actually matches the host to whom we were trying to connect.
CAF currently expects to receive OpenSSL certificates and keys as filenames. This matches the expectations of libopenssl, but is cumbersome to use in a Cloud context. In particular, ECS can only pass secrets as environment variables. So we extend the command-line option to also accept a string like `env:SOME_VARIABLE` and read the contents from the environment variable `SOME_VARIABLE`.
lava
force-pushed
the
topic/openssl-sni
branch
from
0a7d5d4
to
edf4fb7
Compare
| ofs << *contents; | ||
| ofs.close(); | ||
| return filename; | ||
| } |
There was a problem hiding this comment.
I just realized that this approach will only work for docker-compose, there's no good way to inject environment variables when the user uses his own vast and a vast.yaml.
However adding the value without the indirection has the disadvantage that the secrets will appear everywhere the VAST config is printed.
There was a problem hiding this comment.
Can we make it possible to pass the file path in the env variable for the second case?
There was a problem hiding this comment.
A file path is how it already works, before our patches.
I think the cleanest solution is to not pass this via config at all but to provide a /get-client-certificates endpoint where we can download everything before starting CAF. (and to only use this mechanism for the manager nodes) But for the short term I just added support for putting the PEM directly into the option.
* Support for reading private keys and certificates directly as opposed to specifying the name of a separate environment variable, since the latter is not possible when using a `vast.yaml` config file. Note that this is just a crux, eventually we want to have a cloud endpoint where the node can download the required TLS files on the fly given some auth token. * Support for OpenSSL 1.1.1 series. The OSSL_DECODER API is not available on that version, which is used on Debian Bullseye.
lava
force-pushed
the
topic/openssl-sni
branch
from
1cca273
to
1804776
Compare
Unlike its lower-level variants, `PEM_read_bio_PrivateKey` is not officially deprecated yet so we can avoid maintaining two versions of the private key loading by relying on that.
Co-Authored-By: Tobias Mayer <tobim@fastmail.fm>
No description provided.