SSL 错误的解决方法
我正在连接的 https 服务器的 SSL 实现中似乎存在错误； 问题最初出现在我的应用程序中，但我一直在使用 openssl 命令行实用程序调试/重现它，所以我相当确定此时它与我的应用程序无关。
如果我使用 -connect 以外的其他选项连接到远程服务器，OpenSSL 会发送 SSLv2 CLIENT-HELLO，服务器会响应 TLSv1 ServerHello，一切都会正常进行。
如果我使用 -ssl3 连接，OpenSSL 会发送 SSLv3 ClientHello，服务器会使用 SSLv3 ServerHello 进行响应，一切都很好。
但是，如果我使用 -no_ssl2 或 -tls1 连接，OpenSSL 会发送 TLSv1 ClientHello，并且服务器会响应 "TLS 1.0 Alert [length 0002], fatal unexpected_message”，这是我在应用程序中看到的原始问题。
此时有许多可能的解决方法，但我理想地寻找通用的东西，而不是特殊的这个特定服务器，所以我希望有某种“标准”的解决方法。
There seems to be a bug in the SSL implementation of an https server I'm connecting to; the problem initially arose in my application, but I've since been debugging / reproducing it with the openssl commandline utility, so I'm fairly certain it has nothing to do with my application at this point.
If I connect to the remote server with no options other than -connect, OpenSSL sends an SSLv2 CLIENT-HELLO, the server responds with a TLSv1 ServerHello, and everything proceeds normally.
If I connect with -ssl3, OpenSSL sends an SSLv3 ClientHello, the server responds with an SSLv3 ServerHello, and again everything is fine.
However, if I connect with -no_ssl2 or -tls1, OpenSSL sends a TLSv1 ClientHello, and the server responds with "TLS 1.0 Alert [length 0002], fatal unexpected_message", which is the original problem I was seeing in my application.
There are a number of possible workarounds that suggest themselves at this point, but I'm ideally looking for something generic, rather than special-casing this particular server, so I'm hoping there's some kind of "standard" workaround for this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
看来问题实际上是由 RFC 5077 会话票证扩展引起的； 禁用此功能（例如，通过将
-no_ticket传递给 openssl）允许 TLSv1 ClientHello 与远程服务器成功。 由于我的应用程序中没有特别需要此扩展，因此此解决方法似乎是最合适的继续方法。一些研究表明问题可能只是空会话票证扩展，但我没有费心去尝试找出该特定服务器是否存在非空会话票证问题。
It seems the problem was actually caused by the RFC 5077 session ticket extension; disabling this (by passing
-no_ticketto openssl, for example) allowed the TLSv1 ClientHello to succeed with the remote server. Since I have no particular need for this extension in my application, this workaround seems like the most appropriate way to proceed.A little research suggests that the problem may just be empty session ticket extensions, but I didn't bother trying to figure out whether this particular server had problems with non-empty ones.