SslStream should handle handshake and close_notify alerts

[fubar-coder]

At least until 2014, there was a problem with SslStream, where it didn't terminate the connection properly. There is a solution for the problem described on Stack Overflow: .NET SslStream doesn't close TLS connection properly. This solution (obviously) doesn't work any more with .NET Core. Is this problem fixed, or do we still need some kind of workaround?

[bartonjs]

https://www.ietf.org/rfc/rfc4346.txt (TLS 1.1) 7.2.1.

   close_notify
      This message notifies the recipient that the sender will not send
      any more messages on this connection.  Note that as of TLS 1.1,
      failure to properly close a connection no longer requires that a
      session not be resumed.  This is a change from TLS 1.0 to conform
      with widespread implementation practice.

While it does say "must" in that section it doesn't say "MUST", making it unclear if they consider it required or not ("you must do it, but we acknowledge that many people don't").

@davidsh: If you are going to change the Windows version to send close_notify we'll need to change the Unix one, too.

[davidsh]

@bartonjs SslStream doesn't fully support alerts (same limitation as Desktop). This isn't something that could be fixed in time for RTM.

[CIPop]

@fubar-coder I have changed the scope of the issue to track both close_notify as well as TLS handshake alerts.

The RFC quoted above is describing the way a TLS channel needs to close but is very clear regarding the transport channel:

Section 7.2.1. Closure alerts
If the application protocol will not
   transfer any additional data, but will only close the underlying
   transport connection, then the implementation may choose to close the
   transport without waiting for the responding close_notify. No part of
   this standard should be taken to dictate the manner in which a usage
   profile for TLS manages its data transport, including when
   connections are opened or closed.

From my experiments it appears that most browsers and HTTP servers will not send close_notify which is in-line with the current SslStream patterns.

For applications requiring this behavior, I am currently working on an implementation for both close_notify via a new API (currently named ShutdownAsync) as well as better TLS-level handshake error reporting (via fatal alerts).

[nikitozz]

While the fix is not there, is there a possible workaround that doesn't require dealing with unmanaged code?

Thank you.

[CIPop]

@nikitozz I thought I've fixed this in dotnet/corefx#11489.
To obtain the close_notify effect the code needs to call the new ShutdownAsync().
See this test for an example.

[qmfrederik]

I was looking for a way to implement bi-directional shutdown of a SSL connection as described in the OpenSSL SSL_Shutdown manpage, but using the SslStream class from CoreFX.

Just wanted to leave a note here confirming that you can use SslStream.ShutdownAsync to achieve the desired behavior.

However, the remote end may still send an alert after you've called SslStream.ShutdownAsync so you cannot just expect to read unencrypted data off the underlying stream after calling ShutdownAsync.
You need to explicitly do a ReadAsync to force SslStream to process the alert from the remote end, as the example in the unit tests show.

So you could use code like this:

await sslStream.ShutdownAsync().ConfigureAwait(false);
byte[] readBuffer = new byte[128];
int bytesRead = await sslStream.ReadAsync(readBuffer, 0, readBuffer.Length).ConfigureAwait(false);