HTTPS学习总结

zhouzhou525
155 阅读23分钟

想要真正的了解https，需要了解很多相关知识，比如SSL，对称加密，非对称加密，CA证书等知识。

https协议本身并不是一种新的协议，在HTTP跟TCP中间加多了一层加密层TLS/SSL。通常HTTP直接和TCP通信，而HTTPS要先将数据给到TLS/SSL，数据经加密后，再给到 TCP 进行传输。

HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种是确认网站的真实性

HTTPS加的一层SSL在七层中哪个位置

从 HTTP 协议栈层面来看，我们可以在 TCP 和 HTTP 之间插入一个安全层，所有经过安全层的数据都会被加密或者解密，你可以参考下图

  • 从图中我们可以看出 HTTPS 并非是一个新的协议，通常 HTTP 直接和 TCP 通信，HTTPS 则先和安全层通信，然后安全层再和 TCP 层通信。也就是说 HTTPS 所有的安全核心都在安全层，它不会影响到上面的 HTTP 协议，也不会影响到下面的 TCP/IP，因此要搞清楚 HTTPS 是如何工作的，就要弄清楚安全层是怎么工作的。
  • 总的来说，安全层有两个主要的职责：对发起 HTTP 请求的数据进行加密操作和对接收到 HTTP 的内容进行解密操作
  • 我们知道了安全层最重要的就是加解密，那么接下来我们就利用这个安全层，一步一步实现一个从简单到复杂的 HTTPS 协议

https 协议的优点

  • 使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器
  • HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 http 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性
  • HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻 击的成本

https 协议的缺点

  • https握手阶段比较费时，会使页面加载时间延长 50%，增加 10%~20% 的耗电
  • https 缓存不如 http 高效，会增加数据开销
  • SSL 证书也需要钱，功能越强大的证书费用越高
  • SSL 证书需要绑定 IP，不能再同一个 ip 上绑定多个域名，ipv4 资源支持不了这种消耗

http与https区别

在回答这个问题之前，我们先看下http请求存在哪些不足：

  • 通信使用明文（不加密），内容可能会被窃听
  • 不会验证通信方的身份，因此可能会遭遇伪装
  • 无法保证报文的完整性，请求或响应的内容被篡改也无法知道

https就是对上面三点不足的解决，可以认为

https == http + 加密 + 身份验证 + 数据完整性保护

他们的区别就明显了

  • http使用明文传输，https则是具有安全性的ssl加密传输协议
  • http不会验证通信放的身份，https会通过数字证书来验证身份
  • https可以保证数据的完整性，防止传输内容被中间人冒充或篡改
  • HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所共12 个包。
  • 除以上外，http和https使用的端口也不同，前者使用80端口，后者使用443端口

https传输的具体过程

HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种是确认网站的真实性

TLS 的完整过程需要三个算法（协议），密钥交互算法，对称加密算法，和消息认证算法

TLS 中的加密

  • 对称加密 —— 两边拥有相同的秘钥，两边都知道如何将密文加密解密。
  • 非对称加密 —— 有公钥私钥之分，公钥所有人都可以知道，可以将数据用公钥加密，但是将数据解密必须使用私钥解密，私钥只有分发公钥的一方才知道

HTTPS的整体过程分为证书验证和数据传输阶段

1. 证书验证阶段：

  • 浏览器发起 HTTPS 请求。（ TLS 握手请求）
  • 服务端返回 证书(包含服务器公钥S_PuKey)、对称加密算法种类及其他相关信息。
  • 客户端验证证书是否合法，如果不合法则提示告警。

2. 数据传输阶段：

  • 当证书验证合法后，在本地生成随机数。
  • 通过公钥加密随机数，并把加密后的随机数传输到服务端。
  • 服务端通过私钥对随机数进行解密。 服务端通过客户端传入的随机数构造对称加密算法，之后的数据交互通过对称加密算法进行加解密。（对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法）
  • 服务器利用自己唯一的私钥对客户端发来的对称秘钥进行解密，在此过程中，中间方无法对其解密（即使是客户端也无法解密，因为只有服务器端拥有唯一的私钥），保证了对称秘钥在收发过程中的安全，此时，服务器端和客户端拥有了一套完全相同的对称秘钥。

