fix(fxconfig)!: enable TLS by default to prevent plaintext fallback vulnerability

[MayankSharmaCSE]

Summary

Enable TLS by default across all service configurations (orderer, queries, notifications). Previously TLS was disabled by default.

Breaking Change

TLS is now enabled by default.

If you upgrade to this version and don't have TLS configured, you may see:
rootCertPaths must not be empty

New users must either:

• Configure TLS with rootCerts, or
• Explicitly set tls.enabled: false

Existing users can add tls.enabled: false to restore previous behavior.

Changes

• TLS now defaults to enabled: true instead of false
• Normalize() sets Enabled=true when nil
• TLS warning moved to config load time (single centralized warning instead of per-client)
• Integration tests updated with explicit tls.enabled: false (testcontainers use --insecure flag)
• Added assert.False message for Queries TLS assertion for consistency

Migration

Enable TLS (recommended for production):

tls:
  enabled: true
  rootCerts:
    - /path/to/ca.crt

Disable TLS (not recommended for production):
tls:
  enabled: false

Fixes #108
Test Plan

• Unit tests pass
• Integration tests pass

[Copilot]

Pull request overview

Enables TLS by default in fxconfig configurations to prevent insecure plaintext gRPC connections unless users explicitly opt out (tls.enabled: false), addressing the plaintext fallback vulnerability described in #108.

Changes:

• Flip TLS default to enabled via TLSConfig defaults and Normalize() behavior.
• Add a dedicated config-load unit test asserting TLS is enabled by default when unspecified; update existing tests and integration fixtures to explicitly disable TLS where needed.
• Add a centralized CLI warning when any service has TLS disabled; document the breaking change.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
tools/fxconfig/internal/config/config.go	Changes TLS default to enabled and normalizes missing enabled to true.
tools/fxconfig/internal/config/config_test.go	Updates normalization test expectations for the new TLS default.
tools/fxconfig/internal/config/load_test.go	Updates TLS flag tests and adds a new test asserting TLS is enabled by default.
tools/fxconfig/internal/cli/v1/root.go	Emits a centralized warning at config load time if any service has TLS disabled.
tools/fxconfig/integration/helpers_test.go	Updates generated integration configs to explicitly disable TLS.
tools/fxconfig/docs/README.md	Documents the breaking change (TLS enabled by default).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[pasquale95]

@MayankSharmaCSE @mbrandenburger Is there a specific reason to default to TLS enabled? Isn't it counterintuitive? I think about grpcurl or curl which by default run without TLS verification.
Also as Copilot indicated now basically the user will have a fail message by just running fxconfig because he has to define rootCerts as a mandatory field.

[MayankSharmaCSE]

@pasquale95 , i have few thoughts:

1. The decision to enable TLS by default follows security best practices. Tools like grpcurl/curl are general-purpose utilities that can work with or without TLS, but fxconfig manages Fabric-X infrastructure where security is critical. Making secure-by-default reduces the risk of misconfigurations in production.
2. Users will see rootCertPaths must not be empty if they don't configure TLS, which clearly signals they need to act. The fix is simple: add tls.enabled: false to restore the previous behavior, or configure proper TLS certificates.
3. Migration path - Existing users can simply add tls.enabled: false in their config to opt-out if they don't want TLS. The error message makes it obvious what needs to be fixed.

[mbrandenburger]

@MayankSharmaCSE @mbrandenburger Is there a specific reason to default to TLS enabled? Isn't it counterintuitive? I think about grpcurl or curl which by default run without TLS verification. Also as Copilot indicated now basically the user will have a fail message by just running fxconfig because he has to define rootCerts as a mandatory field.

@pasquale95 valid point. I strongly believe the TLS-enabled default is the right thing to move forward - however, it should be as easy as possible. What if we use the system root ca pool by default. If ca "custom" ca cert is needed; the corresponding error message will tell the user that ca server cert cannot be validated; hinting that custom certs can be set via rootCertPaths. If insecure operation mode is desired the user should just set tls.enabled = false.

WDYT?

[pasquale95]

@mbrandenburger I believe this is a good approach. If TLS is enabled by default, then at least we try to use the system root CA pool if rootCerts is undefined.