Enabling TLS on a NATS instance appears to remove plaintext access rather than add TLS alongside it, and TLS is enabled implicitly from external — so publishing an instance externally can sever existing plaintext clients on the next reconcile.
Two parts, both in packages/apps/nats:
tls.enabled, when unset, defaults to the value of external (templates/_tls.tpl). An instance that is switched to external: true — or one that already is — therefore gets TLS without anyone asking for it.- The rendered server config sets TLS on the client port and never sets
allow_non_tls. In NATS that makes port 4222 TLS-only: plaintext clients are not served on a second port, they simply stop connecting.
The consequence is the combination: a change that reads as "publish this instance" also changes the wire protocol for every existing client, with no opt-out short of setting tls.enabled: false before the reconcile.
Confidence and what has not been checked. This is read off the chart and the NATS server's documented behaviour for a tls block without allow_non_tls — it has not been reproduced against a running instance. Before acting on it, someone should confirm on a live instance that a plaintext client is in fact refused once TLS is on. If NATS is serving both somehow, only the implicit-enable half of this stands.
For comparison, the same implicit-enable pattern was recently reconsidered for another engine: where TLS replaces plaintext rather than adding to it, the enablement was made an explicit opt-in precisely so that an upgrade cannot cut live connections. The question here is whether NATS should follow, or whether keeping plaintext available (allow_non_tls) alongside TLS is the better shape.
Enabling TLS on a NATS instance appears to remove plaintext access rather than add TLS alongside it, and TLS is enabled implicitly from
external— so publishing an instance externally can sever existing plaintext clients on the next reconcile.Two parts, both in
packages/apps/nats:tls.enabled, when unset, defaults to the value ofexternal(templates/_tls.tpl). An instance that is switched toexternal: true— or one that already is — therefore gets TLS without anyone asking for it.allow_non_tls. In NATS that makes port 4222 TLS-only: plaintext clients are not served on a second port, they simply stop connecting.The consequence is the combination: a change that reads as "publish this instance" also changes the wire protocol for every existing client, with no opt-out short of setting
tls.enabled: falsebefore the reconcile.Confidence and what has not been checked. This is read off the chart and the NATS server's documented behaviour for a
tlsblock withoutallow_non_tls— it has not been reproduced against a running instance. Before acting on it, someone should confirm on a live instance that a plaintext client is in fact refused once TLS is on. If NATS is serving both somehow, only the implicit-enable half of this stands.For comparison, the same implicit-enable pattern was recently reconsidered for another engine: where TLS replaces plaintext rather than adding to it, the enablement was made an explicit opt-in precisely so that an upgrade cannot cut live connections. The question here is whether NATS should follow, or whether keeping plaintext available (
allow_non_tls) alongside TLS is the better shape.