「开位」你所应该知道的HTTP——HTTPS篇

前言

接上篇，HTTPS是现代平常使用十分频繁的HTTP相关技术，但自己原理上与HTTP的关系并不大，而且可讲内容也比较多，故独立成单独一章讲解。

概述

HTTPS全称Secure Hypertext Transfer Protocol（安全超文本传输协议），是一个安全通讯通道，用于在客户计算机和服务器之间交换信息。它使用安全套接字层进行信息交换，简单来讲它是HTTP的安全版，是使用TLS/SSL加密的HTTP协议。

HTTPS = HTTP + TLS/SSL

HTTP协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议TLS/SSL具备身份验证、信息加密和完整性校验的功能，能够避免此类问题发生。
TLS全称Transport Layer Security（安全传输层协议）, 前身是SSL，故如今用TLS/SSL统称。是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，因此使用HTTPS基本上不须要对HTTP页面进行太多的改造。

套用在TCP/IP四层模型里的结构以下：

TLS/SSL原理

TLS/SSL的功能实现主要依赖于三类基本算法：散列函数（Hash）、对称加密和非对称加密。
其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

TLS/SSL = 非对称加密 + 对称加密 + 散列算法

非对称加密

加密和解密使用不一样密钥的加密算法，也称为公私钥加密。密钥成对出现，通常称为公钥（publickey）和私钥（privatekey），公钥加密的信息只能私钥解开，私钥加密的信息只能公钥解开。即服务器持有私钥，客户端持有公钥，客户端要发送的信息通过公钥加密后传递给服务器，服务器用私钥解密获得明文信息。

特色：

• 能够实现1对多的通讯；
• 保密性比较好，只有公钥须要被传递，故私钥被劫持的几率很低；
• 安全性高，保密性保证私钥安全，所以安全性仅依赖于算法自己；
• 计算复杂，加密速度慢。

在TLS/SSL中，非对称加密仅用于“身份认证”和“密钥协商”，不在后续正文数据传输中使用，这是安全性与性能之间的平衡取舍。

对称加密

加密和解密使用相同密钥的加密算法。即客户端与服务器所持有的密钥是相同的，客户端要发送的信息通过密钥加密后传递给服务器，服务器用相同密钥解密获得明文信息。

特色：

• 通讯方式是1对1，为了足够安全，服务器和N个客户端通讯，须要维持N个密码记录；
• 安全性不只取决于加密算法自己，密钥管理的安全性更是重要；
• 计算量小、加密速度快、加密效率高；
• 缺乏吊销和修改密钥的机制。

在TLS/SSL中，对称加密的密钥是经过非对称加密的“密钥协商”产生的，这样就最大限度的保证了密钥的安全。因为其效率高的特色，正文数据传输使用了该加密方式。

散列函数（Hash）

一种将任意长度的消息压缩到某一固定长度的消息摘要的函数，经常使用于防止信息篡改并验证数据的完整性。

特色：

• 单向不可逆；
• 对输入很是敏感，即一点输入的改变都会致使结果不一样；
• 输出长度固定。

在信息传输过程当中，散列函数不能单独实现信息防篡改，由于明文传输，中间人能够修改信息以后从新计算信息摘要，所以须要对传输的信息以及信息摘要进行加密。
在TLS/SSL中，“密钥协商”的最后步骤和传输正文信息都会带上散列函数计算出的信息摘要，他们一块儿通过对称加密后传输，用来验证完整性。

PKI体系

非对称加密的隐患

前面讲到“身份验证”和“密钥协商”是TLS/SSL的基础功能，要求的前提是合法的服务器掌握着对应的私钥。但非对称加密算法没法确保服务器身份的合法性，由于公钥并不包含服务器的信息。
假定出现如下的状况：

• 客户端C和服务器S进行通讯，中间节点M截获了两者的通讯;
• 节点M本身计算产生一对公钥pub_M和私钥pri_M;
• C向S请求公钥时，M把本身的公钥pub_M发给了C;
• C使用公钥pub_M加密的数据可以被M解密，由于M掌握对应的私钥pri_M，而C没法根据公钥信息判断服务器的身份，从而C和M之间创建了"可信"加密链接。

如图，中间节点M和服务器S之间再创建合法的链接，所以C和S之间通讯被M彻底掌握，M能够进行信息的窃听、篡改等操做，这类攻击被称为“中间人攻击”。

