目的：

这个报文的目的就是告诉对端自己在整个握手过程中收到了什么数据，发送了什么数据。来保证中间没人篡改报文。

其次，这个报文作用就是确认秘钥的正确性。因为Encrypted handshake message是使用对称秘钥进行加密的第一个报文，如果这个报文加解密校验成功，那么就说明对称秘钥是正确的。

原理：

首先，无论是客户端还是服务端，都会在握手完成之后，发送 Encrypted handshake message，且各自收到对端的Encrypted handshake message后会去验证这个数据。 

具体 这个 Encrypted handshake message 怎么计算，就是把当前（准备发送Encrypted handshake message）前，自己收到的数据和发送的数据进行一次简单运算（hash+加密，详细见下文）。

如果中间有人篡改了报文，比如，把客户端的client hello中的提供的加密套件改成了 一个弱秘钥算法，那么对于server而言，收到的client hello 和 客户端实际发送的是不同的，假设server收到的叫做client_hello_bad，这样，server 在计算Encrypted handshake message时，因为使用了client_hello_bad，计算完成之后，会发送给客户端，客户端为了确定握手数据是否被篡改，也需要模拟server端计算这个Encrypted handshake message，显然 客户端 计算 Encrypted handshake message 用的client hello 不是client_hello_bad，这样，客户端计算出来的，就和 服务端发过来的不同了，验证自然失败。

其次，某端要验证 Encrypted handshake message，必然需要先解密 Encrypted handshake message（因为他是用共享秘钥加密的），如果验证失败，也可能是 两端秘钥协商不成功。但是不管怎么样，无论是秘钥协商不成功还是数据被人篡改，都需要断开连接，即让握手失败。

运算：

计算方法也比较简单，将之前所有的握手数据（包括接受、发送），计算md运算，然后计算prf，然后就是使用协商好的对称密钥进行加密了。

第一步 MD运算：

md算法根据协议、算法不同，计算方式不一样。

（1）对于TLS1.2，摘要算法是sha256，即md_result = sha256(all_handshake)；

（2）对于TLS1.0 1.1，摘要算法是md5和sha1结果的拼接，即 md_result  =  md5(all_handshake) + sha1(all_handshake)。

（3）特殊情况：如果加密套件中指定了sha384算法，例如RSA_WITH_AES256_CBC_SHA384加密套件，则无论协商使用tls哪个版本，都用sha384，即md_result = sha384(all_handshake)。

第二部 PRF运算：

  计算完摘要后，客户端按这种格式：“client finished”+ md_result，作为prf的输入。PRF的输出指定为12字节。12字节的数据前填充4字节message头部信息，就可以送入对称加密流程进行加密了。

  PRF运算有机会单讲，其实就是P_HASH运算，P_HASH就是不断hmac运算，直到计算出预定指定长度的值为止。

  具体TLS1.0 1.1 和TLS1.2的PRF算法略不同。

Finished指的是明文，Encrypted handshake message指的是 加密后实际在网络中看到的 Finished，在wireshark等抓包工具中显示的包类型就是Encrypted handshake message。EHM=对称秘钥加密(Finished)。

下图中我将秘钥导入wireshark，所以显示的解密后的结果，即finished，正常情况显示的是Encrypted handshake message。 

  我们将prf解密后，可以看到如下格式：

（注意，这条报文实际就是Encrypted handshake message类型的报文，但是因为我让wireshark解密了下，所以显示了finished）

14 代表 finished 类型的message, 00 00 0c 三字节表示后续的prf长度，是12字节。也就是说对称加密的的输入就是

14 00 00 0c + 12字节PRF。

前四个字节就是上面所谓的头。