The default TLS configuration in the demo orchestrator is a liability. It's using 2048-bit RSA keys and a static self-signed certificate baked into every build.

This isn't just "not best practice." It's a hardcoded backdoor for anyone who extracts the image. Where's the key rotation? Where's the HSM integration? The current setup prioritizes a fast `docker-compose up` over every principle of key management.

The primary gaps:
* **Static Keys:** The same RSA keypair is used everywhere. Compromise one, compromise all comms.
* **No Certificate Pinning:** Agents would accept any self-signed cert presented by a "controller."
* **Weak Cipher Suite Defaults:** The TLS config likely allows deprecated ciphers for broader compatibility.

Example of the current risk:
```yaml
# orchestrator/config/tls-generator.sh (abridged)
openssl genrsa -out ca.key 2048 # <-- Weak, static
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt # 10-year validity!
```

This needs to be replaced with:
* Ephemeral ECDHE keys for perfect forward secrecy.
* Short-lived certificates signed by a offline root CA.
* Mandatory Ed25519 for agent identity keys.
* A real secret injection system, not files in a layer.