《HTTP协议》确保Web安全的HTTPS

HTTP 的缺点

我们已了解到 HTTP 具有相当优秀和方便的一面，然而 HTTP 并非只有好的一面，事物皆具两面性，它也是有不足之处的。HTTP 主要有这些不足：

• 通信使用明文（不加密），内容可能会被窃听
• 不验证通信方的身份，因此有可能遭遇伪装
• 无法证明报文的完整性，所以有可能已遭篡改

HTTPS是身披SSL外壳的HTTP

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL 和 TLS 协议代替而已。

通常，HTTP 直接和 TCP 通信。当使用SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了。简言之，所谓HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP。

由于 SSL 具有加密、身份验证和完整性保护的功能，相应的HTTPS也拥有了这些功能。

加密技术（防窃听）

对称加密（共享一个秘钥）

加密和解密同用一个密钥的方式称为共享密钥加密，也被叫做对称加密。以共享密钥方式加密时必须将密钥也发给对方，需要保障秘钥在转交及保管时的安全。

非对称加密（公钥和私钥）

非对称加密很好地解决了共享密钥加密的困难。非对称加密使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。

发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

另外，要想根据密文和公开密钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。

加密技术在HTTPS中的应用

HTTPS 采用对称加密和非对称加密两者并用的混合加密机制。在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。

证书（验证通信方的身份）

加密技术解决了内容被监听的问题，但是仍然无法验证通信方的身份，即通信方无从得知发送公钥给自己的另一方是否是伪装的。

为了解决上述问题，可以使用由数字证书认证中心（ CA ）颁发的数字证书。数字证书认证中心处于客户端与服务器双方都可信赖的第三方机构的立场上。

数字证书大致申请过程

1. 证书申请者首先应该生成一组私钥和 CSR （证书签名请求文件）

   CSR 是 Certificate Signing Request 的英文缩写，即证书签名请求文件。CSR 文件由公钥、通用名称 (CN), 机构名称 (O), 国家名 (C) 等字段经过编码而成（具体的编码规则暂时没查到，不需要任何其他信息，单从 CSR 文件中就可以反编码出上述信息）。

   CSR 生成工具非常多，比如 openssl ，keystore explore，XCA等。在生成 CSR 的同时还会生成一个与之对应的私钥。

2. 私钥文件由服务端持有，将 CSR 传送给认证中心

3. 认证中心在核实身份后，使用其根证书私钥对 CSR 进行签名，就生成了颁发给用户的数字证书文件

   数字证书是通过认证中心的根证书私钥加密的信息，只能通过认证中心的公钥（此公钥一般浏览器已事先植入）才能解密。

HTTPS 通信过程

1. 客户端发起请求

   客户端发起明文请求，将自己支持的一套加密规则、以及一个随机数（Random_C）发送给服务器

2. 服务端接收请求，并返回处理结果

   服务器接收客户端的请求， 选出一组加密规则和 hash 算法，并将自己的身份信息证书（CA：包含网站地址、加密公钥、证书颁发机构等信息）和一个随机数（ Random_S ）发给客户端

3. 客户端接收服务器的响应

   客户端接到服务器的响应，验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等）。

   如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。

   如果证书受信任，或者是用户接受了不受信的证书，客户端做以下事情：

   1. 生成密码：浏览器会生成一串随机数 Pre_master，并用 CA 证书里的公钥加密成密文 enc_pre_master。

   2. 计算协商密钥：enc_key=Fuc(random_C, random_S, Pre-Master)

   3. 生成握手信息：使用约定好的 HASH 计算握手消息，并使用协商密钥 enc_key 及约定好的算法对消息进行加密。

   4. 发送以下信息到服务器：

      • 随机数密文 enc_pre_master

      • 客户端发给服务器的通知，”以后我们都要用约定好的算法和协商密钥进行通信的哦”。

      • 客户端加密生成的握手信息。

4. 服务器接收客户端发来的数据要做以下四件事情：

   1. 私钥解密：使用自己的私钥从接收到的密文 enc_pre_master 中解密取出密码 Pre_master。

   2. 计算协商密钥：enc_key=Fuc(random_C, random_S, Pre-Master)

   3. 解密握手消息：使用协商密钥 enc_key 解密客户端发来的握手消息，并验证 HASH 是否与客户端发来的一致。

   4. 生成握手消息：使用协商密钥 enc_key 及约定好的算法加密一段握手消息，发送给客户端。这里要发的数据有两条：

      • 服务器发给客户端的通知，”听你的，以后我们就用约定好的算法和协商密钥进行通信哦“。

      • 服务器加密生成的握手信息。

5. 客户端拿到握手信息解密，握手结束。

   客户端解密并计算握手消息的 HASH，如果与服务端发来的 HASH 一致，此时握手过程结束。

   这里浏览器与服务器互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码和hash算法，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。

6. 正常加密通信

   握手成功之后，所有的通信数据将由之前协商密钥 enc_key 及约定好的算法进行加密解密。

从握手过程，我们可以得知：

1. 通过 CA 可以确认服务端的合法性

2. 通过 enc_key 来加密解密，在传输过程中，为了保证 enc_key 不被解破，在客户端用公钥加密后，在服务器端用私钥解密，私钥只有服务器端有，所以即使报文被截获，也无法破解。

3. hash 算法确保报文的完整性

客户端证书

HTTPS 中还可以使用客户端证书。以客户端证书进行客户端认证，证明服务器正在通信的对方始终是预料之内的客户端，其作用跟服务器证书如出一辙。

客户端证书的问题点

1. 证书的获取及发布。

   想获取证书时，用户得自行安装客户端证书。但由于客户端证书是要付费购买的，且每张证书对应到每位用户也就意味着需支付和用户数对等的费用。另外，要让知识层次不同的用户们自行安装证书，这件事本身也充满了各种挑战。

   现状是，安全性极高的认证机构可颁发客户端证书但仅用于特殊用途的业务。比如那些可支撑客户端证书支出费用的业务。

   例如，银行的网上银行就采用了客户端证书。在登录网银时不仅要求用户确认输入ID 和密码，还会要求用户的客户端证书，以确认用户是否从特定的终端访问网银。

2. 客户端证书毕竟只能用来证明客户端实际存在，而不能用来证明用户本人的真实有效性。

   也就是说，只要获得了安装有客户端证书的计算机的使用权限，也就意味着同时拥有了客户端证书的使用权限

Fildder 解密 HTTPS 的原理

Fiddler 作为中间人，接收浏览器发起的请求并转发到服务器，接收服务器返回的内容并转发到浏览器。

由前文所述的 HTTPS 原理可知，加密报文的对称秘钥是通过服务器的公钥加密的，Fiddler 没有服务器的私钥，无法获得对称秘钥，也就无法解密 HTTPS。

Fiddler 现在的做法是：接收到服务器的返回的证书，不直接转发服务器的证书，而是转发自己的另一个数字证书给浏览器，作为客户端与服务器协商秘钥，作为服务端与浏览器协商秘钥，完成秘钥协商的步骤后，继续作为客户端与服务器通信，作为服务端与浏览器通信。

Fiddler 被配置为解密 HTTPS 流量后，会自动生成一个名为 DO_NOT_TRUST_FiddlerRoot 的 CA 证书，并使用该 CA 颁发每个域名的 TLS 证书。正常情况下，DO_NOT_TRUST_FiddlerRoot 证书是不被信任的，浏览器会弹出警告。若 DO_NOT_TRUST_FiddlerRoot 证书被列入浏览器或其他软件的信任 CA 名单内，则浏览器或其他软件就会认为 HTTPS 会话是可信任的、而不会再弹出“证书错误”警告。