HTTPS 攻略

复制粘贴改改改
121 阅读13分钟

攻略大全

1. 粘贴攻略

1.1 计算机网络体系结构

1.1.1 简介

定义：计算机网络的各层+其协议的组合

作用：定义该计算机网络所能完成的功能

1.1.2 结构介绍

计算机网络体系结构分为3种：OSI体系结构、TCP / IP体系结构、五层体系结构

OSI体系结构：概念清楚、理念完整，但是复杂且不实用

TCP/IP体系结构：包含了一系列构成互联网基础的网络协议，是Internet的核心协议，被广泛应用于局域网和广域网。

五层体系结构：融合了OSI与TCP/IP的体系结构，目的是为了学习与讲解计算机原理。

image.png

1.1.2.1 详解TCP/IP

944365-429360cb75ec4cef.png

944365-67e745b520aaf63b.png

1.1.2.2 详解OSI

944365-528b5fa6679a99c6.png

944365-5278b003549ed53a.png

1.2 HTTPS

HTTPS 是超文本传输安全协议，即HTTP + SSL/TLS。说白了，就是一个加强版的HTTP。所以我们要理解HTTPS的精华，就要先弄清楚这个SSL/TLS。

1.2.1 SSL/TLS

TLS是SSL的升级版，而且TLS1.2版本以下都已废弃，目前主要用的是TLS 1.2和TLS 1.3，而OpenSSL则是开源版本的。

那么它到底是个啥呢？

浏览器和服务器通信之前会先协商，选出它们都支持的加密套件，用来实现安全的通信。

随便拿出一个加密套件举例，如：RSA-PSK-AES128-GCM-SHA256：

  • RSA：表示握手时用RSA算法交换密钥
  • PSK：表示使用PSK算法签名
  • AES128-GCM：表示使用AES256对称加密算法通信，密钥长度128，分组模式GCM。TLS 1.3中对称加密算法只剩下AES和CHACHA20，分组模式只剩下GCM和POLY1305
  • SHA256：表示使用SHA256算法验证信息完整性并生成随机数。TLS 1.3中哈希摘要算法只剩下SHA256和SHA384了

为什么需要用到这么多算法呢？

为了保证安全，TLS需要保证信息的：机密性、可用性、完整性、认证性、不可否认性，每一种算法都有其特定的用处。

1.2.2 HTTPS 中 TLS 的加密算法

对称加密算法

就是加密和解密使用同一个密钥。如AES、DES。加解密过程：

  1. 浏览器给服务器发送一个随机数client-random和一个支持的加密方法列表
  2. 服务器给浏览器返回另一个随机数server-random和双方都支持的加密方法
  3. 然后两者用加密方法将两个随机数混合生成密钥，这就是通信双上加解密的密钥

问题是双方如何安全的传递两个随机数和加密方法，直接传给客户端，那过程中就很可能被窃取，别人就能成功解密拿到数据。

不对称加密算法

就是一对密钥，有公钥(public key)和私钥(private key)，其中一个密钥加密后的数据，只能让另一个密钥进行解密。如RSA、ECDHE。加解密过程：

  1. 浏览器给服务器发送一个随机数client-random和一个支持的加密方法列表
  2. 服务器把另一个随机数server-random、加密方法、公钥传给浏览器
  3. 然后浏览器用公钥将两个随机数加密，生成密钥，这个密钥只能用私钥解密

使用公钥反推出私钥是非常困难，但不是做不到，随着计算机运算能力提高，非对称密钥至少要2048位才能保证安全性，这就导致性能上要比对称加密要差很多。

所以，TLS实际用的是两种算法的混合加密。通过 非对称加密算法 交换 对称加密算法 的密钥，交换完成后，再使用对称加密进行加解密传输数据。这样就保证了会话的机密性。 过程如下：

  1. 浏览器给服务器发送一个随机数client-random和一个支持的加密方法列表
  2. 服务器把另一个随机数server-random、加密方法、公钥传给浏览器
  3. 浏览器又生成另一个随机数pre-random，并用公钥加密后传给服务器
  4. 服务器再用私钥解密，得到pre-random
  5. 浏览器和服务器都将三个随机数用加密方法混合生成最终密钥

这样即便被截持，中间人没有私钥就拿不到pre-random，就无法生成最终密钥。

可又有问题来了，如果一开始就被DNS截持，我们拿到的公钥是中间人的，而不是服务器的，数据还是会被窃取，所以数字证书来了。

摘要算法

主要用于保证信息的完整性。常见的MD5算法、散列函数、哈希函数都属于这类算法，其特点就是单向性、无法反推原文。

