The principle of "go" Secure Transport Protocol SSL and TLS and WTLS

First, to clarify the name of the confusion

1.SSL (Secure Socket Layer) is a secure transport protocol designed primarily for the web by Netscape Corporation. This kind of protocol has been widely used on the web.

2.IETF standardizes SSL, known as RFC2246, and calls it TLS (Transport Layer Security), and technically, the difference between TLS1.0 and SSL3.0 is very small. Since this article does not deal with the small differences between the two, the two names in this article are equivalent.

3. In the WAP environment, due to the limited processing and storage capacity of mobile phones and handheld devices, WAP forum simplifies on the basis of TLS and puts forward the WTLS protocol (Wireless Transport Layer Security) to adapt to the special environment of wireless.

We learned from a variety of articles that SSL can be used for confidential transmissions, so that the messages we transfer to and from the Web server are " safe ." How does this " security " actually come about and how much secrecy can ultimately be achieved? This article hopes to use the popular language to clarify its realization principle.

Ii. Overview of the overall structure

SSL is an optional layer between the HTTP protocol and TCP, which is located roughly as follows:

--------- | HTTP | --------- | SSL | --------- | TCP | --------- | IP | －－－－－－－－－

If you use the SSL protocol to access a webpage, the steps are as follows:

User: Enter https://www.sslserver.com in the address bar of the browser

HTTP layer: Translates user requirements into HTTP requests, such as

get/index.htm http/1.1 Host http://www.sslserver.com

SSL layer: Negotiates a cryptographic key with the channel security of the underlying protocol and encrypts the HTTP request with this key.

TCP layer: Establishes a connection to the Web server's 443 port, passing SSL-processed data.

The receiver side is the opposite of this process.

SSL establishes an encrypted channel on top of TCP, and the data through this layer is encrypted, thus achieving a confidential effect.

The SSL protocol is divided into two parts: handshake Protocol and record Protocol. Where handshake protocol is used to negotiate a key, much of the protocol is how the communication parties use it to negotiate a key securely . The Record protocol defines the format of the transfer.

III. basic knowledge of encryption required

Understanding the concept of SSL requires a little bit of encryption, here the need to do a brief description of the concept:

Encryption is generally divided into three categories, symmetric encryption, asymmetric encryption and one-way hash functions.

Symmetric encryption: Sub-group password and serial password.

The block cipher is the clear text according to a certain bit length grouping, the clear text group through the cryptographic operation obtains the ciphertext group, the ciphertext group passes through the decryption operation (the cryptographic operation Inverse), restores the clear text group.

Sequence cipher refers to the use of a small number of keys (chaotic elements) through a complex operation (cryptographic algorithm) to generate a large number of pseudo-random bit streams, for the encryption of the plaintext bit stream.

Decryption refers to using the same key and cipher algorithms and the same pseudo-random bit stream as the encryption to restore the plaintext bit stream.

The word CBC (Cipher Block Chaining) pattern is often used in block ciphers, which refers to a plaintext grouping that is to be separated from the previous cipher before being encrypted. When the encryption algorithm is used in this mode, in addition to the key, you also need to negotiate an initialization vector (iv), this IV has no practical significance, but only in the first calculation of the need to use it. With this model, security will improve.

A typical example of a block cipher is DES, RC5, and idea.

A typical example of a sequence cipher is RC4.

Public Key cryptography:

Simply put, the encryption key differs from the decryption key by splitting the private key and the public key. This approach is mostly used for key exchange, and RSA is a familiar example.

There is also a common known as DH, which can only be used for key exchange and cannot be used for encryption.

One-way hash function:

Due to the interference of the channel itself and man-made destruction, the information received may be different from the original message, a common way is to add a check code.

A one-way hash function can be used for this purpose, a typical example of which is the MD5 we know, which produces a 128-bit digest, and in reality more of a secure hashing Algorithm (SHA), a problem with the earlier version of Sha, which is actually SHA-1, It produces a 160-bit digest, which makes it more effective against brute-force attacks than 128-bit hashes.

Since the one-way hashing algorithm is public, others can change the original text before generating another digest. The solution to this problem can be achieved by HMAC (RFC 2104), which contains a key that can be identified only by people with the same key.

Four, key negotiation process

Because of the slow speed of symmetric encryption, it is generally used for key exchange, the two sides through the public key algorithm to negotiate a copy of the key, and then through the symmetric encryption to communicate, of course, in order to ensure the integrity of the data, before the encryption before the processing of the HMAC.

SSL defaults to server-side authentication only, and client authentication is optional. The following is its flowchart (excerpted from the TLS protocol).

tr>

Client Server Clienth*llo--------> Serverh*llo certificate* serverkeyexchange* certificatere quest* <--------serverh*llodone certificate* clientkeyexchange certificateverify* [Changecipherspec] Finished-- ------> [Changecipherspec] <--------finished Application Data <-------> Application Data

Simply put: SSL client (also TCP client) after the TCP link is established, issued a Clienth*llo to initiate a handshake, the message contains its own list of achievable algorithms and other required messages, the server side of SSL will respond to a Serverh*llo , which identifies the algorithm needed for this communication, and then sends out its own certificate (which contains the identity and its own public key). When the client receives this message, it generates a secret message that is encrypted with the SSL server's public key and passed in after the SSL server is decrypted with its own private key, and the session key negotiation succeeds, and the two parties can communicate with the same session key.

Five, the figurative analogy of key negotiation

If the above description is not clear enough, here we use an image analogy, we assume that A and B communication, A is the SSL client, B is the SSL server side, the encrypted message is placed in square brackets [], to highlight the difference between the plaintext message. The description of the handling action of both parties is enclosed in parentheses ().

