Update http-transport-security.md

docs/framework/wcf/feature-details/http-transport-security.md

@@ -11,7 +11,7 @@ When using HTTP as the transport, security is provided by a Secure Sockets Layer
 
  When a user first visits the site, the SSL mechanism begins a series of negotiations, called a *handshake*, with the user's client (in this case, Internet Explorer). SSL first authenticates the bank site to the customer. This is an essential step because customers must first know that they are communicating with the actual site, and not a spoof that tries to lure them into typing in their user name and password. SSL does this authentication by using an SSL certificate provided by a trusted authority, such as VeriSign. The logic goes like this: VeriSign vouches for the identity of the bank site. Because Internet Explorer trusts VeriSign, the site is trusted. If you want to check with VeriSign, you can do so as well by clicking on the VeriSign logo. That presents a statement of authenticity with its expiration date and who it is issued to (the bank site).  
 
- To initiate a secure session, the client sends the equivalent of a "hello" to the server along with a list of cryptographic algorithms it can use to sign, generate hashes, and encrypt and decrypt with. In response, the site sends back an acknowledgment and its choice of one of the algorithms suites. During this initial handshake, both parties send and receive nonces. A *nonce* is a randomly generated piece of data that is used, in combination with the site's public key, to create a hash. A *hash* is a new number that is derived from the two numbers using a standard algorithm, such as SHA1. (The client and the site also exchange messages to agree which hash algorithm to use.) The hash is unique and is used only for the session between the client and the site to encrypt and decrypt messages. Both client and service have the original nonce and the certificate's public key, so both sides can generate the same hash. Therefore, the client validates the hash sent by the service by (a) using the agreed upon algorithm to calculate the hash from the data, and (b) comparing it to the hash sent by the service; if the two match, then the client has assurance that the hash has not been tampered with. The client can then use this hash as a key to encrypt a message that contains yet another new hash. The service can decrypt the message using the hash, and recover this second-to-final hash. The accumulated information (nonces, public key, and other data) is now known to both sides, and a final hash (or master key) can be created. This final key is sent encrypted using the next-to-last hash. The master key is then used to encrypt and decrypt messages for the reset of the session. Because both client and service use the same key, this is also called a *session key*.  
+ To initiate a secure session, the client sends the equivalent of a "hello" to the server along with a list of cryptographic algorithms it can use to sign, generate hashes, and encrypt and decrypt with. In response, the site sends back an acknowledgment and its choice of one of the algorithms suites. During this initial handshake, both parties send and receive nonces. A *nonce* is a randomly generated piece of data that is used, in combination with the site's public key, to create a hash. A *hash* is a new number that is derived from the two numbers using a standard algorithm, such as SHA1. (The client and the site also exchange messages to agree which hash algorithm to use.) The hash is unique and is used only for the session between the client and the site to encrypt and decrypt messages. Both client and service have the original nonce and the certificate's public key, so both sides can generate the same hash. Therefore, the client validates the hash sent by the service by (a) using the agreed upon algorithm to calculate the hash from the data, and (b) comparing it to the hash sent by the service; if the two match, then the client has assurance that the hash has not been tampered with. The client can then use this hash as a key to encrypt a message that contains yet another new hash. The service can decrypt the message using the hash, and recover this second-to-final hash. The accumulated information (nonces, public key, and other data) is now known to both sides, and a final hash (or master key) can be created. This final key is sent encrypted using the next-to-last hash. The master key is then used to encrypt and decrypt messages for the rest of the session. Because both client and service use the same key, this is also called a *session key*.  
 
  The session key is also characterized as a symmetric key, or a "shared secret." Having a symmetric key is important because it reduces the computation required by both sides of the transaction. If every message demanded a new exchange of nonces and hashes, performance would deteriorate. Therefore, the ultimate goal of SSL is to use a symmetric key that allows messages to flow freely between the two sides with a greater degree of security and efficiency.