Skip to main content

HTTP、HTTPS 协议

HTTP 协议​

HTTP（Hyper Text Transfer Protocol，超文本传输协议），是一种基于 TCP/IP 的应用层通信协议，这个协议详细规定了浏览器和万维网之间互相通信的规则。

HTTP 协议通过请求和响应的方式，在客户端和服务端之间进行通信。

HTTP 协议的信息传输完全以明文方式，不做任何加密，不够安全。

由于传输信息是明文，这个信息有可能被某个中间人恶意拦截甚至篡改。这种行为就是中间人攻击。

可以提前约定一种对称加密方式，并且约定一个随机生成的密钥。后续通信中，信息发送方都使用密钥对信息加密，而信息接收方通过同样的密钥对信息解密。但是第一次约定加密方式和密钥的通信仍然是明文，如果第一次通信就被拦截了，那么密钥就会泄露给中间人，中间人仍然可以解密后续所有的通信内容。

这时可以使用非对称加密，为密钥的传输做一层额外的保护。非对称加密的一组密钥对中，包含一个公钥和一个私钥。明文既可以用公钥加密，用私钥解密，也可以用私钥加密，用公钥解密。具体做法是：

  1. A 向 B 发起通信请求
  2. B 将自己的公钥 key1 发给 A
  3. A 接收到 key1 后，生成一个用于对称加密的密钥 key2，用 key1 将 key2 进行加密，发送给 B
  4. B 用自己的私钥解开了自己的公钥 key1，获得了 key2 的内容
  5. 后续就可以利用 key2 进行对称加密的通信了

即使中间人在一开始就截获了公钥 key1，由于不知道私钥，也无法解密。

这样真的安全吗？不安全。

  1. 因为中间人可以在截获了 B 的公钥 key1 后，自己伪造一份公钥私钥，将自己的公钥 key3 发给 A
  2. A 在不知情的情况下用 key3 将 key2 加密，发送给 B
  3. 中间人再次截获这次通信，用自己的私钥解开 key3，获得了 key2，然后用 key1 重新加密，发送给 B
  4. 这样中间人就获取到了对称加密的密钥 key2，后续通信都可以解密

这时候可以引入一个权威的证书颁发机构（CA）

  1. 作为服务端的 B，首先把自己的公钥发给证书颁发机构，向证书颁发机构申请证书
  2. 证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密 Key1，并且通过服务端网址等信息生成一个证书签名，证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送给了服务端 B
  3. 当 A 向 B 请求通信的时候，B 不再直接返回自己的公钥，而是把自己申请的证书返回给 A
  4. A 收到证书以后，首先要验证证书的真伪。需要说明的是，各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥。所以 A 只需要知道是哪个机构颁布的证书，就可以从本地找到对应的机构公钥，解密出证书签名
  5. A 按照同样的签名规则，自己也生成一个证书签名，如果两个签名一致，说明证书是有效的
  6. 验证成功后，A 就可以放心地再次利用机构公钥，解密出服务端 B 的公钥 Key1
  7. 像之前一样，A 生成自己的对称加密密钥 Key2，并且用服务端公钥 Key1 加密 Key2，发送给 B
  8. 最后，B 用自己的私钥解开加密，得到对称加密密钥 Key2。于是就可以用 Key2 进行对称加密的通信

http 协议默认端口是 80，https 协议默认端口是 443

端口是应用程序的数字标识，主要作用是实现了不同主机应用程序之间的通信

HTTP2.0 协议​

HTTPS 协议​