TLS / SSL protocol details (28) differences between TLS 1.0, TLS 1.1 and TLS 1.2

TLS 1.0 RFC http://www.ietf.org/rfc/rfc2246.txt

TLS 1.1 RFC http://www.ietf.org/rfc/rfc4346.txt

TLS 1.2 RFC http://www.ietf.org/rfc/rfc5246.txt

 

TLS 1.3 see ：https://blog.csdn.net/mrpre/article/details/81532469

my TLS Realization , You can refer to ：https://github.com/mrpre/atls/

Here, according to TLS The implementation of the , Summarize . As for which algorithms are discarded between version numbers 、 What algorithms are added , Look directly at RFC that will do , It doesn't matter here .

It's just about TLS What are the changes in the internal processing logic of the message , That is to analyze from the perspective of code . If you are right TLS I'm not familiar with the agreement , Then it is not recommended to read this article . To understand this article, you need to know TLS It is realized by a deeper understanding , Want to know TLS Basic knowledge of , I suggest starting from the beginning of this series .


difference 1： Yes finished message （Encrypted handshake message） influence
TLS 1.0 TLS 1.1 In the calculation finish when , What's going on is MD5+ SHA1 Combinatorial operation , And in the TLS 1.2 Next , The summary algorithm becomes a single SHA256.

 

 

The pseudocode is as follows

If(version >= TLS1_2)
{


     If (cipher.mac == SHA384)
     {


            restult = SHA384(handshake_in );
     }
     Else
     {
            restult  =  SHA256(handshake_in);
     }
}
Else
{
    restult  =  md5(handshake_in) + sha1(handshake_in);
}

among handshake_in yes String constant + All handshake information （ The type is Handshake Of message）.

for example

As client End handshake_in =“client finidhed” + all_handshake
As Server End handshake_in = “server finidhed” + all_handshake


notes ： For the encryption suite, there are SHA384 And above , No matter what TLS Which version , Use both Encryption suite specified Handshake summary algorithm calculation Abstract , As shown in the pseudo code above （RFC For every new algorithm , All need to specify default still SHAXXX, But in terms of implementation , Are all based on MAC What is it? ,SHAXXX That's what ）.

In fact, the digest algorithm specified in the encryption suite is used for encryption HMAC Of , It does not affect the operation in the handshake process , But if the encryption suite negotiated between the two sides supports SHAXXX, Then it must mean that both sides support SHAXXX Algorithm , So in SHAXXX Safety is higher than SHA256 Under the circumstances , If the handshake phase requires a digest algorithm, it is not necessary to be so ‘ die ’ Only SHA256. Of course, there is nothing better than SHA384 Higher .

 

difference 2： Yes PRF The impact of algorithms
 

First sort out the logic with pseudo code ：

If(version >= TLS1_2)
{
    If (cipher.mac == SHA384)
    {
        TLS1_2_PRF(SHA384, in, srcret);
    }
    Else
    {
        TLS1_2_PRF(SHA256, in, srcret);
    }
}
Else
{
    TLS1_PRF(MD5,SHA1, in, srcret);
}

 

1： about SHA384 The judgment of the , That was already said , No more details here .
2： You can see TLS1.2 and TLS 1.0 TLS 1.1 Of PRF It's different , Different parameters .

TLS 1.2 Of PRF
A single P_HASH,P_HASH It uses SHA256

TLS 1.1 Of PRF
two P_HASH, for the first time P_HASH It uses MD5, as well as secret First half of ; The second time P_HASH The use of SHA1, as well as secret The second half of . two P_HASH The result of or （xor）, Get the final result .

Be careful secret If it's even , Just half each , If it's odd ：

 

for example secret yes 1234567, Then the first half refer to 1234, The latter half refers to 4567, The middle byte is common .

 

difference 3： Yes Certificate verify Influence

Certificate vertify After the client sends the certificate , To show that you are the owner of the certificate , Use your own private key to pair the previously received 、 Sign the handshake information sent .（ and finished similar ）.

Also before signing , The handshake information needs to be HASH operation .

 

TLS1.0 TLS1.1：

Use MD5+SHA1 Abstract the handshake information in the form of , This process and calculation finished equally , Just don't add string constants ’XXX finished’.

notes ： There is one exception , about ECDSA Signature algorithm （ The client certificate is ECC certificate ）, Only one time SHA1 Calculation .

TLS 1.2：

TLS 1.2 Next , certificate verify The message format is different from that before , More 2 Bytes （Signature Hash Algorithm）, Express hash_alg as well as sign_alg. The specific handshake summary is based on hash_alg Make a single calculation .

Again , If the encryption suite exists SHA384, Then use SHA384

TLS 1.2 Next Certificate verify The format of

 

The pseudocode is as follows ：

If(version >= TLS1_2)
{
    result = SHAXXX(all_handshake);
    ADD_MD_INFO_TO_PACKET();// Two bytes are added to the message to indicate its signature algorithm 
}
Else
{
    If(ECDSA_SIGN)
    {
          result = SHA1(all_handshake);
    }
    Else
    {
        result = MD5(all_handshake) + SHA1(all_handshake) 
    }
}

 

In conclusion ：

 

1：TLS 1.2 Need to increase the 2 Bytes indicate the type of signature algorithm （ Asymmetric + Abstract ）. and TLS1.2 Use the previous default agreement md5+sha1 Calculation summary in the form of , The asymmetric algorithm must use the algorithm corresponding to the private key type , This does not need to show that .

2：ECDSA Signatures require special treatment .

 

 

difference 4： Yes server key exchange Influence

TLS1.2 Lower and certificate verify similar , The message format is different from the previous version . More 2 Byte representation HASH Algorithm and signature algorithm .

 

 

Summary logic and when signing certificate verify equally .

 

difference 5： Impact on encryption

    The change is TLS1.1 Beginning to change , No TLS1.2.

    To fight against beast attack ,SSL Before encrypting data , Need to fill in a BLOCK_SIZE（IV_SIZE） Random number of length , This random value is also encrypted as part of the data , When decrypting , Also decrypt , Then discard .

     CBC Next , For the above scenario, we can actually optimize , This BLOCK_SIZE The data of can not be encrypted for the sender , Then the next block of data Write_IV Change to this random number , such CBC The pattern can work completely . For the decryptor , This BLOCK_SIZE The data can not be decrypted , Then decrypt the next block Read_IV Become this random number ,CBC Mode also works . One less BLOCK_SIZE The disclosure of the 、 Encrypt data . See my blog for detailed optimization scheme  http://blog.csdn.net/mrpre/article/details/78093370

If it works , Please give me a reward N element ：http://39.98.242.44