File: internal/service/oauth_service.go (lines 24, 25, 26, 27, 28, 29, 30)
Project: tinyauth
Severity: BUG • Confidence: medium • Slug: insecure-crypto
Finding
NewOAuthService (lines 24-31) constructs an http.Client whose tls.Config explicitly sets InsecureSkipVerify from config.Insecure but does NOT set MinVersion. The peer LdapService (internal/service/ldap_service.go:114-122) sets MinVersion: tls.VersionTLS12 — so the codebase is inconsistent. When an admin sets Insecure=true for testing and forgets, or even when Insecure=false but the upstream OAuth provider negotiates a weak version, this transport will happily downgrade. Go's TLS dialer defaults are reasonable on modern versions, but explicit configs override the implicit floor in some flows — and there is no defense-in-depth here, while there is for LDAP.
Recommendation
Add MinVersion: tls.VersionTLS12 (or TLS13) to the tls.Config to match the LDAP service. Consider removing the configurable InsecureSkipVerify entirely or at least logging a loud warning at startup when it's enabled.
Revalidation
Verdict: true-positive
Confirmed structurally. NewOAuthService (lines 24-31) constructs a tls.Config with only InsecureSkipVerify set, while ldap_service.go:114-122 sets MinVersion: tls.VersionTLS12 explicitly — the codebases are inconsistent. However, the practical impact is limited: since Go 1.18, the standard library's default tls.Config MinVersion for clients is TLS 1.2, so absent an explicit downgrade (which this config does not do) the dialer will not negotiate <1.2 even without an explicit MinVersion. The recommendation (add MinVersion for defense-in-depth and consistency with LDAP) is reasonable, but MEDIUM overstates the severity in a modern Go runtime. Downgrading to BUG / hardening-grade is appropriate. The separate concern about InsecureSkipVerify is purely a configuration question — admins opt in deliberately.
File:
internal/service/oauth_service.go(lines 24, 25, 26, 27, 28, 29, 30)Project: tinyauth
Severity: BUG • Confidence: medium • Slug:
insecure-cryptoFinding
NewOAuthService (lines 24-31) constructs an http.Client whose tls.Config explicitly sets InsecureSkipVerify from config.Insecure but does NOT set MinVersion. The peer LdapService (internal/service/ldap_service.go:114-122) sets MinVersion: tls.VersionTLS12 — so the codebase is inconsistent. When an admin sets Insecure=true for testing and forgets, or even when Insecure=false but the upstream OAuth provider negotiates a weak version, this transport will happily downgrade. Go's TLS dialer defaults are reasonable on modern versions, but explicit configs override the implicit floor in some flows — and there is no defense-in-depth here, while there is for LDAP.
Recommendation
Add
MinVersion: tls.VersionTLS12(or TLS13) to the tls.Config to match the LDAP service. Consider removing the configurable InsecureSkipVerify entirely or at least logging a loud warning at startup when it's enabled.Revalidation
Verdict: true-positive
Confirmed structurally. NewOAuthService (lines 24-31) constructs a tls.Config with only InsecureSkipVerify set, while ldap_service.go:114-122 sets MinVersion: tls.VersionTLS12 explicitly — the codebases are inconsistent. However, the practical impact is limited: since Go 1.18, the standard library's default tls.Config MinVersion for clients is TLS 1.2, so absent an explicit downgrade (which this config does not do) the dialer will not negotiate <1.2 even without an explicit MinVersion. The recommendation (add MinVersion for defense-in-depth and consistency with LDAP) is reasonable, but MEDIUM overstates the severity in a modern Go runtime. Downgrading to BUG / hardening-grade is appropriate. The separate concern about InsecureSkipVerify is purely a configuration question — admins opt in deliberately.