Introducing configurable setting for min tls version#199
Introducing configurable setting for min tls version#199pebanb wants to merge 2 commits intobasecamp:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds an (intended) configuration option to require TLS 1.3 as the minimum TLS version for the HTTPS server, while preserving existing TLS/ALPN configuration.
Changes:
- Add
OnlyTLS1_3tointernal/server.Configto control whether HTTPS enforcesMinVersion = tls.VersionTLS13. - Refactor HTTPS server initialization to reuse a
tls.Configinstance and conditionally setMinVersion.
Tip
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| internal/server/server.go | Creates a reusable TLS config for the HTTPS server and conditionally enforces TLS 1.3 minimum. |
| internal/server/config.go | Adds a new config field meant to control the TLS 1.3 minimum-version behavior. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
898c406 to
627aded
Compare
627aded to
6d6be08
Compare
|
@pebanb my mr just makes implicit explicit, no change in behavior, the same was done for http3. in your case I would add a |
hi @AnyCPU the standard existing behavior is kept, it's just possible to force tls 1.3 by a configuration if required for some application, which require to enforce only new ciphers. |
|
@pebanb I know I saw the source code, in more generic case
from dev/ux it is easier to remember a |
There was a problem hiding this comment.
Pull request overview
Adds a configurable minimum TLS version for the HTTPS (h1/h2) server, wiring it through CLI/env config and extending tests to cover the new option.
Tip
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.
Changes:
- Introduce
Config.MinTLSand a--min-tls/MIN_TLSconfiguration path. - Apply the configured TLS minimum version to the HTTPS server’s
tls.Config. - Extend HTTPS deployment tests with new subtests for various minimum TLS values.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| internal/server/testing.go | Extends the test server helper to pass through MinTLS config. |
| internal/server/server_test.go | Adds subtests intended to validate different configured minimum TLS versions. |
| internal/server/server.go | Builds an HTTPS tls.Config with MinVersion based on config (and errors on invalid values). |
| internal/server/config.go | Adds MinTLS to server configuration struct. |
| internal/cmd/util.go | Adds getEnvString helper for string-valued env configuration. |
| internal/cmd/run.go | Adds --min-tls flag (and MIN_TLS env support) to populate Config.MinTLS. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| require.NoError(t, err) | ||
| assert.Equal(t, http.StatusOK, resp.StatusCode) | ||
| assert.Equal(t, "HTTP/1.1", resp.Proto) | ||
| assert.GreaterOrEqual(t, resp.TLS.Version, uint16(tls.VersionTLS10)) | ||
| }) |
There was a problem hiding this comment.
The new min-TLS subtests don't actually verify that the server enforces the configured minimum: asserting resp.TLS.Version >= TLS1.0/1.1/1.2 will pass even if the server ignores MinTLS (because the negotiated version is commonly higher anyway). Consider asserting the server's configured MinVersion directly (tests are in the same package, so you can read server.httpsServer.TLSConfig.MinVersion), and/or add a negative handshake test by forcing the client MaxVersion below the configured minimum and asserting the request fails.
| case "tls1_3": | ||
| tlsConfig.MinVersion = tls.VersionTLS13 | ||
| case "": | ||
| // No minimum TLS version set |
There was a problem hiding this comment.
When MinTLS is empty, the HTTPS server TLS config leaves MinVersion unset. That means the effective minimum is Go's runtime default, which can be changed by environment/runtime settings and may not meet the PR's stated goal of hardening the server. If the intent is to be secure by default, consider setting an explicit default minimum (e.g., TLS 1.2) when MinTLS is not provided, and reserve an explicit opt-out value if you need to preserve legacy behavior.
| // No minimum TLS version set | |
| // Default to a secure minimum TLS version when not explicitly configured. | |
| tlsConfig.MinVersion = tls.VersionTLS12 |
There was a problem hiding this comment.
default and empty case should use tls 1.2 because Go does it implicitly at the moment.
| default: | ||
| return fmt.Errorf("unsupported minimum TLS version: %q (use tls1_0, tls1_1, tls1_2, or tls1_3)", s.config.MinTLS) | ||
| } |
There was a problem hiding this comment.
The new error branch for unsupported MinTLS values is user-facing behavior but isn't covered by tests. Adding a small test that sets Config.MinTLS to an invalid value and asserts Server.Start() fails with this error would help prevent regressions (especially since the flag/env input is free-form).
hi, introduced configurable min tls version, now you can set each version you need :) |
Introducing TLS 1.3 as a config flag for more secure server.
An improvement vs #190
Adding also test coverage for the new feature.