一、背景
公司有个黑盒监控拨测组件,类似可以通过各种协议如HTTP、TCP、ICMP等等针对目标主机、目标IP、目标站点进行定时拨测,通过返回的状态码等信息来推断,目标业务系统/主机、站点是否存在异常,健康情况如何。
最近在配置一个HTTPS的拨测任务,就遇到了比较奇怪的现象。 之前拨测的HTTPS站点都是OK的,但是这个站点死活报错。报错信息如下:
tls: no supported version satisfy MinVersion and MaxVersion
程序是使用Golang写的。根据关键词提示,应该是TLS这块出现了问题。所以我针对这个情况进行了一下分析
二、分析过程
1、首先使用curl针对不同版本TLS进行探测,是否能正常访问
curl可以使用--tls1.0 、--tls1.1、--tls1.2 参数强制https请求使用对应的TLS版本。
从图中可以看到,这个站点比较特殊,可能是年代比较久远,签发的SSL证书只支持TLS1.0版本进行访问,其它版本无法建立SSL握手,否则报错。
由此断定,应该是我们程序出错了,毕竟curl使用--tls1.0没有报错,可以正常访问。
2、查看Golang源码关于tls.Config这个结构体的参数配置
根据错误信息提示"tls: no supported version satisfy MinVersion and MaxVersion", 我找到了golang的tls.Config这个结构体,同时看到了MaxVersion和MinVersion这2个属性。
这2个属性框定了,和HTTPS站点交互使用的TLS版本的范围。 并且MinVersion总是小于等于MaxVersion的.
注意: MinVersion默认是TLS1.2, 这里就是今天主角的坑点!!!!
查了下资料,Golang在不同版本,给MinVersion设置的默认值不一样。早期比较旧的Golang版本默认是TLS1.0, 后面的高版本就是TLS1.2了
3、验证下是否是因为MaxVersion、MinVersion设置错误导致的
Go
func TestTls(t *testing.T) {
tlsConfig := &tls.Config{
MinVersion: tls.VersionTLS10,
MaxVersion: tls.VersionTLS10,
}
// 使用自定义的 TLS 配置创建一个 HTTP 客户端
client := &http.Client{
Transport: &http.Transport{
TLSClientConfig: tlsConfig,
},
}
// 发送一个 GET 请求
resp, err := client.Get("https://www.baidu.com")
if err != nil {
fmt.Println("Error:", err)
return
}
defer resp.Body.Close()
// 打印响应状态码
fmt.Println("Response Status:", resp.Status)
}
1、首先,直接设置Maxversion为TLS1.0,符合我们程序的逻辑思路. MinVersion采用默认值
报错信息和文章开头的一模一样,果然没错!就是这个原因导致的。 MinVersion(TLS1.2)竟然大于了MaxVersion(TLS1.0), 不报错才怪。
2、那我再来验证,MinVersion到底是不是TLS1.2呢? 很简单,我直接把MinVersion设置为TLS1.0,看下代码还会报错吗?
明显,现在MinVersion <= MaxVersion, 逻辑正确, 代码也正常通过测试。 说明MinVersion默认就是TLS1.2
三、总结
关于tls.Config的MinVersion属性,我的修复建议就是强制写死默认最小版本是TLS1.0,不要依赖Golang给你设置MinVersion的值。 要不然就会造成上面我的这种情况,十分坑爹!
如果你设置的MinVersion是TLS1.0,MaxVersion怎么设置都不会报错的。因为至少MaxVersion都是TLS1.0了,还是满足条件: MinVersion <= MaxVersion