诡异的ERR_SSL_PROTOCOL_ERROR

发布网友 发布时间：2024-09-26 04:17

我来回答

共1个回答

热心网友 时间：2024-10-05 00:31

面对同事反馈的公司部分网站无法正常打开，页面显示ERR_SSL_PROTOCOL_ERROR的异常情况，我起初判断为短暂的网络故障或缓存问题，但实际情况远比预期复杂。

同事试了多种方法，问题依旧未能解决，且问题似乎在多个同事中普遍出现，分析发现，问题表现存在不少诡异之处。考虑到大多数用户推荐使用体验良好的Chrome浏览器访问网站，我们首先并未怀疑Chrome，尽管问题仅在Chrome中出现。尝试清除浏览器缓存、SSL状态，更换SSL证书后，问题依然存在。

在尝试各种方法无果后，我们开始聚焦于Chrome。通过向Chrome反馈问题，虽然未得到回复，但通过Chromium官方的bug跟踪平台搜索ERR_SSL_PROTOCOL_ERROR，我们发现有用户也遇到了相同的问题，且问题出现时间恰好与我们的反馈时间吻合。进一步阅读相关帖子后，我们揭示了问题背后的真相。

9月28日，Chromium发布了一项部署，其标题为Disable SHA1 in TLS server handshakes by default，即默认禁用TLS握手时的SHA1加密方法。这一发布本身是正常且正确的，因为SHA1已被公认为不安全。然而，问题在于存在使用低版本OpenSSL的一些老旧系统，这些系统会强制使用SHA1。这就是问题发生的巧合与蝴蝶效应。

了解问题原因后，我们找到了解决办法。首先，可以通过chrome://flags/#use-sha1-server-handshakes修改Chrome的默认选项为Enabled，这样可以确保浏览器正常访问。然而，这方法对客户来说操作复杂，且使用SHA1加密不安全。因此，最佳解决方案是更新服务端的OpenSSL版本。以我们的服务器为例，将版本从1.0.1升级到1.1.1后，问题得到解决。

需要注意的是，若网站使用了Nginx部署，可通过nginx -V检查依赖的OpenSSL版本。若版本过低，需要通过重新编译Nginx使用新版本的OpenSSL进行替代升级。具体的步骤可在网上查找，这里不详述。

至此，问题得到妥善解决。总结经验教训，我们意识到更新依赖组件和关注安全更新的重要性，同时也强调了维护用户访问体验的连贯性和安全性。

热心网友 时间：2024-10-05 00:30

面对同事反馈的公司部分网站无法正常打开，页面显示ERR_SSL_PROTOCOL_ERROR的异常情况，我起初判断为短暂的网络故障或缓存问题，但实际情况远比预期复杂。

同事试了多种方法，问题依旧未能解决，且问题似乎在多个同事中普遍出现，分析发现，问题表现存在不少诡异之处。考虑到大多数用户推荐使用体验良好的Chrome浏览器访问网站，我们首先并未怀疑Chrome，尽管问题仅在Chrome中出现。尝试清除浏览器缓存、SSL状态，更换SSL证书后，问题依然存在。

在尝试各种方法无果后，我们开始聚焦于Chrome。通过向Chrome反馈问题，虽然未得到回复，但通过Chromium官方的bug跟踪平台搜索ERR_SSL_PROTOCOL_ERROR，我们发现有用户也遇到了相同的问题，且问题出现时间恰好与我们的反馈时间吻合。进一步阅读相关帖子后，我们揭示了问题背后的真相。

9月28日，Chromium发布了一项部署，其标题为Disable SHA1 in TLS server handshakes by default，即默认禁用TLS握手时的SHA1加密方法。这一发布本身是正常且正确的，因为SHA1已被公认为不安全。然而，问题在于存在使用低版本OpenSSL的一些老旧系统，这些系统会强制使用SHA1。这就是问题发生的巧合与蝴蝶效应。

了解问题原因后，我们找到了解决办法。首先，可以通过chrome://flags/#use-sha1-server-handshakes修改Chrome的默认选项为Enabled，这样可以确保浏览器正常访问。然而，这方法对客户来说操作复杂，且使用SHA1加密不安全。因此，最佳解决方案是更新服务端的OpenSSL版本。以我们的服务器为例，将版本从1.0.1升级到1.1.1后，问题得到解决。

需要注意的是，若网站使用了Nginx部署，可通过nginx -V检查依赖的OpenSSL版本。若版本过低，需要通过重新编译Nginx使用新版本的OpenSSL进行替代升级。具体的步骤可在网上查找，这里不详述。

至此，问题得到妥善解决。总结经验教训，我们意识到更新依赖组件和关注安全更新的重要性，同时也强调了维护用户访问体验的连贯性和安全性。