Repository navigation
False positive: go/insecure-tls is partially wrong #23058
Description
Description of the false positive
The example of go/insecure-tls states that MinVersion = 0 for tls.Config means "lowest supported version", this is wrong.
func insecureMinMaxTlsVersion() {
{
config := &tls.Config{}
config.MinVersion = 0 // BAD: Setting the MinVersion to 0 equals to choosing the lowest supported version (i.e. SSL3.0)
}According to the go docs:
MinVersioncontains the minimum TLS version that is acceptable.By default, TLS 1.2 is currently used as the minimum. TLS 1.0 is the
minimum supported by this package.
Code samples or links to source code
TLSClientConfig: &tls.Config{
MinVersion: 0,
}See https://github.com/phil9909/codeql-bug-repoducer for code, see this GitHub Action Output for proof that TLSv1.1 is rejected.
URL to the alert on GitHub code scanning (optional)
In the reproducer repo: https://github.com/phil9909/codeql-bug-repoducer/security/code-scanning/1
In OpenBao: https://github.com/openbao/openbao/security/code-scanning/1159
Activity
mbg commentedon Nov 9, 2026
Hi @phil9909,
Thanks for the report. I see where you are coming from, but I am wondering if the main issue highlighted by the query here is more the reliance on a default than what that actual default is. In other words, by setting
MinVersion: 0, you rely on the library to pick a secure minimum version. That may be the case at a given point in time and/or for a particular version of the library, but may not be true for arbitrary versions of the library or at a future point in time. In general, our queries don't implement different behaviours based on different versions of a given library.I'll pass this on to the team that looks after the queries for Go though to see if this is the intended behaviour of this query or something they want to look at changing / improving going forward.
[-]False positive: `go/insecure-tls` is paritally wrong[/-][+]False positive: `go/insecure-tls` is partially wrong[/+]phil9909 commentedon Nov 10, 2026
Thanks for the quick reply.
Fair, but some toughs on this:
"the library" in this case is the go standard library, not some random library. IMHO, if you control both ends of the communication (i.e. internal service to service communication) increasing the
MinVersionto "newest supported by both services" might make sense (today probably TLS 1.3), but in many cases you don't (because of talking to a third party service) for most projects it makes sense to stick with the Go default minimum version here, it balances security and compatibility and will be updated regularly. If you set a minimum today, you take on the responsibility of maintaining this, something that is forgotten easily (and I don't think relaying on CodeQL to periodically flag this is a good idea).In Go this
and this
is equivalent, because
MinVersionis auint16and the "empty value" is0. But the later is not flagged by CodeQL: https://github.com/phil9909/codeql-bug-repoducer/pull/1/filesEither flag both or neither.
If you still want to flag this, I'd argue this is a different less severe problem compared to actually setting a version which is known to be insecure today.
Happy to hear the opinion of your Go experts.
owen-mc commentedon Nov 10, 2026
Thanks for reporting this. I agree it should be fixed. I will put up a PR.
owen-mc commentedon Nov 11, 2026
#23080