含义:

咱们通常所说的 HTTPS 协议,说白了就是“HTTP 协议”和“SSL/TLS 协议”的组合。你可以把 HTTPS 大致理解为——“HTTP over SSL”或“HTTP over TLS”,而SSL和TSL就是HTTPS的加密机制.

基本流程:

(1) 客户端向服务端索要并验证公钥。
(2) 双方协商生成"对话密钥"。
(3) 双方采用"对话密钥"进行加密通信。

前两个阶段称为"握手阶段"

握手阶段详解:

  1. 首先由客户端发出加密通信请求。在这一阶段,客户端要向服务器提供一下信息:
a. 支持的协议版本。(如: TLS1.0, SSL3.0等);
b. 客户端生成随机数,用于生成"对话密钥".
c. 支持的加密方法.
d. 支持的压缩方法。
  1. 服务器收到客户端的信息后,向客户端返回信息,内容如下:
 a. 确认使用的加密通信协议版本。如果浏览器与服务器支持的版本不一致,服务器关闭加密通信。
 b. 一个服务器生成的随机数,稍后用于生成"对话密钥"。
 c. 确认使用的加密方法。
 d. 服务器证书(数字证书,一般为了保证安全会有一个专门的CA机构签发)。

ps: 除了上面这些信息,如果服务器需要确认客户端的身份,就会再包含一项请求,要求客户端提供"客户端证书"。比如,金融机构往往只允许认证客户连入自己的网络,就会向正式客户提供USB密钥,里面就包含了一张客户端证书

  1. 客户端收到服务器回应以后,首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期,就会向访问者显示一个警告,由其选择是否还要继续通信。如果证书没有问题,客户端就会从证书中取出服务器的公钥。然后,向服务器发送下面三项信息。
a. 一个随机数(pre-master-key)。该随机数用服务器公钥加密,防止被窃听。
b. 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。
c. 客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供服务器校验。

上面a项的随机数加上之前的两个随机数,用这三个随机数来生成"对话密钥"。至于为什么要用到三个随机数,原因如下:

"不管是客户端还是服务器,都需要随机数,这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的,因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来说,pre-master-key本身就是一个随机数,再加上hello消息中的随机,三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数,如果随机数不随机,那么pre master secret就有可能被猜出来,那么仅适用pre master secret作为密钥就不合适了,因此必须引入新的随机因素,那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了,一个伪随机可能完全不随机,可是是三个伪随机就十分接近随机了,每增加一个自由度,随机性增加的可不是一。"
  1. 服务器收到客户端的第三个随机数pre-master key之后,计算生成本次会话所用的"会话密钥"。然后,向客户端最后发送下面信息。
(1)编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。
(2)服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供客户端校验。

至此,整个握手阶段全部结束。接下来,客户端与服务器进入加密通信,就完全是使用普通的HTTP协议,只不过用"会话密钥"加密内容。

私钥的作用:

服务器有公钥和私钥,如上所述,在握手的过程中,会把公钥,通过数字证书传给客户端。客户端再通过公钥生成第三个随机数。

上面所提到的握手之后的"会话密钥",是对称加密,而服务器的公钥和私钥只用于加密和解密"对话密钥"(非对称加密),无其他作用。整个对话过程中(握手阶段和其后的对话),服务器的公钥和私钥只需要用到一次。紧记,公钥加密后基本上只有私钥能解密了。

参考

  1. http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html