服务器利用自己唯一的私钥对客户端发来的对称秘钥进行解密，在此过程中，中间方无法对其解密（即使是客户端也无法解密，因为只有服务器端拥有唯一的私钥），保证了对称秘钥在收发过程中的安全，此时，服务器端和客户端拥有了一套完全相同的对称秘钥。

介绍一下https的握手过程

  • 第一步，客户端给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法
  • 第二步，服务端确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数
  • 第三步，客户端确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给服务端
  • 第四步，服务端使用自己的私钥，获取客户端发来的随机数（即Premaster secret）。
  • 第五步，客户端和服务端根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程

总结

  • 客户端发起 HTTPS 请求，服务端返回证书，客户端对证书进行验证，验证通过后本地生成用于构造对称加密算法的随机数
  • 通过证书中的公钥对随机数进行加密传输到服务端（随机对称密钥），服务端接收后通过私钥解密得到随机对称密钥，之后的数据交互通过对称加密算法进行加解密。（既有对称加密，也有非对称加密）

为什么https数据传输使用对称加密

  • 对称加密： 对称加密指的就是加密和解密使用同一个秘钥，所以叫做对称加密。对称加密只有一个秘钥。
  • 非对称加密: 加密和解密使用不同的秘钥，一把作为公开的公钥，另一把作为私钥。公钥加密的信息，只有私钥才能解密。

通过上面的握手过程可知，https在证书验证阶段，使用非对称加密来传输共享秘钥，之后的传输中都使用对称加密方式。原因是，非对称加密的加解密效率是非常低的，而http场景中通常端与端之间的交互量很大，对非对称加密的效率是无法忍受的。另外， HTTPS场景中只有服务端保存了私钥，一对公私钥只能实现单向加解密过程。因此 HTTPS 中的内容传输采用对称加密

对称密钥加密和非对称密钥加密它们有什么区别

  • 对称密钥加密是最简单的一种加密方式，它的加解密用的都是相同的密钥，这样带来的好处就是加解密效率很快，但是并不安全，如果有人拿到了这把密钥那谁都可以进行解密了。
  • 而非对称密钥会有两把密钥，一把是私钥，只有自己才有；一把是公钥，可以发布给任何人。并且加密的内容只有相匹配的密钥才能解。这样带来的一个好处就是能保证传输的内容是安全的，因为例如如果是公钥加密的数据，就算是第三方截取了这个数据但是没有对应的私钥也破解不了。不过它也有缺点，一是公钥因为是公开的，谁都可以过去，如果内容是通过私钥加密的话，那拥有对应公钥的黑客就可以用这个公钥来进行解密得到里面的信息；二来公钥里并没有包含服务器的信息，也就是并不能确保服务器身份的合法性；并且非对称加密的时候要消耗一定的时间，减低了数据的传输效率。

混合加密机制的好处是什么

  • 对称密钥加密和非对称密钥加密都有它们各种的优缺点，而混合加密机制就是将两者结合利用它们各自的优点来进行加密传输。
  • 比如既然对称密钥的优点是加解密效率快，那么在客户端与服务端确定了连接之后就可以用它来进行加密传输。不过前提是得解决双方都能安全的拿到这把对称密钥。这时候就可以里用非对称密钥加密来传输这把对称密钥，因为我们知道非对称密钥加密的优点就是能保证传输的内容是安全的。
  • 所以它的好处是即保证了对称密钥能在双方之间安全的传输，又能使用对称加密方式进行通信，这比单纯的使用非对称加密通信快了很多。以此来解决了HTTP中内容可能被窃听的问题。

混合加密的缺点

混合加密主要是为了解决HTTP中内容可能被窃听的问题。但是它并不能保证数据的完整性，也就是说在传输的时候数据是有可能被第三方篡改的，比如完全替换掉，所以说它并不能校验数据的完整性。如果需要做到这一点就需要使用到数字签名。

介绍下https中间人攻击的过程

这个问题也可以问成 为什么需要CA认证机构颁发证书？ 我们假设如果不存在认证机构，则人人都可以制造证书，这就带来了"中间人攻击"问题。

