https://zinyan.com/?p=453
1. 介绍
我通过https://zinyan.com/?p=450#3.1-error%E9%94%99%E8%AF%AF 中的方法，修复了我的Error日志中大量的[warn]警告之后。
现在error.log文件的大小由原先的最大700kb，直接减少为300Bytes内容了。
可以说，有效的减少了error错误日志的文件大小。
而现在比较多的内容就是：SSL_do_handshake() failed (SSL: **error:**141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking异常了。
示例如下：
2022/11/20 09:06:45 [crit] 2314826#2314826: *1894679 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 104.131.181.99, server: 0.0.0.0:443
2022/11/20 13:33:53 [crit] 2314826#2314826: *1900198 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 146.190.18.122, server: 0.0.0.0:443
2022/11/20 16:14:46 [crit] 2314826#2314826: *1903204 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 87.236.176.8, server: 0.0.0.0:443
2022/11/20 17:50:51 [crit] 2314826#2314826: *1905328 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 184.105.247.228, server: 0.0.0.0:443
2022/11/20 21:06:42 [crit] 2314826#2314826: *1910105 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 212.102.40.218, server: 0.0.0.0:443
2022/11/21 01:05:20 [crit] 2314826#2314826: *1915544 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 198.20.87.98, server: 0.0.0.0:443
2022/11/21 18:39:59 [crit] 2335881#2335881: *1948773 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 103.213.96.233, server: 0.0.0.0:443
2022/11/21 21:14:07 [crit] 2335881#2335881: *1953570 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 212.102.40.218, server: 0.0.0.0:443
2022/11/22 00:18:20 [crit] 2335881#2335881: *1957927 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 74.82.47.33, server: 0.0.0.0:443
2022/11/22 00:41:56 [crit] 2335881#2335881: *1958315 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 152.32.241.234, server: 0.0.0.0:443
2022/11/22 04:39:15 [crit] 2335881#2335881: *1960441 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 192.241.201.18, server: 0.0.0.0:443
每天总是会有几个请求提示这个错误。那么这个错误是什么？我们的nginx有问题么？
2. 分析
我们将错误内容进行一个分解理解。
SSL_do_handshake() failed : SSL握手失败。那么ssl握手是什么？简单理解就是https的证书认证过程。确保网站内容请求和发送的数据是没有被串改的。
SSL: error:141CF06C：ssl的错误码是 141CF06C
SSL routines:tls_parse_ctos_key_share：错误发生在SSL链接顺序中的tls_parse_ctos_key_share验证阶段，客户端验证秘钥是否正确的阶段。
验证得到的结果是：bad key share 秘钥错误。
然后整个SSL握手就失败了。
最后client：客户端请求的IP地址。 server：服务器端的ip地址。
我们将问题一点点拆分之后。就需要研判了。SSL证书为什么会错误？
我们的httpsSSL证书配置不准确，证书有问题。
客户端访问时得到的SSL证书有串改。
那么，这个问题是发生在客户端还是发生在服务端？
很简单，检测你的错误日志是否非常多的[crit]异常。我们使用多个不同的浏览器访问我们网站是否会出现SSL错误。
如果不是，那么就说明访问客户端出现了问题。
PS 1：例如我的每天500个IP访问，只有4~5个出现了crit异常。
说明是客户端请求的问题。
2.1 客户端
如果是客户端出现了问题。那么客户端哪种情况会出现这些异常？通过搜索相关资料得知有以下多种情况会出现客户端证书错误异常：
客户端运行的浏览器严重过时了。老版本浏览器中对SSL证书的验证签名不通过。（几率比较低）
客户端是一个攻击软件，它在使用软件扫描服务器的漏洞。
客户端所在的网络，有严格的防火墙机制。限制了网站正确被访问。（可以参考国内网络屏蔽国外网站。）
上面的第1和第3的情况我们无法解决。而第2种情况，代表了我们的服务器正在受到漏洞扫描攻击。
可以评判多个ip的访问重复情况。进行合理的屏蔽就可以了。
3. ip公布
公布一些频繁访问我的网站，然后出现SSL错误的ip地址。给小伙伴们一些参考。
后面的（+1）只是代表访问的次数。统计范围为：2022-11-01 至 2022-11-22 日
24.199.91.105 美国纽约 Twcc
35.203.251.56 美国 谷歌云
35.216.204.3 瑞士苏黎世 谷歌云
35.216.240.37 瑞士苏黎世 谷歌云
35.216.244.6 瑞士苏黎世 谷歌云
39.98.50.238 北京市北京 阿里云
43.134.234.251 新加坡 腾讯云
43.153.208.98 新加坡 腾讯云
43.158.217.205 印度马哈拉施特拉孟买 腾讯云
43.158.214.10 印度马哈拉施特拉孟买 腾讯云
45.55.61.251 美国纽约
47.92.83.245 北京市北京 阿里云
47.92.105.157 北京市北京 阿里云
47.92.154.94 北京市北京 阿里云
47.92.163.190 北京市北京 阿里云
47.92.195.28 北京市北京 阿里云
47.92.248.176 北京市北京 阿里云
51.159.99.253 法国巴黎（+1）
64.62.197.9 美国加利福尼亚费利蒙
64.62.197.30 美国加利福尼亚费利蒙
64.62.197.120 美国加利福尼亚费利蒙
64.62.197.134 美国加利福尼亚费利蒙
64.62.197.212 美国加利福尼亚费利蒙
65.49.20.121 美国加利福尼亚费利蒙
66.175.213.4 美国新泽西纽瓦克
68.183.65.135 德国黑森法兰克福
71.6.135.131 美国加利福尼亚圣地亚哥
74.82.47.6 美国加利福尼亚费利蒙
74.82.47.30 美国加利福尼亚费利蒙
74.82.47.33 美国加利福尼亚费利蒙
74.82.47.39 美国加利福尼亚费利蒙
81.70.9.83 北京市北京 腾讯云
87.236.176.8 英国英格兰利兹
87.236.176.24 英国英格兰利兹
87.236.176.39 英国英格兰利兹
87.236.176.60 英国英格兰利兹
87.236.176.98 英国英格兰利兹
87.236.176.193 英国英格兰利兹
87.236.176.239 英国英格兰利兹
94.102.49.193 荷兰北荷兰省
95.168.170.166 荷兰北荷兰省哈勒姆 Leaseweb
103.213.96.233 江苏省常州市 电信&联通&移动（+7）
104.131.181.99 美国纽约（+1）
104.152.52.108 美国伊利诺斯芝加哥
104.152.52.118 美国伊利诺斯芝加哥
104.152.52.180 美国伊利诺斯芝加哥
104.152.52.230 美国伊利诺斯芝加哥
104.152.52.212 美国伊利诺斯芝加哥
104.152.52.215 美国伊利诺斯芝加哥
104.218.164.191 英国英格兰伦敦 优刻云
106.75.36.68 北京市北京 优刻云
106.75.133.83 广东省广州市 优刻云
106.75.135.102 广东省广州市 优刻云
106.75.148.44 广东省广州市 优刻云
106.75.165.127 广东省广州市 优刻云
107.178.237.22 美国爱荷华康瑟尔布拉夫斯 谷歌云
117.187.173.111 贵州省毕节市 移动
134.122.112.12 美国纽约纽约市
134.209.148.53 印度卡纳塔克班加罗尔
138.68.174.35 英国英格兰伦敦
138.197.172.30 加拿大安大略多伦多
139.59.27.34 印度卡纳塔克班加罗尔
142.93.68.52 美国纽约纽约市
143.110.243.143 印度卡纳塔克班加罗尔
143.198.4.69 美国新泽西
146.190.18.122 荷兰北荷兰省阿姆斯特丹
146.190.226.143 荷兰北荷兰省阿姆斯特丹
152.32.171.91 香港 优刻云
152.32.201.23 日本东京 优刻云
152.32.241.234 菲律宾马尼拉 优刻云
154.89.5.73 香港 Cloudinnovation
154.89.5.76 香港 Cloudinnovation
154.89.5.99 香港 Cloudinnovation（+1）
154.89.5.120 香港 Cloudinnovation（+1）
154.89.5.207 香港 Cloudinnovation
157.245.111.127 印度卡纳塔克班加罗尔
157.245.113.97 美国
159.89.15.187 德国黑森法兰克福
159.89.172.170 印度卡纳塔克班加罗尔
159.89.182.60 美国纽约（+4）
159.223.21.247 德国黑森法兰克福
159.223.102.149 美国新泽西锡考克斯
161.35.40.254 英国英格兰伦敦
161.35.86.181 荷兰北荷兰省阿姆斯特丹
161.35.161.86 英国英格兰伦敦
161.35.188.242 美国纽约纽约市
161.35.198.183 德国黑森法兰克福
162.142.125.210 美国伊利诺斯芝加哥
165.22.24.54 德国黑森法兰克福
165.227.76.114 美国纽约
167.71.230.161 美国纽约纽约市
167.71.254.0 美国纽约纽约市
167.99.2.61 美国纽约
167.99.58.120 美国纽约
167.172.63.149 英国英格兰伦敦
167.172.240.54 美国纽约（+1）
178.62.227.225 荷兰
178.128.80.176 新加坡
184.105.139.121 美国加利福尼亚费利蒙
184.105.139.117 美国加利福尼亚费利蒙
184.105.247.219 美国加利福尼亚费利蒙
184.105.247.228 美国加利福尼亚费利蒙
184.105.247.235 美国加利福尼亚费利蒙
185.142.236.43 荷兰北荷兰省阿姆斯特丹
198.199.93.54 美国加利福尼亚旧金山
192.241.201.18 美国加利福尼亚旧金山
192.241.201.23 美国加利福尼亚旧金山
192.241.201.104 美国加利福尼亚旧金山
192.241.202.99 美国加利福尼亚旧金山
192.241.203.236 美国加利福尼亚旧金山
192.241.206.119 美国加利福尼亚旧金山
192.241.206.199 美国加利福尼亚旧金山
192.241.210.142 美国加利福尼亚旧金山
192.241.210.229 美国加利福尼亚旧金山
192.241.212.172 美国加利福尼亚旧金山
192.241.213.49 美国加利福尼亚旧金山
192.241.213.124 美国加利福尼亚旧金山
198.20.87.98 美国伊利诺斯芝加哥
198.199.94.93 美国加利福尼亚旧金山
198.199.94.79 美国加利福尼亚旧金山
198.199.119.138 美国加利福尼亚旧金山
207.154.219.163 德国黑森法兰克福
212.102.40.218 美国德克萨斯达拉斯（+14）
216.218.206.69 美国加利福尼亚费利蒙
216.218.206.72 美国加利福尼亚费利蒙
216.218.206.83 美国加利福尼亚费利蒙
216.218.206.114 美国加利福尼亚费利蒙
216.218.206.123 美国加利福尼亚费利蒙
223.111.175.68 江苏省泰州市 移动
以上ip是否有风险，请自行判断。这里只是做数据汇总。
没有想到，服务器这么受国外网站的青睐啊。
该屏蔽屏蔽，该限制限制。可以通过阿里云服务器的安全组设置（如果你是其他服务器，也有相关安全组）。也可以通过nginx 进行ip屏蔽。
例如我把下面的一些ip请求进行了屏蔽：
212.102.40.218
216.218.206.0/24
198.199.94.0/24
192.241.201.0/24
192.241.206.0/24
192.241.210.0/24
167.172.240.54
159.89.182.60
154.89.5.0/24
104.152.52.0/24
103.213.96.233
104.131.181.99
87.236.176.0/24
74.82.47.0/24
64.62.197.0/24
51.159.99.253
0/24 的作用是指 0-255。例如：74.82.47.0/24 就代表屏蔽了74.82.47.0~255 范围内的所有ip地址。
4. 结论
最后，让我们回到这个问题本身来。如果部分IP一直访问触发这个错误，那么可以屏蔽该IP的访问。
不进行处理也不影响我们的正确使用。
====================================
文章作者： Z同学
文章来源： Z同学
文章链接： https://zinyan.com/?p=453
版权声明： 内容遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
