.NET SslStream 无法正确关闭 TLS 连接
.NET 的 SslStream
类在关闭连接之前不会发送 close_notify
警报。
如何手动发送 close_notify
警报?
.NET's SslStream
class does not send the close_notify
alert before closing the connection.
How can I send the close_notify
alert manually?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
谢谢你提出这个问题。 它为我指明了正确的方向,.Net 中存在一个错误,而我并不经常考虑这个错误。
我在编写 FTPS 服务器实现时遇到了这个问题,Filezilla(或可能是 GnuTLS)客户端抱怨“gnutls_record_recv 中的 GnuTLS 错误 -110:TLS 连接未正确终止”。 我认为这是 SslStream 实现中的一个相当重要的缺点。
因此,我最终编写了一个包装器,在关闭流之前发送此警报:
下面的代码是让它工作(此代码要求程序集“不安全”):
使用的 Windows API:
反射实用程序:
我没有经验编写与非托管环境的可靠交互,因此我希望有人可以查看并解决问题(也许可以使其“安全”)。
Thanks for this question. It pointed me into the right direction, that there is a bug in .Net, which I do not very often think about.
I bumped into this problem during writing of my implementation of FTPS server and Filezilla (or GnuTLS probably) client was complaining "GnuTLS error -110 in gnutls_record_recv: The TLS connection was non-properly terminated". I think it is a quite significant drawback in SslStream implementation.
So I ended up with writing a wrapper which sends this alert before closing the stream:
And the following code is to make it working (this code requires assembly to be 'unsafe'):
Windows API used:
Reflection utilities:
I am not experienced in writing reliable interaction with unmanaged environment, so I hope somebody can have a look and fix issues (and maybe make it 'safe').
这是 .NET 使用底层安全 API 时的一个错误。 请注意我提出的另一个关于无法选择特定密码套件的问题 - 他们真的搞砸了这个 API 包装器......
It's a bug in .NET's usage of the underlying security API. Note another question by me about being unable to select a specific cypher suite - they really botched up this API wrapper...
根据记录,至少在 .NET 2.0 中,SslStream 似乎也不会响应来自另一方的 close_notify。 这意味着正确调用 OpenSSL 的 SSL_Shutdown() ,即两次 - 一次启动关闭,另一次等待响应 - 将在第二次调用时挂起。
For the record, SslStream at least in .NET 2.0 also doesn't appear to response to a close_notify from the other side. This means that calling OpenSSL's SSL_Shutdown() properly, i.e. twice - once to initiate the shutdown and again to wait for the response - will hang on the second call.