身份验证CA和证书

为了解决上述的隐患，关键是确保获取公钥途径是合法的，可以验证服务器的身份信息，为此须要引入权威的第三方机构CA。
CA全称Certificate Authority（证书颁发机构），它负责核实公钥的拥有者的信息，并颁发认证"证书"，同时可以为使用者提供证书验证服务，即PKI体系。

证书 = 公钥 + 申请者与颁发者信息 + 有效时间 + 域名信息 + 签名

CA认证流程以下：

客户端会内置信任CA的证书信息（包含公钥），若是CA不被信任，则找不到对应CA的证书，证书也会被断定非法。
也能够这样理解，网站千千万，浏览器厂商没办法一家一家去认证，因而跟CA合做，经过维护一个CA列表，只要网站有通过这个列表里CA的认证，就能够信任该网站的证书。

TLS/SSL握手过程

TLS/SSL握手过程也就是所谓的HTTPS四次握手（不含证书验证步骤）。

1. 客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数random_C（明文），扩展字段等信息。
2. 服务端返回协商的信息结果，随机数random_S（明文），证书链等。
3. 对证书进行验证，包括证书可信性、有效性等，可能须要联系CA。

4. 细分为四步：

   1. client_key_exchange：客户端计算产生随机数字Pre-master，并用证书公钥加密，发送给服务器;
   2. 客户端根据random_C、random_S以及Pre-master，计算获得协商密钥enc_key（即对称加密用的密钥）；
   3. change_cipher_spec：客户端通知服务器后续的通讯都采用协商的通讯密钥和加密算法进行加密通讯;
   4. encrypted_handshake_message：结合以前全部通讯参数的hash值与其它相关信息生成一段数据，采用协商密钥enc_key进行加密，而后发送给服务器用于数据与握手验证;

5. 细分为四步：

   1. 服务器使用私钥解密Pre-master，根据random_C、random_S以及Pre-master，计算获得协商密钥enc_key；
   2. 计算以前全部接收信息的hash值，而后解密客户端发送的encrypted_handshake_message，验证数据和密钥正确性；
   3. change_cipher_spec：验证经过以后，服务器一样发送change_cipher_spec以告知客户端后续的通讯都采用协商的密钥与算法进行加密通讯;
   4. encrypted_handshake_message：服务器也结合全部当前的通讯参数信息生成一段数据并采用协商密钥enc_key加密并发送到客户端;
6. 握手结束，开始使用协商密钥enc_key进行对称加密通讯（包含hash完整性验证）。

示意图以下：

HTTPS的使用成本

• 证书费用及维护更新
  通常正规CA颁发的证书都是须要付费购买的，而且到期后还得续费。
• 增长了访问延迟
  分析前面的握手过程，一次完整的握手至少须要两端依次来回两次通讯，至少增长延时2RTT，利用会话缓存从而复用链接，延时也至少1RTT。
• 消耗较多CPU资源
  加解密是须要消耗性能的，前面也有提到非对称加密的特色，所以会成为性能瓶颈。

HTTPS的优化

TLS False Start

在TLS/SSL协商第二阶段，也就是浏览器生成最后一个随机数并用公钥加密发送给服务器后，当即发送加密的应用层数据，而无需等待服务器的确认。

Session Identifier（会话标识符）

若是用户的一个业务请求包含了多条的加密流，客户端与服务器要反复握手，一定致使更多的时间损耗。或某些特殊状况致使会话中断，须要从新握手。
服务器为每一次的会话生成并记录一个sessionId，发送给客户端，客户端从新链接只须要提供这个id，不须要从新握手。

OCSP Stapling

OCSP全称Online Certificate Status Protocol。由web服务器向OCSP server周期性地查询证书状态，得到一个带有时间戳和签名的OCSP response并缓存它。当有客户端发起请求时，web服务器会把这个response在TLS握手过程当中发给客户端。
（谷歌浏览器默认只使用内置列表检查，故这个优化对谷歌无效）

HSTS（HTTP Strict-Transport-Security）

一个报文头部字段，告诉浏览器，接下来的一段时间内，当前域名(及其子域名)的后续通讯应该强制性使用HTTPS，直到超过有效期为止。

形如：

Strict-Transport-Security: max-age=31536000;includeSubDomains