假如信息被截取，并重新生成了摘要，这时候就判断不出来是否被篡改了，所以需要给摘要也通过会话密钥进行加密，这样就看不到明文信息，保证了安全性，同时也保证了完整性。

1.2.3 如何保证数据不被篡改？签名原理和证书?

数字证书(数字签名)

它可以帮我们验证服务器身份。因为如果没有验证的话，就可能被中间人劫持，假如请求被中间人截获，中间人把他自己的公钥给了客户端，客户端收到公钥就把信息发给中间人了，中间人解密拿到数据后，再请求实际服务器，拿到服务器公钥，再把信息发给服务器。

这样不知不觉间信息就被人窃取了，所以在结合对称和非对称加密的基础上，又添加了数字证书认证的步骤，让服务器证明自己的身份。

数字证书需要向有权威的认证机构(CA)获取授权给服务器。首先，服务器和CA机构分别有一对密钥(公钥和私钥)，然后是如何生成数字证书的呢？

  • CA机构通过摘要算法生成服务器公钥的摘要(哈希摘要)
  • CA机构通过CA私钥及特定的签名算法加密摘要，生成签名
  • 把签名、服务器公钥等信息打包放入数字证书，并返回给服务器

服务器配置好证书，以后客户端连接服务器，都先把证书发给客户端验证并获取服务器的公钥。

证书验证流程：

  • 使用CA公钥和声明的签名算法对CA中的签名进行解密，得到服务器公钥的摘要内容
  • 再用摘要算法对证书里的服务器公钥生成摘要，再把这个摘要和上一步得到的摘要对比，如果一致说明证书合法，里面的公钥也是正确的，否则就是非法的。

证书认证又分为单向认证和双向认证

单向认证：服务器发送证书，客户端验证证书

双向认证：服务器和客户端分别提供证书给对方，并互相验证对方的证书

不过大多数https服务器都是单向认证，如果服务器需要验证客户端的身份，一般通过用户名、密码、手机验证码等之类的凭证来验证。只有更高级别的要求的系统，比如大额网银转账等，才会提供双向认证的场景，来确保对客户身份提供认证性。

1.2.4 HTTPS 连接过程和优化

我们知道了https就只是比http多了一步TLS连接，TLS连接是怎么回事呢，根据TLS版本和密钥交换法不同，过程也不一样，有三种方式：

1.2.4.1 RSA握手

早期的TLS密钥交换法都是使用RSA算法，它的握手流程是这样子的

  1. 浏览器给服务器发送一个随机数client-random和一个支持的加密方法列表
  2. 服务器把另一个随机数server-random、加密方法、公钥传给浏览器
  3. 浏览器又生成另一个随机数pre-random，并用公钥加密后传给服务器
  4. 服务器再用私钥解密，得到pre-random，此时浏览器和服务器都得到三个随机数了，各自将三个随机数用加密方法混合生成最终密钥，然后开始通信

1.2.4.2 TLS 1.2 版

TLS 1.2版的用的是ECDHE密钥交换法：

  1. 浏览器给服务器发送一个随机数client-random、TLS版本和一个支持的加密方法列表
  2. 服务器生成一个椭圆曲线参数server-params、随机数server-random、加密方法、证书等传给浏览器
  3. 浏览器又生成椭圆曲线参数client-params，握手数据摘要等信息传给服务器
  4. 服务器再返回摘要给浏览器确认应答

这个版本不再生成椭圆曲线参数cliend-params和server-params，而是在服务器和浏览器两边都得到server-params和client-params之后，就用ECDHE算法直接算出pre-random，这就两边都有了三个随机数，然后各自再将三个随机加密混合生成最终密钥

1.2.4.3 TLS 1.3版

在TLS1.3版本中废弃了RSA算法，因为RSA算法可能泄露私钥导致历史报文全部被破解，而ECDHE算法每次握手都会生成临时的密钥，所以就算私钥被破解，也只能破解一条报文，而不会对之前的历史信息产生影响，，所以在TLS 1.3中彻底取代了RSA。目前主流都是用ECDHE算法来做密钥交换的

TLS1.3版本中握手过程是这样子的

  1. 浏览器生成client-params、和client-random、TLS版本和加密方法列表发送给服务器
  2. 服务器返回server-params、server-random、加密方法、证书、摘要等传给浏览器
  3. 浏览器确认应答，返回握手数据摘要等信息传给服务器

简单说就是简化了握手过程，只有三步，把原来的两个RTT打包成一个发送了，所以减少了传输次数。这种握手方式也叫1-RTT握手。

这种握手方还有优化空间吗？有的，用会话复用。

1.2.4.4 会话复用

会话复用有两种方式：Session ID 和 Session Ticket

