[网络协议]【网络协议】HTTPS

1.HTTP协议存在的问题

• 窃听风险
  由于HTTP本身不具备加密的功能，所以也无法做到对通信整体（使用HTTP协议通信的请求和响应的内容）进行加密。HTTP协议无法加密数据，所有通信数据都是明文。通过网络的嗅探设备及一些技术手段，就可还原HTTP报文内容。
• 篡改风险
  完整性是指信息的准确度，无法证明完整性意味着无法判断信息是否准确。由于HTTP协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改也没有办法知晓。
• 冒充风险
  HTTP协议中的请求和响应不会同通信方确认。在HTTP协议通信时，由于不存在确认通信方的步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应，也就是说，任何人都可以伪造虚假服务器欺骗用户。

2.什么是HTTPS

HTTPS就是在安全地传输层上发送的HTTP。HTTP安全层是通过SSL协议（Secure Sockets Layer，安全套接层）及TLS协议（Transport Layer Security，传输层安全）来实现的。可以理解为，HTTPS是HTTP加SSL/TLS。

因此，是SSL/TLS解决了HTTP协议中存在的问题。

3.什么是SSL/TLS

NetSpace公司设计并发布了SSL协议。在SSL更新到3.0时，IETF对SSL 3.0进行了标准化，并添加了少数机制，标准化后的IETF更名为TLS 1.0，可以说TLS就是SSL的3.1版本。

3.1.通信过程

1. 由客户端向服务器发起加密通信请求，即 ClientHello 请求。
   客户端发送以下信息：
   • 客户端?持的 SSL/TLS 协议版本，如 TLS 1.2 版本；
   • 客户端?产的随机数，后面用于生产会话秘钥；
   • 客户端?持的加密算法；
   • 客户端支持的压缩方法。
2. 服务器收到客户端请求后，向客户端发出回应，即 SeverHello。
   服务器回应以下信息：
   • 确认使用的加密通信协议版本，比如 TLS 1.2 版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信；
   • 一个服务器生成的随机数，稍后用于生成会话秘钥；
   • 确认使用的加密算法；
   • 服务器证书。
3. 客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，询问是否要继续通信。如果证书没问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送以下信息：
   • 一个随机数（pre-master key）。该随机数用服务器公钥加密，防止被窃听；
   • 编码改变通知，表示随后的信息都将用双方商定的加密方法和会话秘钥发送；
   • 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的摘要，用来供服务器校验。
4. 服务器收到客户端的 pre-master key 之后，计算生成本次会话所用的会话秘钥。然后，向客户端发送以下信息：
   • 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送；
   • 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来客户端与服务器进入加密通信是使用普通的HTTP协议。

3.2.如何解决HTTP中的问题

3.2.1.解决窃听

服务器采用非对称加密算法，客户端向服务器请求，服务器把公钥明文给传输客户端，客户端使用服务器的公钥进行加密处理，服务器收到被加密的信息后，再使用自己的私钥进行解密。
到此为止，仅保证了由客户端向服务器单向传输数据的安全性。却还存在两个弊端，一个是下面要提到的容易被冒充，一个是加解密耗时。对于第二点，HTTPS协议为了兼顾安全性与速度，采用的对称+非对称的结合方式。具体是怎么做的呢？
客户端向服务器请求，服务器把非对称加密的公钥 A 明文传输给客户端，客户端随机生成一个用于对称加密的密钥 B，用 A 加密后传给服务器，服务器拿到后用私钥 A’ 解密得到密钥 B，之后双方所有数据都通过密钥 B 加密解密即可。

3.2.2.解决冒充

接上一条，使用对称+非对称方式还无法解决被冒充的问题。什么是被冒充，非对称加密的公钥是公开的，如果这个非对称公钥被中间人劫持到了，那他也能用该公钥解密服务器传来的信息，进而得知对称密钥 B。这时候中间人向客户端发送了另一套信息，客户端根本无法确认收到的公钥是不是服务器自己的。那么如何解决这种冒充的问题呢？这时候引入了第三方充当“公证人”，让客户端能够确认这个公钥是不是服务器自己的，这个就是CA机构（Certificate Authority）。CA机构颁发的证书就是数字证书。
网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给客户端，客户端从证书里获取公钥即可。由此可解决中间人冒充的问题。

3.2.3.解决篡改

如果证书在传输过程中被篡改呢？要如何保证数据的完整性。这时就需要校验数字签名。

签名过程：

• CA机构将证书明文用哈希函数计算出哈希值；
• 用签名者的私钥加密哈希值，得到数字签名；
• 将数字签名添加进去，同证书明文共同构成数字证书。

验证过程：

• 拿到数字证书，得到证书明文和数字签名；
• 用CA机构的公钥解密数字签名；
• 用证书指明的哈希函数计算出哈希值；
• 比较解密的数字签名与计算的哈希值是否相等。

之所以用哈希，也是考虑到时间复杂度的问题。

3.3.TLS与SSL

SSL协议可分为两层：SSL记录协议（SSL Record Protocol）和SSL握手协议（SSL Handshake Protocol）。
SSL记录协议（SSL Record Protocol）建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
SSL握手协议（SSL Handshake Protocol）建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
SSL协议提供的服务主要有：

• 认证用户和服务器，确保数据发送到正确的客户机和服务器；
• 加密数据以防止数据中途被窃取；
• 维护数据的完整性，确保数据在传输过程中不被改变。

TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上，提供了以下增强内容：

• 更安全的MAC算法；
• 更严密的警报；
• “灰色区域”规范的更明确的定义。

TLS对于安全性的改进主要有：

• 对于消息认证使用密钥哈希：TLS 使用“消息认证代码的密钥哈希”（HMAC），当记录在开放的网络上传送时，该代码确保记录不会被变更。SSL v3.0还提供键控消息认证，但HMAC比SSL v3.0 使用的 MAC 功能更安全。
• 增强的伪随机功能（PRF）：PRF 生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。
• 改进的已完成消息验证：TLS和SSL v3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSL v3.0更安全。
• 一致证书处理：与SSL v3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。
• 特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

4.证书格式标准

4.1.公钥证书格式标准X.509

X.509是密码学里的公钥证书格式标准，定义了公钥证书结构的基本标准。X.509 v3数字证书结构如下：
证书
– 公钥算法
– 主题公钥
– 此日期前无效
– 此日期后无效
– 版本号
– 序列号
– 签名算法
– 颁发者
– 证书有效期
– 主题
– 主题公钥信息
– 颁发者唯一身份信息（可选项）
– 主题唯一身份信息（可选项）
– 扩展信息（可选项）
– …
证书签名算法
数字签名

4.2.公钥密码学标准PKCS

PKCS是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。
到1999年底，PKCS已经公布了15个标准，其编号分别为PCKS#1~15。其中比较常用的有PKCS#1, PKCS#7, PKCS#8以及PKCS#12。虽然叫公钥，但是他的标准里也规定了私钥的格式，其中PKCS#8就是私钥的格式标准。PKCS#12定义了包含私钥与公钥证书的文件格式。

4.3.证书文件格式