TLS config flexibility - #13
Merged
Merged
Conversation
Branch: TLSConfigFlexibility AI-usage: full (Hermes + Qwen3.6-35b) Signed-off-by: Gabe Goodhart <ghart@us.ibm.com>
Branch: TLSConfigFlexibility AI-usage: full (Hermes + Qwen3.6-35b) Signed-off-by: Gabe Goodhart <ghart@us.ibm.com>
Branch: TLSConfigFlexibility AI-usage: Full (OpenCode + Qwdn3.6-35b) Signed-off-by: Gabe Goodhart <ghart@us.ibm.com>
Branch: TLSConfigFlexibility AI-usage: full (OpenCode + Qwen3.6-35b) Signed-off-by: Gabe Goodhart <ghart@us.ibm.com>
Previously, the name REMOTE_CONTROL_CLIENT_CA was ambiguous as to whether it was the CA used to sign the client cert or the CA that the client should trust (ie the CA used to sign the server cert). The new names line up with the values internally that make it clear (cfg.ClientTLS.TrustedCAFile is the CA used to sign the server that the client shoudl trust) Branch: TLSConfigFlexibility AI-usage: none Signed-off-by: Gabe Goodhart <ghart@us.ibm.com>
… verification According to the documentation, VerifyConnection runs on all handshakes whereas VerifyPeerCertificate only runs on initial connections. This also fixes setting InsecureSkipVerify to skip the default verification. The custom verification always runs, regardless of the InsecureSkipVerify value See: https://pkg.go.dev/crypto/tls#Config Branch: TLSConfigFlexibility AI-usage: draft (Bob) Signed-off-by: Gabe Goodhart <ghart@us.ibm.com>
The names should match across json and CLI even if snake vs kebab case are different Branch: TLSConfigFlexibility AI-usage: none Signed-off-by: Gabe Goodhart <ghart@us.ibm.com>
Branch: TLSConfigFlexibility AI-usage: none Signed-off-by: Gabe Goodhart <ghart@us.ibm.com>
Member
Author
|
Looking over the code so far, I'm also going to add flexibility to the |
Branch: TLSConfigFlexibility AI-usage: full (OpenCode + Qwen3.6-35b) Signed-off-by: Gabe Goodhart <ghart@us.ibm.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR makes the TLS config surface more flexible in the following ways:
hostandclientprocesses) can load without needing access to the server's key/cert or the CA used to sign their credentialsremote-control init, the user can specify DNS names and IP addresses for the generated TLS credentialsAdditionally, the env var overrides for the trusted CAs have been clarified to avoid the ambiguity of
REMOTE_CONTROL_SERVER_CA(unclear if it's the CA that signed the server's cert or the CA the server should trust).Security
This PR makes it possible for the client processes to boot without needing to hold the keys to the server which makes security much stronger. The option to skip hostname verification slightly weakens security, but is common for using self-signed certs where the server will be accessed via a variable DNS lookup on a private LAN or VPN. The full cryptographic verification is still performed, so the only loss in security is the mitigation against Man-In-The-Middle attacks. This option should only be used on a trusted network that is itself secured against MitM.