我理解的 HTTP/HTTPS.png
最近又把好久以前看的关于 HTTP/HTTPS 相关的资料翻了一遍，对于之前理解不到位的地方有了一点深入的理解，在此记录一下。
下面主要来讨论一下 HTTP 的不足、HTTPS是什么以及为什么建议使用HTTPS。
HTTP
我们都知道，HTTP 是属于应用层的一个非常常用的协议，目前的最新版本应该是 HTTP2.0，不过很多服务端依然还停留在 HTTP1.1（我们公司就是）。这里，不对其做过多说明，相信大家已经很熟悉了，主要看看它的3个明显的不足点：
1.通信使用明文，内容可能被窃听；
- HTTP 本身不具备加密功能，即使所谓的 POST 方法也不是，他只是将请求参数从 URL 移到了请求体里边，实际还是明文传输。
2.不验证通信方的身份，因此有可能遭遇伪装；
- HTTP 协议的实现本身非常简单，不论是谁发送过来的请求都会返回响应。
3.无法证明报文的完整性，所以有可能已遭篡改。
- 所谓完整性是指信息的准确度。在请求/响应发送出去之后直到对方接收之前的这段时间里，如果遭到篡改，接收方也无法获悉。
其实，这些问题不仅在 HTTP 上出现，其它未加密的协议中也会存在这类问题。
HTTPS (HTTP over SSL 或 HTTP over TLS)
HTTP + 加密 + 认证 + 完整性保护 == HTTPS
为了解决使用 HTTP 协议时存在的这些问题，需要在 HTTP 上再加入加密处理、认证和完整性保护机制，这样的 HTTP 就称为 HTTPS。
HTTPS 并非是应用层的一种新协议。而是在 HTTP 与 TCP 的通信接口部分用 SSL 或 TLS 协议代替而已。
注：SSL 或 TLS 协议是独立于 HTTP 的协议，所以不光是 HTTP 协议，其它运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。
先来看看HTTPS 的主要通信步骤(省略了部分细节)：
- 客户端 发送报文开始 SSL 通信。报文中包含 客户端支持的 SSL 版本、加密组件列表；
- 服务端 应答。报文内容包含 SSL 版本以及从加密组件(从客户端发来的列表中筛选出来的)；
- 服务端 继续发送 证书 (Certificate) 报文。也就是服务端的(公钥)证书；
- 客户端 验证证书之后，利用里边的公钥 (public key) 加密一个随机密码串发送给服务端（非对称加密）；
- 服务端 使用私钥 (private key) 解密报文得到那组随机密码串，然后与客户端互发报文确认：之后的报文就用这个随机密码串加密；
- 至此，SSL 连接就算建立完成了；
- 正常的通信(使用对称加密)，即发送 HTTP 请求及响应；
- 最后，客户端与服务端互发断开连接的报文，结束通信。
以上流程中，应用层发送数据时，会附加一种叫做 MAC (Message Authentication Code) 报文摘要，用来检测报文是否遭到篡改，从而保护报文的完整性。
下面是对整个流程的图解 (仅使用服务器证书的情况)：
HTTPS通信步骤-仅使用服务端证书.png
补充1：
CBC 模式（Cipher Block Chaining）又名密码分组模式或密码块链，是对称加密的一种模式，使用一个密钥和一个初始化向量对数据进行加密。
在此模式下，将前一个明文块加密处理后和下一个明文块做 异或 (XOR) 运算，使之重叠，然后再对运算结果做加密处理。对第一个明文块加密时，要么使用前一段密文的最后一块，要么利用外部生成的初始向量。
简单说，CBC 模式要求，首先将明文数据分块，然后逐块分别进行加密，对后一块数据的加密需要依赖前一块数据，而第一块数据就需要依赖初始向量了，如下图所示。
对称加密-CBC.png
补充2：
很多人可能会有一个疑问，经常听说 3 次握手和 4 次挥手，那么在 HTTPS 中建立连接及断开连接时会进行这些操作吗？
答案是肯定的，依然会执行 3 次握手和 4 次挥手，因为这是建立和断开 TCP 连接时必须的操作，而 TCP 属于传输层的协议，与应用层无关。
说完了基本的流程，下面对各个细节做一个深入讨论：
1.SSL 和 TLS
SSL 协议最初由网景通信公司倡导，目前主导权已转移至 IETF(Internet 工程任务组) 的手中，IETF 以 SSL3.0 为基准，又制定了 TLS 协议。
SSL 使用公开密钥加密(非对称加密)的处理方式。
先说说对称加密，在这种方式中，加密和解密采用同一个密钥，那就必须将秘钥发送给对方，可是发送过程有可能被监听，导致密码泄露。
对称加密的不足.png
公开密钥加密方式解决了共享密钥加密的困难。它使用一对非对称的密钥。一把叫做私钥 (private key)，不能让其他人知道；一把叫做公钥 (public key)，可以随意发布，任何人都可以获得。
使用公开密钥加密方式，发送密文的一方使用对方的公钥进行加密，对方收到被加密的信息后，再使用自己的私钥解密。这样，不需要发送用来解密的私钥，也不必担心密钥被攻击者窃听而盗走。
另外，要想根据秘闻和公钥恢复到原来的明文，就目前的技术来看是异常困难的。
公开密钥加密-对称加密.png
2.HTTPS 采取混合加密机制
共享秘钥加密方式在交换密钥阶段容易被窃听导致密钥泄露，但处理速度快；公开密钥加密方式相对安全，但是处理速度却慢很多，效率就很低。
HTTPS 充分采用共享秘钥加密和公开密钥加密两者各自的优势，将其组合起来用于通信，在交换密钥环节使用共享秘钥加密方式，之后建立通信交换报文阶段则使用共享秘钥加密方式。
HTTPS 采取混合加密机制.png
不过，公开密钥加密方式无法证明公钥本身就是货真价实的公钥，为了解决这个问题，可以使用数字证书认证机构（CA，Certificate Authority）颁发的公开密钥证书（数字证书）。
利用数字证书证明公钥真实性.png
-
服务器 将自己的公钥发送给 CA ，CA 用自己的私钥给服务器的公钥签名并颁发公钥证书(公钥证书内含：服务器的公钥 + CA的数字签名 + 各种信息)；
-
客户端 拿到服务器的公钥证书后，利用 CA 的公钥验证公钥证书上的数字签名(怎么验证？用 CA 的公钥对 CA 的数字签名进行解密，得到摘要，根据信息自己计算一个摘要，对二者进行比较来验证证书有效性)；
-
证明了证书有效性，那么公钥就是有效的，然后客户端就可以使用此公钥加密，服务器端使用对应的私钥解密了。
3.使用 HTTPS 的注意事项
既然 HTTPS 那么安全可靠，为什么不一直使用 HTTPS ？
其中一个原因是因为与明文通信相比，加密通信会消耗更多的 CPU 及内存资源。因此如果是非敏感信息则使用 HTTP 通信，只有在包含个人敏感数据时，采利用 HTTPS 加密通信。
HTTPS比HTTP慢2到100倍.png
除此之外，想要节约购买证书的开销也是原因之一。要进行HTTP通信，证书是必不可少的。而使用的证书必须向认证机构 （CA）购买。那些购证书并不核算的服务以及一些个人网站，可能只会选择采用 HTTP 的通信方式。
对于 iOS 开发者来说，Apple 推荐的是使用 HTTPS 通信，曾经还给了一个切换 HTTPS 的最后期限，过时未切换的话 App 会被下架，不过最后有不了了之了。
网友评论