TLS certificate verification: opt-in security to preserve backward compatibility

[Copilot]

Addresses concerns about breaking production deployments with TLS changes. Default behavior remains InsecureSkipVerify: true to prevent rollout failures across distributed systems with self-signed certs or mixed CA trust.

Changes

• Default behavior: Unchanged (InsecureSkipVerify: true) for backward compatibility
• Opt-in security: MICRO_TLS_SECURE=true environment variable enables certificate verification
• Deprecation warning: Single log message on startup guides migration to v6
• Documentation: Migration guide covering multi-host deployments and certificate management

Usage

// Default (backward compatible, insecure)
broker := broker.NewHttpBroker()
// Logs: [SECURITY WARNING] TLS certificate verification is disabled...

// Opt-in secure mode
os.Setenv("MICRO_TLS_SECURE", "true")
broker := broker.NewHttpBroker()
// Certificate verification enabled

// Explicit secure config
broker := broker.NewHttpBroker(
    broker.TLSConfig(mls.SecureConfig()),
)

Rationale

• No major version bump: Breaking change deferred to v6
• Cross-host safety: All nodes use identical insecure default, avoiding CA trust issues during rollout
• Production rollout: Zero coordination required for version upgrades; security enabled per-service
• Migration path: Users adopt security incrementally before v6 makes it default

See docs/SECURITY_MIGRATION.md for deployment strategies.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[FEATURE] Insecure TLS Configuration: Skipping Certificate Verification</issue_title>
<issue_description>Is your feature request related to a problem? Please describe.
In the go-micro package, specifically in the file github.com/go-micro/go-micro/broker/http.go at line 84 within the newTransport function, there is a default configuration that skips TLS certificate verification. This behavior poses a serious security risk because it disables the mechanism that ensures the authenticity and integrity of the TLS connection. Without certificate verification, man-in-the-middle attacks become possible, allowing attackers to intercept, modify, or steal data transmitted over the network.

Describe the solution you'd like
To mitigate this security vulnerability, I propose updating the default TLS configuration to enforce certificate verification. This can be achieved by configuring the tls.Config object to include a valid RootCAs pool or by setting the InsecureSkipVerify flag to false, which is its default value. Doing so will ensure that connections are established only with servers presenting trusted certificates, enhancing the overall security posture of the application.

Additional context
It is crucial to consider the implications of disabling certificate verification in production environments. While it might simplify development or testing scenarios, it should never be enabled in any environment where sensitive data is handled. To address this issue properly, the default configuration should be updated to enforce certificate verification, and developers should be provided with clear documentation on how to configure exceptions for testing purposes only.
</issue_description>

<agent_instructions>Is this something we reliably do without breakages? </agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes [FEATURE] Insecure TLS Configuration: Skipping Certificate Verification #2713

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.