中间人攻击的过程如下

  • 客户端请求被劫持，将所有的请求发送到中间人的服务器
  • 中间人服务器返回自己的证书
  • 客户端创建随机数，使用中间人证书中的公钥进行加密发送给中间人服务器，中间人使用私钥对随机数解密并构造对称加密，对之后传输的内容进行加密传输
  • 中间人通过客户端的随机数对客户端的数据进行解密
  • 中间人与服务端建立合法的https连接（https握手过程），与服务端之间使用对称加密进行数据传输，拿到服务端的响应数据，并通过与服务端建立的对称加密的秘钥进行解密
  • 中间人再通过与客户端建立的对称加密对响应数据进行加密后传输给客户端
  • 客户端通过与中间人建立的对称加密的秘钥对数据进行解密

简单来说，中间人攻击中，中间人首先伪装成服务端和客户端通信，然后又伪装成客户端和服务端进行通信（如图）。 整个过程中，由于缺少了证书的验证过程，虽然使用了https，但是传输的数据已经被监听，客户端却无法得知

HTTPS 握手过程中，客户端如何验证证书的合法性

CA证书中会包含颁发机构信息、公钥、公司信息、域名、有效期等信息，浏览器验证证书：

  • 首先就是要验证域名、有效期等信息是否正确
  • 然后判断证书来源的合法性。每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证
  • 判断证书是否被篡改。需要与 CA 服务器进行校验
  • 判断证书是否已吊销

以上任意一步都满足的情况下浏览器才认为证书是合法的

问题

1. 为什么数据传输是用对称加密

HTTP的应用场景中通常端与端之间存在大量的交互，非对称加密的加解密效率非常低。另外，在 HTTPS的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密

2. 为什么需要证书?

防止“中间人”攻击，同时可以为网站提供身份证明。

3. 使用 HTTPS 会被抓包吗?

会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。

数字签名？它是什么

数字签名的产生主要就是为了解决HTTP中内容可能被篡改的问题，即校验数据的完整性。它能确定消息是发送方发送过来的，因为这里会有一个验证数字签名的过程，别人是假冒不了发送方的签名的。

数字签名它是什么呢？它的产生过程其实就是两步，第一步将原文用Hash函数生成一个叫消息摘要的东西，第二步就是用发送方的私钥对这个消息摘要进行进行加密。这个产生的东西就叫做数字签名，它一般会与原文一起发送给接收者。

而验证它的过程其实也并不复杂。

  • 首先发送方会将原文与数字签名(也就是加密后的摘要)一起发送给接收方
  • 接收方会接收到这两样东西，即原文和数字签名
  • 接收方用Hash函数处理原文会得到一份消息摘要
  • 同时用发送方的公钥解密数字签名也会得到一份消息摘要
  • 只要比较这两份消息摘要是否相等就可以验证出数据有没有被篡改了

当然这里关键的一步就是要保证发送方传递过来的公钥是可信赖的，这时候就得用到数字证书了。

谈谈对数字证书的理解

数字证书也叫公钥证书，或者简称证书。它主要是为了解决通信方身份遭伪装的问题，也就是验证通信方的身份。

因为我们知道在HTTPS中虽然有了混合加密机制保证数据不被监听，有了数字签名校验数据的完整性，但是数字签名校验的前提是能拿到发送方的公钥，并且保证这个公钥是可信赖的，所以就需要数字证书。

它简单来说其实是由一些权威的数字认证机构颁发给服务器的一个文件。数字认证机构简称CA，它是客户端和服务端都信任的第三方机构，我知道比较有名的一个就是威瑞信(VeriSign)。至于颁发证书的流程，主要是为：

  • 服务器的运营人员会向认证机构提交自己的公钥、组织信息、个人信息等并申请认证
  • 而认证机构在拿到这些信息后会通过线上、线下各种途径验证申请者提交信息的真实性
  • 在确认其真实性后，认证机构给这些信息(申请者的公钥，组织信息，个人信息以及认证机构自己的信息等)，我们简称为明文信息，进行数字签名，过程也就是签名提到的数字签名的步骤：1.通过Hash函数处理明文信息生成一个信息摘要；2.再用认证机构自己的私钥对信息摘要进行加密处理。通过这两个步骤生成的文件就叫数字签名。
  • 之后会将明文信息和数字签名组合而成的证书颁发给申请者，也就是服务器。

为什么说数字证书就能对通信方的身份进行验证呢

那是因为在客户端第一次给服务端发送HTTPS请求的时候，服务端会将它自己的证书随着其它的信息(例如server_random、 server_params、需要使用的加密套件等东西)一起返给客户端。

