HTTPS协议之通信加密过程分析

前言:

1. 学习https的加密过程避免不了去了解以下概念：

   • 对称加密。常用的算法有DES， AES，通俗的了解即通信的双方都使用同一个秘钥进行加密或解密。

   • 非对称加密。常用的算法有RSA, DH，私钥 + 公钥= 密钥对，对它的通俗理解即用私钥加密的数据，只有对应的公钥才能解密，用公钥加密的数据，只有对应的私钥才能解密。

   • 消息摘要Message Digest 。算法有MD5，SHA，简单来讲，就是将原数据用一个Hash算法生成一个消息摘要，这个Hash算法有个极好的特性,只要原数据有一点点变化，那生成的消息摘要就会有巨变,能有效防止别人篡改数据。

   • 数字证书。是通信确定身份的一种电子证书，该电子证书一般是有权威的CA机构颁发，内容包括证书签发者，证书用途，采用的HASH算法，服务器的基本信息（如域名，组织名，地区名，以及国家等信息），还有最重要的服务器公钥。

   • 数字签名。如果CA直接将上面的数字证书就这样直接给了申请机构，那传输过程中如果有人篡改了这个证书，那这个证书还有什么权威性可言？于是把证书的内容通过摘要算法做一次HASH,得到一个信息摘要，然后再用CA的私钥对摘要加密，就得到了数字签名，附加在证书的末尾，一起传给申请机构。现在，设想一下，如果不加密那个摘要，任何人都可以篡改证书，然后再重新计算HASH，附在证书的后面，传给申请者时，申请者是无法发现证书是否被篡改过的。而用了CA私钥加密后，就生成了类似人类指纹的签名，任何篡改证书的尝试，都会被数字签名发现。

2. 建议首先安装Woreshark,方便直观的观察加密流程。

名词解释

首先解释一下上面的几个名词：

https：在http(超文本传输协议)基础上提出的一种安全的http协议，因此可以称为安全的超文本传输协议。http协议直接放置在TCP协议之上，而https提出在http和TCP中间加上一层加密层。从发送端看，这一层负责把http的内容加密后送到下层的TCP，从接收方看，这一层负责将TCP送来的数据解密还原成http的内容。

SSL(Secure Socket Layer)：是Netscape公司设计的主要用于WEB的安全传输协议。从名字就可以看出它在https协议栈中负责实现上面提到的加密层。因此，一个https协议栈大致是这样的： image

SSL 加密过程

假设A与B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。

A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH，摘要算法有MD5和SHA（把消息封装成Client Hello发送给B)。

B：我们用DES－RSA－SHA这对组合好了（把消息封装成Server Hello发送给A)。
另外，这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书Certificate发给A）。

A：（收到B发来的加密方式和证书Certificate，验证B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性，至于如何验证下面详细讲）

（如果证书没有问题，A会生成一份秘密消息，这份秘密消息处理后将用作对称加密密钥。将这份秘密消息用B的公钥加密，封装成称作ClientKeyExchange的消息。由于用了B的公钥，保证了第三方无法窃听）

我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B）。

B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成A传送过来的对称加密密钥，这时双方已经安全的协商出一套加密办法了）

接着，A，B双方就通过这个对称加密密钥进行加密解密通信了

从上面的过程可以看到，SSL协议是如何用非对称密码算法来协商对称密钥，并使用密钥加密明文并传输的。事实上，上述过程B没有验证A的身份，如果需要的话，SSL也是支持的，此时A也需要提供自己的证书，这里就不展开了。在设置IIS的SSL Require的时候，通常默认都是igore client certification的。

现在来说一下客户端是如何验证服务端发来的证书Certificate的：

客户端接到服务器传来的证书，从本机得到CA的公钥值，这样就可以解密数字证书末尾的数字签名了，解密签名得到原始的证书摘要HASHs，然后自己也按照证书中的HASH算法，自己也对证书计算一个摘要HASHc，如果HASHs == HASHc，则认证通过，否则认证失败。