SslStream does not properly send the "close_notify" alert - by Joannes Vermorel - Forecasting API

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 788752 Comments
Status Closed Workarounds
Type Bug Repros 4
Opened 5/28/2013 6:14:01 AM
Access Restriction Public


The SslStream does not properly send the "close_notify" alert on SSL3 and above as specified in the RFC. See for the detail concerning the "close_notify" alert.

In particular, the alert is not send when the method "Dispose()" is called, and no alternative are actually offered to the send the alert.

This invalid behavior wreaks havoc when interacting with numerous 3rd parties (starting from FileZilla for example when attempting FTPS with a .NET app on the server side).

This problem has already been observed and confirmed by other parties on StackOverflow
Sign in to post a comment.
Posted by Sidharth [MSFT] on 12/1/2014 at 10:25 AM
Hello Joannes,

Thank you very much for your feedback. Unfortunately, we will not be able to action on this bug in the current release. Ideally, we would love to address every issue reported by customers, but realistically, we cannot. Further, this is a critical part of .NET networking code, and making this change would add risk of breaking existing implementations that are dependent on this behavior.

We will continue to evaluate it for further releases. In the meantime, please consider using Windows.Networking.Sockets API or the workaround mentioned in the Wokarounds section.

.NET Networking team
Posted by Howard Dierking on 9/27/2013 at 5:50 PM
I've dug deeper on this, and while the team continues to consider this a lower priority issue, I can at least provide their reasoning.

This part of the spec ( “This is a change from TLS 1.0 to conform with widespread implementation practice.” Implies that this is a common mistake.

This only mitigates truncation attacks. HTTP is less susceptible to such attacks because it uses Content-Length or Chunked framing, so it knows when it reaches the end of a response. Similar for WCF over Sockets. SMTP is so verbose that I think a truncation would be obvious, but I’d have to look closer to be sure. That just leaves custom Sockets programming to provide disconnect handling.

So, the assigned priority is based on the fact that the mitigation here is frequently covered by higher level protocols, and that the majority of developers are programming against those protocols.
Posted by Victor Nicollet on 7/29/2013 at 1:25 AM
Thanks for your suggestion. However, Windows.Networking.Socket interfaces do not seem to support server-side SSL/TLS. From the documentation on SSL/TLS at :

> This support for SSL/TLS is limited to using the StreamSocket object as the client in the SSL/TLS negotiation. SSL/TLS cannot currently be used by the StreamSocketListener with the StreamSocket created when a connection is received to enable SSL/TLS on the StreamSocket created, since the SSL/TLS negotiation as a server is not implemented for a StreamSocket.

Also, while the SocketStreamListener does allow specifying an SSL flag, its behavior is not documented, and there is no way to provide the server certificate.
Posted by Peter [MSFT] on 7/24/2013 at 2:45 PM
Thank you for your feedback. We are unable to take this bug at this time. As a possible workaround, you can try using the Windows.Networking.Socket interfaces for creating SSL/TLS streams.
Posted by Rinat Abdullin on 7/15/2013 at 5:06 AM
I confirm the problem. Surprisingly enough, it was around .NET at least since October 2008:
Posted by Helen [MSFT] on 5/28/2013 at 11:41 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Macy [MSFT] on 5/28/2013 at 6:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(
Posted by Victor Nicollet on 5/28/2013 at 6:22 AM
I can confirm and reproduce this issue : closing or disposing the SSLStream will not send a Close Notify alert before closing the underlying stream.

Several third party clients that use SSL/TLS, especially the GnuTLS library, will treat this as evidence of tampering and will discard any data or requests sent priori to the shutdown.