客户端在收到之后首先会验证这个证书，只有验证通过之后才会有后续操作。而验证的过程其实也就是数字签名的验证过程(题5)：

  • 前面说过了，证书其实是由明文信息(申请者的公钥，组织信息，个人信息以及认证机构自己的信息等)和这个明文信息的数字签名组成的。(对应着题5也就是原文和数字签名)
  • 客户端会用Hash函数处理明文信息生成一个信息摘要
  • 然后再用内置在浏览器上的CA的公钥来解密证书里的数字签名，得到一个信息摘要。因为我们知道证书实际是由CA颁发给服务器的，并且里面的数字签名也是用的CA的私钥加密的，所以只有CA的公钥才能解。
  • 最后再将两个信息摘要进行对比，若是一样则能保证通信方的身份是正确的。

其实验证证书的过程不仅仅是数字签名的验证，客户端还会验证证书相关的域名信息，有效时间，是不是在CRL吊销列表里，以及它的上一级是否有效等等。

（一般答到这里就可以了，如果面试官继续问你上一级是否有效这样验证，你就回答：这是一个递归的过程，直到验证到根证书也就是操作系统内置的Root证书或者浏览器内置的Root证书为止）

就像前面说的，只有能用CA的公钥解密的数字签名并且通过了认证的证书才是有效的，因为证书是CA颁布的。这也就保证了客户端收到的服务器发来的公钥是真实可用的(因为公钥在证书的明文信息里)。

（想想其实很好理解，因为浏览器它自己没有辨别证书是否合法的能力，它就把这事交给CA去做，CA是信任的过的机构，它只要把自己的公钥内嵌到浏览器里，浏览器再用这个CA公钥来解证书里的签名就可以了。而证书的签名也是经过CA的私钥加密生成的，只有CA的公钥能解，但它的公钥又不是随便人能拿到的，只有各大浏览器厂商才有，所以这就是数字证书的验证过程）

请详细的说一下HTTPS它的加密传输过程，涉及到哪些算法呢？

难度：🌟🌟🌟🌟

在HTTPS加密传输中，实际上涉及到 SSL/TLS 协议，这里是有一个TSL握手的过程。对于传统的TLS握手也就是RSA握手我就不描述了，主要是说一下现在主流的TLS1.2版本的握手，也就是ECDHE握手。

它的过程大致来说是这样的：

  1. 客户端在第一次发送HTTPS请求的时候，会把 client_random、TSL版本号、加密套件列表发送给服务器
  2. 服务器在接收到之后确认TSL的版本号，同时发送 server_random、server_params、需要使用的加密套件、以及自己的证书给客户端
  3. 客户端在收到这些信息之后，首先是会对服务器的证书进行验证(也就是题目7)，若是验证成功则会传递一个 client_params 给服务器
  4. 与此同时客户端会通过ECDHE算法计算出一个pre_random，其中是传入了两个参数，一个是 client_params，还一个是 server_params。(也就是说：ECDHE(client_params, server_params) = per_random)
  5. 这时候客户端就同时拥有了 client_random、server_random、pre_random，它会将这三个参数通过一个伪随机函数计算得出最终的secret，这个secret就是它们后续通信所要用的对称密钥。
  6. 而在客户端生成完secret之后，会给服务器发送一个收尾消息，告诉服务器之后都要用对称加密，且对称加密的算法是用第一次约定好的。
  7. 服务器它在接收到刚刚传递过来的client_params之后，也会使用和客户端一样的方式生成secret，并且也会发送一个收尾消息给客户端。
  8. 当双方都收到收尾消息并验证成功之后，握手就结束了。后面开始用这个secret对称密钥加密报文进行传输。

（ECDHE基于椭圆曲线离散对数，传入的两个参数也被叫做椭圆曲线的公钥）

描述一下RSA握手

难度：🌟🌟🌟

  1. 客户端首先向服务端发送一个HTTPS请求
  2. 服务端会把事先配置好的公钥证书随着其它的信息返回给客户端
  3. 客户端在收到服务端发来的证书之后进行验证，验证的过程参考数字证书验证，会得到服务端的信息以及它的公钥
  4. 验证成功之后会用伪随机函数计算出一个加密所需要的对称密钥(secret)，并且用服务端的公钥加密这个对称密钥发送给服务端
  5. 服务端再用自己的私钥解密刚刚的消息，得到里面的对称密钥。此时服务端和客户端都有了对称密钥。
  6. 后面的传输都会用这个 secret 进行对称密钥加解密传输

