new security feature

Author: gewarren

xml/System.Net.Security/SslStream.xml

@@ -85,7 +85,7 @@
 
  <xref:System.Net.Security.SslStream> assumes that a timeout along with any other <xref:System.IO.IOException> when one is thrown from the inner stream will be treated as fatal by its caller. Reusing a <xref:System.Net.Security.SslStream> instance after a timeout will return garbage. An application should <xref:System.IO.Stream.Close%2A> the <xref:System.Net.Security.SslStream> and throw an exception in these cases.
 
- The .NET Framework 4.6 includes a new security feature that blocks insecure cipher and hashing algorithms for connections. Applications using TLS/SSL through APIs such as HttpClient, HttpWebRequest, FTPClient, SmtpClient, SslStream, etc. and targeting .NET Framework 4.6 get the more-secure behavior by default.
+ The .NET Framework 4.6 includes a security feature that blocks insecure cipher and hashing algorithms for connections. Applications using TLS/SSL through APIs such as HttpClient, HttpWebRequest, FTPClient, SmtpClient, and SslStream and targeting .NET Framework 4.6 get the more-secure behavior by default.
 
  Developers may want to opt out of this behavior in order to maintain interoperability with their existing SSL3 services OR TLS w/ RC4 services. [This article](https://support.microsoft.com/kb/3069494) explains how to modify your code so that the new behavior is disabled.
 

xml/System.Net/ServicePointManager.xml

@@ -66,7 +66,7 @@
 
  When an application requests a connection to an Internet resource Uniform Resource Identifier (URI) through the <xref:System.Net.ServicePointManager> object, the <xref:System.Net.ServicePointManager> returns a <xref:System.Net.ServicePoint> object that contains connection information for the host and scheme identified by the URI. If there is an existing <xref:System.Net.ServicePoint> object for that host and scheme, the <xref:System.Net.ServicePointManager> object returns the existing <xref:System.Net.ServicePoint> object; otherwise, the <xref:System.Net.ServicePointManager> object creates a new <xref:System.Net.ServicePoint> object.
 
- The .NET Framework 4.6 includes a new security feature that blocks insecure cipher and hashing algorithms for connections. Applications using TLS/SSL through APIs such as <xref:System.Net.Http.HttpClient>, <xref:System.Net.HttpWebRequest>, <xref:System.Net.FtpWebRequest>, <xref:System.Net.Mail.SmtpClient>, <xref:System.Net.Security.SslStream>, etc. and targeting .NET Framework 4.6 get the more-secure behavior by default.
+ The .NET Framework 4.6 includes a security feature that blocks insecure cipher and hashing algorithms for connections. Applications using TLS/SSL through APIs such as <xref:System.Net.Http.HttpClient>, <xref:System.Net.HttpWebRequest>, <xref:System.Net.FtpWebRequest>, <xref:System.Net.Mail.SmtpClient>, and <xref:System.Net.Security.SslStream> and targeting .NET Framework 4.6 or later get the more-secure behavior by default.
 
  Developers may want to opt out of this behavior in order to maintain interoperability with their existing SSL3 services or TLS w/ RC4 services. [This article](https://support.microsoft.com/kb/3069494) explains how to modify your code so that the new behavior is disabled.
 
@@ -1120,7 +1120,7 @@ For versions of the .NET Framework through the .NET Framework 4.6.2, no default
 
  Your code should never implicitly depend on using a particular protection level, or on the assumption that a given security level is used by default. If your app depends on the use of a particular security level, you must explicitly specify that level and then check to be sure that it is actually in use on the established connection. Further, your code should be designed to be robust in the face of changes to which protocols are supported, as such changes are often made with little advance notice in order to mitigate emerging threats.
 
- The .NET Framework 4.6 includes a new security feature that blocks insecure cipher and hashing algorithms for connections. Applications using TLS/SSL through APIs such as HttpClient, HttpWebRequest, FTPClient, SmtpClient, SslStream, etc. and targeting .NET Framework 4.6 get the more-secure behavior by default.
+ The .NET Framework 4.6 includes a security feature that blocks insecure cipher and hashing algorithms for connections. Applications using TLS/SSL through APIs such as HttpClient, HttpWebRequest, FTPClient, SmtpClient, and SslStream and targeting .NET Framework 4.6 get the more-secure behavior by default.
 
  Developers may want to opt out of this behavior in order to maintain interoperability with their existing SSL3 services OR TLS w/ RC4 services. [This article](https://support.microsoft.com/kb/3069494) explains how to modify your code so that the new behavior is disabled.