Session ID：就是客户端和服务器首次连接时各自保存会话ID，并存储会话密钥，下次再连接时，客户端发送ID过来，服务器这边再查找ID，如果找到了就直接复用会话，密钥也不用重新生成。

可是这样的话，在客户端数量庞大的时候，对服务器的存储压力可就大了。

所以出来了第二种方式——Session Ticket：就是双方连接成功后服务器加密会话信息，用Session Ticket消息发给客户端存储起来，下次再连接时就把这个Session Ticket解密，验证有没有过期，如果没有过期就复用会话。原理就是把存储压力分给客户端。

这样就万无一失了吗？

No，这样也存在安全问题。因为每次要用一个固定的密钥来解密Session Ticket，一旦密钥被窃取，那所有历史记录也就被破解了，所以只能尽量避免这种问题，定期更换密钥。毕竟节省了不少生成会话密钥和这些算法的耗时，性能还是提升了嘛。

那刚说了1-RTT，那能不能优化到0-RTT呢？

还真可以，做法就是发送Session Ticket的时候带上应用数据，不用等服务端确认。这种方式被称为PSK(Pre-Shared Key)。

这样万无一失了吗？

尴了个尬，还是不行。这PSK要是被窃取，人家不断向服务器重发，就直接增加了服务器被攻击的风险。

虽然不是绝对安全，但已是现行架构下最安全的解决文案了，大大增加了中间人的攻击成本。

1.2.5 HTTPS优缺点

1.2.5.1 优点

  • 内容加密，中间无法查看原始内容
  • 身份认证，保证用户访问正确。如访问百度，即使DNS被劫持到第三方站点，也会提醒用户没有访问百度服务，可能被劫持
  • 数据完整性，防止内容被第三方冒充或篡改
  • 虽然不是绝对安全，但已是现行架构下最安全的解决文案了，大大增加了中间人的攻击成本

1.2.5.2 缺点

  • 要钱，功能越强大的证书费用越贵
  • 证书需要绑定IP，不能在同一个IP上绑定多个域名
  • https双方加解密，耗费更多服务器资源
  • https握手更耗时，降低一定用户访问速度(优化好就不是缺点了)

1.2.6 HTTPS 的性能优化

1.2.6.1 访问速度优化

  1. 会话复用，上面说了，复用session可以减少 CPU 消耗，因为不需要进行非对称密钥交换的计算。可以提升访问速度，不需要进行完全握手阶段二，节省了一个 RTT 和计算耗时。
  2. 使用 SPDY 或者 HTTP2。SPDY 最大的特性就是多路复用，能将多个 HTTP 请求在同一个连接上一起发出去，不像目前的 HTTP1.x 协议一样，只能串行地逐个发送请求。Pipeline 虽然支持多个请求一起发送，但是接收时依然得按照顺序接收，本质上无法解决并发的问题。HTTP2支持多路复用，有同样的效果。
  3. 设置HSTS，服务端返回一个 HSTS 的 http header，浏览器获取到 HSTS 头部之后，在一段时间内，不管用户输入www.baidu.com还是www.baidu.com ，都会默认将请求内部跳转成www.baidu.com。Chrome, firefox, ie 都支持了 HSTS。
  4. Nginx设置Ocsp stapling。Ocsp 全称在线证书状态检查协议 (rfc6960)，用来向 CA 站点查询证书状态，比如是否撤销。通常情况下，浏览器使用 OCSP 协议发起查询请求，CA 返回证书状态内容，然后浏览器接受证书是否可信的状态。这个过程非常消耗时间，因为 CA 站点有可能在国外，网络不稳定，RTT 也比较大。如果不需要查询则可节约时间。
  5. False start。简单概括 False start 的原理就是在 clientkeyexchange 发出时将应用层数据一起发出来，能够节省一个 RTT。

1.2.6.2 计算性能优化

  1. 优先使用 ECC椭圆加密算术
  2. 使用最新版的 OpenSSL
  3. TLS 远程代理计算
  4. 硬件加速方案

1.2.7 HTTP 和 HTTPS 的区别

  • HTTP是明文传输，不安全的，HTTPS是加密传输，安全的多
  • HTTP标准端口是80，HTTPS标准端口是443
  • HTTP不用认证书，免费；HTTPS需要认证，证书要钱
  • 连接方式不同，HTTP三次握手，HTTPS中TLS1.2版本7次，TLS1.3版本6次
  • HTTP在OSI网络模型中是在应用层，而HTTPS的TLS是在传输层
  • HTTP是无状态的，HTTPS是有状态的

944365-820f955afd57185f.png

2. 造火箭攻略

3. 拧螺丝攻略

4. 复制攻略

4.1 《计算机网络》

4.2 《HTTP权威指南》

avatar
文章
阅读
粉丝