Provides a stream used for client-server communication that uses the Secure Socket Layer (SSL) security protocol to authenticate the server and optionally the client.
See Also: SslStream Members
SSL protocols help to provide confidentiality and integrity checking for messages transmitted using an System.Net.Security.SslStream. An SSL connection, such as that provided by System.Net.Security.SslStream, should be used when communicating sensitive information between a client and a server. Using an System.Net.Security.SslStream helps to prevent anyone from reading and tampering with information while it is in transit on the network.
An System.Net.Security.SslStream instance transmits data using a stream that you supply when creating the System.Net.Security.SslStream. When you supply this underlying stream, you have the option to specify whether closing the System.Net.Security.SslStream also closes the underlying stream. Typically, the System.Net.Security.SslStream class is used with the System.Net.Sockets.TcpClient and System.Net.Sockets.TcpListener classes. The System.Net.Sockets.TcpClient.GetStream method provides a System.Net.Sockets.NetworkStream suitable for use with the System.Net.Security.SslStream class.
After creating an System.Net.Security.SslStream, the server and optionally, the client must be authenticated. The server must provide an X509 certificate that establishes proof of its identity and can request that the client also do so. Authentication must be performed before transmitting information using an System.Net.Security.SslStream. Clients initiate authentication using the synchronous erload:System.Net.Security.SslStream.AuthenticateAsClient methods, which block until the authentication completes, or the asynchronous erload:System.Net.Security.SslStream.BeginAuthenticateAsClient methods, which do not block waiting for the authentication to complete. Servers initiate authentication using the synchronous erload:System.Net.Security.SslStream.AuthenticateAsServer or asynchronous erload:System.Net.Security.SslStream.BeginAuthenticateAsServer methods. Both client and server must initiate the authentication.
The authentication is handled by the Security Support Provider (SSPI) channel provider. The client is given an opportunity to control validation of the server's certificate by specifying a System.Net.Security.RemoteCertificateValidationCallback delegate when creating an System.Net.Security.SslStream. The server can also control validation by supplying a System.Net.Security.RemoteCertificateValidationCallback delegate. The method referenced by the delegate includes the remote party's certificate and any errors SSPI encountered while validating the certificate. Note that if the server specifies a delegate, the delegate's method is invoked regardless of whether the server requested client authentication. If the server did not request client authentication, the server's delegate method receives a null certificate and an empty array of certificate errors.
If the server requires client authentication, the client must specify one or more certificates for authentication. If the client has more than one certificate, the client can provide a System.Net.Security.LocalCertificateSelectionCallback delegate to select the correct certificate for the server. The client's certificates must be located in the current user's "My" certificate store. Client authentication via certificates is not supported for the System.Security.Authentication.SslProtocols.Ssl2 (SSL version 2) protocol.
If the authentication fails, you receive a System.Security.Authentication.AuthenticationException, and the System.Net.Security.SslStream is no longer useable. You should close this object and remove all references to it so that it can be collected by the garbage collector.
When the authentication process, also known as the SSL handshake, succeeds, the identity of the server (and optionally, the client) is established and the System.Net.Security.SslStream can be used by the client and server to exchange messages. Before sending or receiving information, the client and server should check the security services and levels provided by the System.Net.Security.SslStream to determine whether the protocol, algorithms, and strengths selected meet their requirements for integrity and confidentiality. If the current settings are not sufficient, the stream should be closed. You can check the security services provided by the System.Net.Security.SslStream using the SslStream.IsEncrypted and SslStream.IsSigned properties. The following table shows the elements that report the cryptographic settings used for authentication, encryption and data signing.
The security protocol used to authenticate the server and, optionally, the client. |
The SslStream.SslProtocol property and the associated System.Security.Authentication.SslProtocols enumeration. |
The key exchange algorithm. |
The SslStream.KeyExchangeAlgorithm property and the associated System.Security.Authentication.ExchangeAlgorithmType enumeration. |
The message integrity algorithm. |
The SslStream.HashAlgorithm property and the associated System.Security.Authentication.HashAlgorithmType enumeration. |
The message confidentiality algorithm. |
The SslStream.CipherAlgorithm property and the associated System.Security.Authentication.CipherAlgorithmType enumeration. |
The strengths of the selected algorithms. |
The SslStream.KeyExchangeStrength, SslStream.HashStrength, and SslStream.CipherStrength properties. |
After a successful authentication, you can send data using the synchronous erload:System.Net.Security.SslStream.Write or asynchronous SslStream.BeginWrite(Byte[], int, int, AsyncCallback, object) methods. You can receive data using the synchronous SslStream.Read(Byte[], int, int) or asynchronous SslStream.BeginRead(Byte[], int, int, AsyncCallback, object) methods.
If you specified to the erload:System.Net.Security.SslStream.#ctor that the underlying stream should be left open, you are responsible for closing that stream when you are done using it.
If the application that creates the System.Net.Security.SslStream object runs with the credentials of a Normal user, the application will not be able to access certificates installed in the local machine store unless permission has been explicitly given to the user to do so.
System.Net.Security.SslStream assumes that a timeout along with any other System.IO.IOException when one is thrown from the inner stream will be treated as fatal by its caller. Reusing a System.Net.Security.SslStream instance after a timeout will return garbage. An application should System.IO.Stream.Close the System.Net.Security.SslStream and throw an exception in these cases.