HTTP可能存在信息窃听或身份伪装等安全问题，使用HTTPS通信机制可以有效防止这些问题

7.1 HTTP的缺点

缺点举例：

  • 通信使用明文，内容可能被窃听
  • 不验证通信方的身份，可能被伪装
  • 无法证明报文的完整性，可能被篡改

7.1.1 通信使用明文可能被窃听

HTTP 报文使用明文(指未经过加密的报文)方式发送。

  • TCP/IP是可能被窃听的网络：因为TCP/IP协议族的通信线路上哪个部分都可能被窥视，不可能要求所有网络设备加密，所以报文本身是会被看到的
  • 加密处理防止被窃听：保护信息的对策最为普及的就是加密技术，可被加密的对象有这么几个：
    • 通信加密：通过SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全层传输协议）的组合使用加密HTTP的通信内容

通过SSL建立安全通信线路之后，在这条线路上进行HTTP通信，这个组合叫做HTTPS（HTTP Secure）超文本传输安全协议
第7章 确保Web安全的HTTPS - 图1

  • 内容加密：把HTTP报文里所含的内容进行加密处理，前提是要求客户端和服务器同时具备加密和解密的机制，但这样仍有内容被篡改的风险

7.1.2 不验证通信方的身份就可能遭到伪装

a. 任何人都可以发起请求

http里没有确认通信方的处理步骤，也就是说，服务器只要接收请求，就会返回一个响应（除非服务器设定对发送端IP和端口的访问限制）

因为不确认发送方会存在以下隐患：

  • 可能有伪装的Web服务器， 不按照真实意图返回响应
  • 可能是伪装的客户端
  • 无法确认正在通信的对方是否具有访问权限
  • 无法判断请求来自何方
  • 无意义的请求也照单全收，DoS（Denial of Service，拒绝服务攻击）

b. 需要查明对方的证书

第7章 确保Web安全的HTTPS - 图2

证书由值得信任的第三方机构颁发，用以证明服务器和客户端是 实际存在的。另外，伪造证书从技术角度来说是异常困难的一件 事。所以只要能够确认通信方(服务器或客户端)持有的证书， 即可判断通信方的真实意图。

7.1.3 无法证明报文完整性，可能被篡改

  • 接收到的内容可能有误

没有任何办法确认，发出的请求 / 响应和接收到的请 求 / 响应是前后相同的。

请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击(Man-in-the-Middle attack，MITM)。

第7章 确保Web安全的HTTPS - 图3

  • 如何防止篡改

常用的是MD5和SHA-1等散列值校验的方法确认文件的数字全名，但也不是保证完整性的，因 为 PGP 和 MD5 本身被改写的话，用户是没有办法意识到的。

使用HTTPS提供认证+加密处理+摘要功能

7.2 HTTP + 加密 + 认证 + 完整性保护 = HTTPS

第7章 确保Web安全的HTTPS - 图4

7.2.2 HTTPS是身披SSL外壳的HTTP

HTTP 直接和 TCP 通信。

当使用 SSL 时，则演变成先和 SSL 通 信，再由 SSL 和 TCP 通信了。

简言之，所谓 HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP。

第7章 确保Web安全的HTTPS - 图5

SSL是独立于HTTP的协议，其他应用层协议也可以配合SSL协议使用，是世界上应用最为广泛的网络安全技术

7.2.3 相互交换密钥的公共密钥加密技术

谈SSL之前，先讲一下加密方法，SSL使用的是一种公开密钥加密

  • 共享密钥加密的困境

加密和解密同用一个密钥的方式称为共享密钥加密(Common key crypto system)，也被叫做对称密钥加密。

以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能 安全地转交?在互联网上转发密钥时，如果通信被监听那么密钥 就可会落入攻击者之手，同时也就失去了加密的意义，还得安全的保管收到的密钥

  • 使用两把密钥的公开密钥加密

它使用一对非对称的密钥，一把作为私钥，另一个叫做公开密钥，

第7章 确保Web安全的HTTPS - 图6

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥 (private key)，另一把叫做公开密钥(public key)。顾名思 义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发 布，任何人都可以获得。

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

另外，要想根据密文和公开密钥，恢复到信息原文是异常困难 的，因为解密过程就是在对离散对数进行求值，这并非轻而易举 就能办到。退一步讲，如果能对一个非常大的整数做到快速地因 式分解，那么密码破解还是存在希望的。但就目前的技术来看是 不太现实的。

  • https采用混合加密机制

https采用共享密钥加密和公开密钥加密两者并用的混合加密机制

7.2.4 证明公开密钥正确性的证书

遗憾的是，公开密钥加密方式还是存在一些问题的。那就是无法证明 公开密钥本身就是货真价实的公开密钥。比如，正准备和某台服务器 建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原 本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真 正的公开密钥已经被攻击者替换掉了。

为了解决上述问题，可以使用由数字证书认证机构(CA，Certificate Authority)和其相关机关颁发的公开密钥证书。

首先，服务器 的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证 机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。

服务器会将这份数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信

接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事:

  1. 认证服务器的公开密钥的是真实有效的数字证书认证机构
  2. 服务器的公开密钥是值得信赖的。

。。。。

7.2.5 HTTPS的安全通信机制

第7章 确保Web安全的HTTPS - 图7

步骤 1: 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件(Cipher Suite)列表(所使用的加密算法及密钥长度等)。

步骤 2: 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。

步骤 3: 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。

步骤 4: 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。

步骤 5: SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。

步骤 6: 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。

步骤 7: 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确 解密该报文作为判定标准。

步骤 8: 服务器同样发送 Change Cipher Spec 报文。 步骤 9: 服务器同样发送 Finished 报文。

步骤 10: 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接 就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用 层协议的通信，即发送 HTTP 请求。

步骤 11: 应用层协议通信，即发送 HTTP 响应。

步骤 12: 最后由客户端断开连接。断开连接时，发送 close_notify 报 文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP 的通信。

在以上流程中，应用层发送数据时会附加一种叫做 MAC(Message Authentication Code)的报文摘要。MAC 能够查知报文是否遭到篡 改，从而保护报文的完整性。

ps

1. SSL速度慢吗？

第7章 确保Web安全的HTTPS - 图8

两方面的慢：

  • 通信慢
  • 大量消耗CPU和内存资源，导致处理速度变慢

和HTTP相比，网络负载可能慢2到100倍，因为必须进行SSL通信以及SSL的加密处理

2. 为什么不一直使用HTTPS？

因为加密通信消耗更多CPU及内存资源，所以非敏感信息使用HTTP通信，只有在包含个人信息等敏感数据时再使用HTTPS加密通信

第7章 确保Web安全的HTTPS - 图9

节约购买证书也是原因之一，必须想CA购买，一年的授权要600多人民币

知乎上对https的文章