ECDHE握手和RSA握手又有什么区别呢

难度：🌟🌟🌟

它们的区别主要是：

  1. 生成secret(对称密钥)的过程不同。RSA中是使用RSA算法生成一个pre_random并用服务器的公钥加pre_random发送给服务器，然后各自用伪随机函数生成相同的secret对称密钥；而在ECDHE握手中，它没有用到RSA算法，而是用ECDHE算法生成的pre_random，且这个过程中比RSA多了client_params和server_params两个参数。
  2. 在生成完secret之后，ECDHE握手在客户端发送完收尾消息后可以提前抢跑，直接发送 HTTP 报文，节省了一个 RTT，不必等到收尾消息到达服务器，然后等服务器返回收尾消息给自己，直接开始发请求。这也叫TLS False Start。
  3. 最主要的：RSA不具备向前安全性，ECDHE有

（向前安全性：一次破解并不影响历史信息的性质就是向前安全性）

你知道TSL1.3版本吗？它较TSL1.2做了哪些改进呢？

TSL1.3版本是2018年推出的。它较TSL1.2主要是做了以下改进：

  1. 强化安全

废除了很多的加密算法，只保留了5个加密套件。其中最主要的是废弃了RSA，因为在2015年发现了PRAEK攻击，即已经有人发现了RSA的漏洞能进行破解；而且RSA不具备向前安全性。

  1. 提高性能

同时利用会话复用节省了重新生成密钥的时间，利用 PSK 做到了0-RTT连接。

介绍下 HTTPS 中间人攻击

中间人攻击过程如下：

  • 服务器向客户端发送公钥。
  • 攻击者截获公钥，保留在自己手上。
  • 然后攻击者自己生成一个【伪造的】公钥，发给客户端。
  • 客户端收到伪造的公钥后，生成加密hash值发给服务器。
  • 攻击者获得加密hash值，用自己的私钥解密获得真秘钥。
  • 同时生成假的加密hash值，发给服务器。
  • 服务器用私钥解密获得假秘钥。
  • 服务器用加秘钥加密传输信息

防范方法：

服务端在发送浏览器的公钥中加入CA证书，浏览器可以验证CA证书的有效性

http/https 协议总结

1.0 协议缺陷:

  • 无法复用链接，完成即断开，重新慢启动和 TCP 3次握手
  • head of line blocking: 线头阻塞，导致请求之间互相影响

1.1 改进:

  • 长连接(默认 keep-alive)，复用

  • host 字段指定对应的虚拟站点

  • 新增功能:

    • 断点续传

    • 身份认证

    • 状态管理

    • cache 缓存

      • Cache-Control
      • Expires
      • Last-Modified
      • Etag

2.0:

  • 多路复用
  • 二进制分帧层: 应用层和传输层之间
  • 首部压缩
  • 服务端推送

https: 较为安全的网络传输协议

  • 证书(公钥)
  • SSL 加密
  • 端口 443

TCP:

  • 三次握手

  • 四次挥手

  • 滑动窗口: 流量控制

  • 拥塞处理

    • 慢开始
    • 拥塞避免
    • 快速重传
    • 快速恢复

缓存策略: 可分为 强缓存 和 协商缓存

  • Cache-Control/Expires: 浏览器判断缓存是否过期，未过期时，直接使用强缓存，Cache-Control的 max-age 优先级高于 Expires

  • 当缓存已经过期时，使用协商缓存

    • 唯一标识方案: Etag(response 携带) & If-None-Match(request携带，上一次返回的 Etag): 服务器判断资源是否被修改

    • 最后一次修改时间: Last-Modified(response) & If-Modified-Since(request，上一次返回的Last-Modified)

      • 如果一致，则直接返回 304 通知浏览器使用缓存
      • 如不一致，则服务端返回新的资源

  • Last-Modified 缺点：

    • 周期性修改，但内容未变时，会导致缓存失效
    • 最小粒度只到 s， s 以内的改动无法检测到

  • Etag 的优先级高于Last-Modified

avatar
文章
阅读
粉丝