Introduction to HTTP Transmission Security Process

If HTTP is used for transmission, the Security Socket Layer (SSL) provides security. SSL is widely used in the Internet to prove the identity of the service to the client and subsequently provide confidentiality (encryption) to the channel ). This topic describes how SSL works and how it is implemented in Windows Communication Foundation (WCF.

Basic SSL

The SSL method can be best described through a typical solution. In this example, the solution is a bank website. This website allows users to log on with their usernames and passwords. After Authentication, you can perform transactions, such as viewing account balances, paying bills, and transferring money from one account to another.

When a user visits the website for the first time, the SSL mechanism starts a series of negotiations with the user client (in this case, Internet Explorer), called "handshake". SSL first proves the identity of the bank website to the customer. This step is required because the customer must first know that they are communicating with a real website, rather than a fraudulent website trying to lure them into entering their usernames and passwords. SSL performs this authentication by using an SSL certificate provided by a trusted authority such as VeriSign. The logic is as follows: VeriSign guarantees that the identity of the Bank's website is true. Because Internet Explorer trusts VeriSign, it also trusts the website. If you want to verify with VeriSign, you can click the VeriSign logo to perform this operation. This will display a statement containing the expiration date and the authenticity of the recipient (bank website.

To start a security session, the client sends an item equivalent to "hello" to the server, along with a list of encryption algorithms that can be used to sign, generate a hash, and encrypt and decrypt it. In response, the website sends a confirmation message and its selection of one of the algorithm groups. Both parties send and receive Nonce during the initial handshake."Nonce" is a random piece of data that is used together with the public key of the website to create a hash."Hash" is a new number obtained from two numbers using a standard algorithm (such as SHA1. (The client and website also exchange messages to negotiate the hash algorithm to be used .) Hash is unique and only used in sessions between the client and the website for message encryption and decryption. Both the client and service have the public key of the original Nonce and certificate, so the communication ends can generate the same hash. Therefore, the client can verify the hash sent by the Service in the following ways: (a) Calculate the hash based on the data using the agreed algorithm; and (B) compare the calculated hash with the hash sent by the Service. If the two match, the client can make sure that the hash is not tampered. The client can then use this hash as the key to encrypt messages that contain another new hash. The service can use this hash to decrypt the message and obtain the second to last hash again. In this way, both parties are informed of the accumulated information (Nonce, public key, and other data) and can create the last Hash (also known as the master key ). The final key is encrypted using the second-to-last hash and then sent. Then, the CMK is used to encrypt and decrypt the messages used to reset the session. Because both the client and the service use the same key, the key is also called a "session key".

The session key is also described as a symmetric key or a "Shared Secret ". It is important to have a symmetric key because it reduces the amount of computing required by both parties. If each message requires a new exchange of Nonce and hash, the performance will decrease. Therefore, the ultimate goal of SSL is to use a symmetric key that allows the message to flow freely between the communication parties, with higher security and efficiency.

Because the Protocol may vary with the website, the previous description is only a simplified version of the process. Another possibility is that both the client and the website generate a combined algorithm Nonce during the handshake to increase the complexity of the data exchange process and provide more protection for the process.

Certificate and public key infrastructure

During the handshake, the service also sends its SSL Certificate to the client. The certificate contains information such as the expiration date of the certificate, the Uniform Resource Identifier (URI) of the Authority and website ). The client compares the URI with the URI it was originally associated with to ensure that the URI matches the two and checks the date and the Authority.

Each certificate has two keys: one private key and one public key, which are called an "exchange key pair". In short, only the certificate owner knows the private key, and the public key can be read from the certificate. Both keys can be used to encrypt and decrypt abstract, hash, or other keys, but they can only be used for reverse operations. For example, if the client uses public key encryption, only the website can use the private key to decrypt the message. Similarly, if a website uses a private key for encryption, the client can use the public key for decryption. This ensures that the client only exchanges messages with the owner of the private key, because only messages encrypted with the private key can be decrypted using the public key. The website can be sure that it is exchanging messages with clients that have been encrypted using the public key. However, this exchange is only secure for the first handshake, so it is much more complicated to create an actual symmetric key. However, all communications depend on services that have valid SSL certificates.

Use WCF to implement SSL

HTTP Transmission security (or SSL) is provided outside WCF. You can use either of the following two methods to implement SSL:

• If you want to use Internet Information Service (IIS) as the WCF host, use the IIS infrastructure to set the SSL Service.
• If you want to create a self-hosted WCF application, you can use HttpCfg.exe to bind the SSL Certificate to the corresponding address.

Use IIS to implement transmission security IIS 7.0

To set IIS 7.0 as a secure host (using SSL), see IIS 7.0 Beta: configure the Secure Socket Layer in IIS 7.0 (possibly an English webpage ).

To configure a certificate for use with IIS 7.0, see IIS 7.0 Beta: configure a server certificate in IIS 7.0 (which may be an English webpage ).

In IIS 6.0

To set IIS 6.0 as a secure host (using SSL), see Configuring Secure Sockets Layer (which may be an English webpage ).

To configure a certificate for use with IIS 6.0, see Certificates_IIS_SP1_Ops (which may be an English webpage ).

Use HttpCfg for SSL

To create a self-hosted WCF application, download the HttpCfg.exe tool from the Windows XP Service Pack 2 Support Tool website (which may be an English webpage.

For more information about using the X.509 Certificate to set the port through HttpCfg.exe, see how to configure the port using the SSL certificate.