A: I want to talk to you safely , I here the symmetric encryption algorithm has DES,RC5, the key exchange algorithm has RSA and DH, Digest algorithm has MD5 and SHA.

B: We'll use the Des-rsa-sha to set it up.

This is my certificate, which has my name and public key, you take to verify my identity (send the certificate to a).

There is nothing else to say at the moment.

A: (check that the name of B on the certificate is correct, and verify the authenticity of B's certificate through the certificate of the CA that is already in hand, if one of the errors, issue a warning and disconnect, this step ensures the authenticity of B's public key)

(generates a secret message that is treated as an encryption key, encrypting the initialization vector and the HMAC key.) This secret message-the protocol, known as per_master_secret-, is encrypted with the public key of B, encapsulated in a message called Clientkeyexchange. Due to the use of B's public key to ensure that third parties cannot eavesdrop)

I generated a copy of the

Secret message, encrypted with your public key, to you (send Clientkeyexchange to B)

Note that I'm going to send you a message in an encrypted way!

(Process secret messages, generate encryption keys, encrypt initialization vectors, and keys for HMAC)

[I'm done.]

B: (Use your own private key to decrypt the secret message in Clientkeyexchange, and then process the secret message, generate the encryption key, encrypt the initialization vector and the HMAC key, the two sides have negotiated a set of encryption method safely )

Note that I will also start to send you a message in an encrypted way!

[I'm done.]

A: [My secret is ...]

B: [Others won't hear ...]

Vi. Calculation of encryption

The key negotiation was discussed in the previous step, but it has not yet been clarified how to encrypt the message using the encryption key, encrypting the initialization vector and the HMAC key.

In fact, the process is so:

1 with the HMAC key, the plaintext message is treated as a safe Digest and then put together with the plaintext.

2 Encrypt the initialization vector to encrypt the message above with the encryption key.

Vii. Security

Securityportal at the end of 2000 there was an article "the end of SSL and SSH," which sparked a lot of discussion, and there are some sophisticated tools such as dsniff that can intercept HTTPS messages through the man in the middle attack.

From the above principle, the structure of SSL is rigorous, the problem is generally in the application of the actual not rigorous. A common attack is the middle in the middle attack, which refers to the communication between A and b at the same time that there is a third party C in the middle of the channel, you can completely hear a and B communication messages, and can intercept, replace and add these messages.

1 SSL can allow a variety of key exchange algorithms, and some algorithms, such as DH, there is no concept of certificate, so that a can not verify the public key and the authenticity of the identity, so C could easily impersonate, with their own key to communicate with each other, so as to eavesdrop on the content of the conversation.

To prevent middle in the middle attack, a certificate-based key exchange algorithm should be used.

2 with the certificate, if C replaced the original certificate with its own certificate, A's browser will pop up a warning box to warn, but how many people will notice this warning?

3 Because of the U.S. password export restrictions, Ie,netscape and other browsers support the encryption strength is very weak, if only using the browser's own encryption function, theoretically there is the possibility of being cracked.

Eight, agent

Here's a look at how SSL proxies work. When the proxy for HTTPS is set in the browser, and after Https://www.example.com is entered in the browser, the browser establishes a TCP link with proxy and sends a message to it:

CONNECT server.example.com:443 http/1.1 host:server.example.com:443

The proxy then establishes a TCP connection to the Webserver end, after which the agent is completely a content forwarding device. The browser and Web server will establish a secure channel, so this secure channel is end-to-end, although all the information flow over the proxy, but its content proxy can not be decrypted and changed (of course, by the certificate of support, Otherwise this place is a good place to attack the man in the middle, see the discussion above).

Nine, about the certificate

Note that if for a typical application, the administrator only needs to generate a "certificate request" (the suffix is mostly. CSR), it contains your name and public key, and then the request to a CA service company such as VeriSign (of course, together with $ hundreds of), after your certificate request is verified, the CA uses its private key to sign, form a formal certificate back to you. The administrator can then import the certificate on the Web server. If you don't want to spend that money, or want to know the principle, you can make your own CA.

From the CA's point of view, you need the CA's private key and public key. From the perspective of the server that wants the certificate, you need to hand over the server's certificate request to the CA.

If you want to make a CA yourself, don't forget that the client needs to import the CA's certificate (the CA's certificate is self-signed and importing it means you "trust" the CA-signed certificate).

Commercial CAs are generally not used because they are already built into your browser.

Ten, Wtls

In the WAP environment, there is also the need for secure encryption, so wapforum reference in the WWW world the most popular SSL protocol design WTLS. In principle, this agreement is basically the same as SSL, but there are many changes in the specific area. Most of these changes are not technically necessary, but are simplified as much as possible due to the limitations of handheld device operations and storage. However, my feeling is that these changes are not very significant, and the amount of time and space saved on the calculation and storage is not much. In an era of rapid hardware speed, the benefits of such changes may not be much (a new agreement would require a lot of new input and would not be compatible with the original system).

Here I simply cite some of the differences between SSL and WTLS.

1.WTLS in the general UDP this type of unreliable channel work, so each message must have a serial number, the protocol also rely on it to handle packet loss, duplication and so on. In addition, denial-of-service attacks have become easier.

The secure connection established by the 2.WTLS is between the WAP gateway and the handheld device, and if the WAP gateway and the Web server are to be kept secret, then SSL should be used, that is, the end-to-end encryption cannot be implemented in this model.

---------- ------------- --------- | Mobile |----------->| WAP |---------->| WEB | | Device |<-----------| Gateway |<----------| Server | | | WTLS | | SSL | | ---------- ------------- ---------

The 3.WTLS protocol adds a mechanism to become a key_refresh, and when a certain number of packets are passed, both parties update their keys with the same algorithm. At a very small cost, security has been enhanced.

The principle of "go" Secure Transport Protocol SSL and TLS and WTLS