极客时间已完结课程限时免费阅读

02 | 为HTTP穿上盔甲：HTTPS

02 | 为HTTP穿上盔甲：HTTPS-极客时间

02 | 为HTTP穿上盔甲：HTTPS

2019-09-13 四火 来自北京
《全栈工程师修炼指南》
课程介绍

讲述：四火

时长19:12大小13.19M

你好，我是四火。
在上一讲中，我介绍了互联网最重要的 HTTP 协议。可是随着互联网的发展，你会发现 HTTP 越来越无法满足复杂的需求，比如数据加密传输的安全性需求，再比如服务器消息即时推送的交互模式的需求，而这些不适性是由 HTTP 的基本特性所造成的。
因此，我们需要在传统 HTTP 领域以外开疆拓土，这就包括要引入其它的网络协议，或增强、或填补 HTTP 协议所不擅长的空白领域，这也是今天这一讲和下一讲的核心内容。今天我们重点学习 SSL/TLS ，看看它是如何让 HTTP 传输变得安全可靠的。

HTTP，SSL/TLS 和 HTTPS

在一开始的时候，HTTP 的设计者并没有把专门的加密安全传输放进协议设计里面。因此单独使用 HTTP 进行明文的数据传输，一定存在着许多的安全问题。比方说，现在有一份数据需要使用 HTTP 协议从客户端 A 发送到服务端 B，而第三方 C 尝试来做点坏事，于是就可能产生如下四大类安全问题：
Interception：拦截。传输的消息可以被中间人 C 截获，并泄露数据。
Spoofing：伪装。A 和 B 都可能被 C 冒名顶替，因此消息传输变成了 C 发送到 B，或者 A 发送到 C。
Falsification：篡改。C 改写了传输的消息，因此 B 收到了一条被篡改的消息而不知情。
Repudiation：否认。这一类没有 C 什么事，而是由于 A 或 B 不安好心。A 把消息成功发送了，但之后 A 否认这件事发生过；或者 B 其实收到了消息，但是否认他收到过。
但是，与其重新设计一套安全传输方案，倒不如发挥一点拿来主义的精神，把已有的和成熟的安全协议直接拿过来套用，最好它位于呈现层（Presentation Layer），因此正好加塞在 HTTP 所在的应用层（Application Layer）下面，这样这个过程对于 HTTP 本身透明，也不影响原本 HTTP 以下的协议（例如 TCP）。
这个协议就是 SSL/TLS，它使得上面四大问题中，和传输本身密切相关的前三大问题都可以得到解决（第四个问题还需要引入数字签名来解决）。于是，HTTP 摇身一变成了 HTTPS：
HTTP + SSL/TLS = HTTPS
这里涉及到的两个安全协议，SSL 和 TLS，下面简要说明下二者关系。
SSL 指的是 Secure Socket Layer，而 TLS 指的是 Transport Layer Security，事实上，一开始只有 SSL，但是在 3.0 版本之后，SSL 被标准化并通过 RFC 2246 以 SSL 为基础建立了 TLS 的第一个版本，因此可以简单地认为 SSL 和 TLS 是具备父子衍生关系的同一类安全协议。

动手捕获 TLS 报文

介绍了最基本的概念，我们再来看看 HTTPS 是怎样安全工作，让客户端和服务端相互信任的， TLS 连接又是怎样建立起来的。还记得上一讲的选修课堂吗？我们学了怎样抓包。今天我们就能让所学派上用场！自己动手，我们抓 TLS 连接握手的报文来分析。
命令行执行抓包命令，指明要抓 https://www.google.com 的包（当然，你也可以使用其他 HTTPS 网站地址），注意 HTTPS 的默认端口是 443（-i 指定的 interface 可能因为不同的操作系统有所区别，在我的 Mac 上是 en0）：
sudo tcpdump -i en0 -v 'host www.google.com and port 443' -w https.cap
再新建一个命令行窗口，使用 curl 命令来访问 Google 主页：
curl https://www.google.com
于是在看到类似如下抓包后 CTRL + C 停止：
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C49 packets captured
719 packets received by filter
0 packets dropped by kernel
接着使用 Wireshark 打开刚才抓的 https.cap，在 filter 中输入 tls，得到如下请求和响应报文：
可以看到，这里有五个重要的握手消息，在它们之后的所有消息都是用于承载实际数据的“Application Data”了。握手的过程略复杂，接下来我会尽可能用通俗的语言把最主要的流程讲清楚。

对称性和非对称性加密

这里我先介绍两个概念，“对称性加密”和“非对称性加密”，这是学习后面内容的重要基础。
对称性加密（Symmetric Cryptography），指的是加密和解密使用相同的密钥。这种方式相对简单，加密解密速度快，但是由于加密和解密需要使用相同的密钥，如何安全地传递密钥，往往成为一个难题。
非对称性加密（Asymmetric Cryptography），指的是数据加密和解密需要使用不同的密钥。通常一个被称为公钥（Public Key），另一个被称为私钥（Private Key），二者一般同时生成，但是公钥往往可以公开和传播，而私钥不能。经过公钥加密的数据，需要用私钥才能解密；反之亦然。这种方法较为复杂，且性能较差，好处就是由于加密和解密的密钥具有相对独立性，公钥可以放心地传播出去，不用担心安全性问题。
原始数据 + 公钥 → 加密数据
加密数据 + 私钥 → 原始数据

TLS 连接建立原理

有了上述基础，下面我们就可以结合图示，看看整个连接建立的握手过程了。
Step 1: Client Hello. 客户端很有礼貌，先向服务端打了个招呼，并携带以下信息：
客户端产生的随机数 A；
客户端支持的加密方法列表。
Step 2: Server Hello. 服务端也很有礼貌，向客户端回了个招呼：
服务端产生的随机数 B；
服务端根据客户端的支持情况确定出的加密方法组合（Cipher Suite）。
Step 3: Certificate, Server Key Exchange, Server Hello Done. 服务端在招呼之后也紧跟着告知：
Certificate，证书信息，证书包含了服务端生成的公钥。这个公钥有什么用呢？别急，后面会说到。
客户端收到消息后，验证确认证书真实有效，那么这个证书里面的公钥也就是可信的了。
接着客户端再生成一个随机数 C（Pre-master Secret），于是现在共有随机数 A、B 和 C，根据约好的加密方法组合，三者可生成新的密钥 X（Master Secret），而由 X 可继续生成真正用于后续数据进行加密和解密的对称密钥。因为它是在本次 TLS 会话中生成的，所以也被称为会话密钥（Session Secret）。简言之：
客户端随机数 A + 服务端随机数 B + 客户端 Pre-master Secret C → 会话密钥
需要注意的是，实际这个 Pre-master Secret 的生成方法不是固定的，而会根据加密的具体算法不同而不同：
上述我介绍的是传统 RSA 方式，即 Pre-master Secret 由客户端独立生成，加密后再通过 Client Key Exchange 发回服务端。
还有一种是 ECDHE 方式，这种方式下无论在客户端还是服务端，Pre-master Secret 需要通过 Client Key Exchange 和 Server Key Exchange 两者承载的参数联合生成。
Step 4: Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message. 接着客户端告诉服务端：
Client Key Exchange，本质上它就是上面说的这个 C，但使用了服务端通过证书发来的公钥加密；
Change Cipher Spec，客户端同意正式启用约好的加密方法和密钥了，后面的数据传输全部都使用密钥 X 来加密；
Encrypted Handshake Message，快速验证：这是客户端对于整个对话进行摘要并加密得到的串，如果经过服务端解密，和原串相等，就证明整个握手过程是成功的。
服务端收到消息后，用自己私钥解密上面的 Client Key Exchange，得到了 C，这样它和客户端一样，也得到了 A、B 和 C，继而到 X，以及最终的会话密钥。
于是，客户端和服务端都得到了能够加密解密传输数据的对称密钥——会话密钥。
因此，我们可以看到：TLS 是通过非对称加密技术来保证握手过程中的可靠性（公钥加密，私钥解密），再通过对称加密技术来保证数据传输过程中的可靠性的。
这种通过较严格、较复杂的方式建立起消息交换渠道，再通过相对简单且性能更高的方式来实际完成主体的数据传输，并且前者具有长效性（即公钥和私钥相对稳定），后者具有一过性（密钥是临时生成的），这样的模式，我们还将在全栈的知识体系中，继续见到。
Step 5: Change Cipher Spec, Encrypted Handshake Message. 服务端最后也告知客户端：
Change Cipher Spec，服务端也同意要正式启用约好的加密方法和密钥，后面的数据传输全部都使用 X 来加密。
Encrypted Handshake Message，快速验证：这是服务端对于整个对话进行摘要并加密得到的串，如果经过客户端解密，和原串相等，就证明整个握手过程是成功的。

总结思考

今天我们了解了关于数据传输的四大类安全问题，了解了 HTTPS 和 SSL/TLS 的概念和它们之间的关系，还通过自己动手抓包的方式，详细学习了 TLS 连接建立的步骤。
TLS 连接的步骤是今天的重点，也是比较难理解的部分，希望你能牢牢地掌握它。现在就来检验一下今天的学习成果吧！请你思考这样两个问题：
有位程序员朋友注意到，自己在使用在线支付功能时，网站访问是使用 HTTPS 加密的，因此他觉得，支付的过程中是不可能出现安全问题的，你觉得这种想法对吗？
在介绍 TLS/SSL 连接建立的过程当中，我提到了，握手过程是使用非对称加密实现的，而真正后续的数据传输部分却是由对称加密实现的。为什么要这么麻烦，全部都使用对称或非对称加密一种不好吗？
你能回答上面的问题吗？如果可以，我相信你已经理解了 HTTPS 安全机制建立的原理。

选修课堂：证书有效验证的原理

在讲解“握手过程”的 step 3 时，我提到了客户端在收到服务端发送过来的证书时，需要校验证书的有效性。这个过程其实也是至关重要的，因为只有确认了证书的有效性，客户端才能放心地使用其中的公钥。如果你对它的理解比较模糊，那就一定要看看今天的选修课堂了。
这就是我们抓包中，服务器发来的证书部分的截图。我们可以看到，这不是单个证书，而是一个证书链，包含了两个证书，每个证书都包含版本、发布机构、有效期、数字签名等基本内容，以及一个公钥。实际上，这两个服务端传回来的证书，和浏览器内置的根证书联合起来，组成了一个单向、完整的证书链：
上图中的第三行，就是携带着服务器公钥的证书，它是从证书发布机构（CA, Certificate Authority）申请得来的，也就是图中第二行的 GTS CA 1O1。证书在申请的时候，我们提到的服务器公钥就已经是该证书的一部分了，因此我们才说，如果证书是有效的，那么它携带的公钥就是有效的。
在当时申请的时候，证书发布机构对证书做摘要生成指纹，并使用它自己的私钥为该指纹加密，生成数字签名（Digital Signature），而这个数字签名也随证书一起发布。这个发布机构的私钥是它内部自己管理的，不会外泄。
指纹 + 私钥 → 数字签名
验证过程则正好是发布过程的反向，即在客户端要对这个被检测证书做两件事：
对它用指定算法进行摘要，得到指纹 P1；
使用证书发布机构的公钥对它的数字签名进行解密，得到指纹 P2。
数字签名 + 公钥 → 指纹
如果 P1 和 P2 一致，就说明证书未被篡改过，也说明这个服务端发来的证书是真实有效的，而不是仿冒的。
好，问题来了，证书发布机构使用非对称性加密和数字签名保证了证书的有效性，那么谁来保证证书发布机构的有效性？
答案就是它的上一级证书发布机构。
CA 是分级管理的，每一级 CA 都根据上述同样的原理，由它的上一级 CA 来加密证书和生成数字签名，来保证其真实性，从而形成一个单向的信任链。同时，标志着最高级别 CA 的根证书数量非常少，且一般在浏览器或操作系统安装的时候就被预置在里面了，因此它们是被我们完全信任的，这就使得真实性的鉴别递归有了最终出口。也就是说，递归自下而上验证的过程，如果一直正确，直至抵达了顶端——浏览器内置的根证书，就说明服务端送过来的证书是安全有效的。
总结一下今天选修课堂的内容。证书有效性的验证，需要使用依赖于证书发布机构的公钥去解密被检测证书的数字签名，如果顺利解密，并且得到的指纹和被检测证书做摘要得到的指纹一致，就说明证书真实有效。

扩展阅读

HOW HTTPS WORKS：漫画版介绍 HTTPS 前前后后，很有趣。
The First Few Milliseconds of an HTTPS Connection：如果你想深究你抓到的 TLS 连接建立的包中每一段报文的意思，这篇文章是一个很好的参考。
文中介绍了两种生成 Pre-master Secret 的方法，其中第二种的方法是 Diffie–Hellman 密钥交换的变种，这里蕴含的数学原理很有意思，如果你感兴趣，请参阅维基百科链接。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 3

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
01 | 网络互联的昨天、今天和明天：HTTP 协议的演化
下一篇
03 | 换个角度解决问题：服务端推送技术
unpreview
 写留言

精选留言(18)

  • 饭团
    置顶
    2019-09-13
    回答老师问题 1)不能 因为虽然https是安全的，但前提是你的访问对象是安全的，归根到底你要保证真实是真实的，安全的！是你想访问对象！因为证书也是可以自己生成的！ 2)为了性能，非对称加密算法性能不好！对称算法性能高！

    作者回复: 1）结论正确，但是解释不太妥当。HTTPS 可以达到数据在网络传输过程中的可靠性，但是支付过程是一个复杂和综合性的行为，涉及到的过程和角色远不只有 HTTPS 连接和它的客户端、服务端，因此 HTTPS 的安全性结论无法推广到整个支付过程和支付行为的安全性结论。 2）性能是一个非常重要的因素，说得很好，因为非对称性加密的性能要比对称性加密的性能差很多，特别是在被加密数据量比较大的时候，但它的问题在于无法把密钥传递到对端，因此我们才使用了非对称加密的方式来帮助做到这一点。但是，还有其它原因，比如说，对称性密钥是每次会话生成的，会话以外自动失效，这就像武功唯快不破一样，通常很短的时间就更换掉了；如果使用非对称性加密方式来传输实际数据，因为它只在最开始的时候生成一次，而不是每次会话都生成，因此在传输中同一个公钥会被发给多个不同的客户端，因此第三方的中间人可以使用这个公开的公钥解密服务端发给其它客户端的数据，这显然不具备安全性。

    23
  • CC
    2019-09-23
    对于老师的置顶回复中的下面这句话有一个疑问：「第三方的中间人可以使用这个公开的公钥解密服务端发给其他客户端的数据。」 我的理解是：非对称加密意味着「公钥加密，私钥解密」。 如果使用公开的公钥加密传输数据，第三方中间人仍然需要私钥来解密数据。 为何第三方中间人可以使用这个公钥来解密数据呢？ 不确定是不是自己哪一步理解有误。 提前谢谢老师。
    展开

    作者回复: 这是一个很好的问题。 有“公钥加密，私钥解密”，但其实也有“私钥加密，公钥解密”。 从消息保密的角度来说，一般我们都是使用公钥加密，私钥解密。这样才能让消息保密，即便被第三方窃取了消息，消息内容也不会泄露。如果是这个用途，那么你说的完全正确。 但是 non-repudiation 则是反过来，使用私钥加密，目的就是让对方，以及可能出现的第三方使用公钥解密，这样大家都能证明消息已经确实被发送了，因为在私钥没有泄露的情况下，这条消息是无法被创建的，这也就使得“否认”（repudiation）变得不可能。

    共 3 条评论
    6
  • kissingers
    2019-12-02
    老师，为什么要设计成有了ABC才能计算出密钥，不要AB行吗？因为只有c是加密的，攻击者拿到c 不就可以计算出密钥了吗？那ab 还有意义吗？谢谢

    作者回复: 这种方式（传统 RSA 方式）下，C 是通过非对称密钥加密的，因此攻击者拿到加密后的 C，却无法解密。最后的对称密钥的计算，需要解密后的 C。 至于 A 和 B 因子的引入，是为了提高 pre-master 的随机性。

    共 2 条评论
    3
  • 零维
    2019-10-17
    老师，证书发布机构对证书做摘要生成的指纹和客户端生成的指纹 P1 是一个东西吗？

    作者回复: 对。对于证书做摘要得到指纹，这个指纹无论是发布方还是客户端得到的，它们必须一致，要不然校验就失败了。

    2
  • 零维
    2019-10-17
    老师，您建议先粗略的读一遍，再重读的时候再学习这些延展资料，还是第一遍的时候就跟着学下来呢？

    作者回复: 这个取决于你自己吧 :) 理解内容最重要。

    1
  • I.m 帅帅大王
    2021-05-29
    老师我想问一下，客户端与服务端建立连接之后，之后的发送消息时是直接使用会话密钥加密后传输吗，不需要客户端再使用公钥加密后传输了吧？

    作者回复: 对，连接建立以后，都使用会话密钥加密

  • 唯心主义蠢货🍁
    2020-11-01
    1. https只保证A点到B点的传输内容是安全的，但是不保证A网站是安全的，也不保证B网站是安全 2.对称加密的特点是简洁快速但是安全性较低，非对称加密的特点是安全性高但是发送信息过程繁琐，所以结合这两个的特点，我们需要通过利用非对称加密的安全性将对称加密的密钥安全地传输给对方，那既然对称加密的密钥是安全的了，那之后的传输都可以用这个了。 整个过程主要： （1）. 用CA机构的私钥把证书进行加密，客户端通过操作系统或者浏览器内置的公钥解密，保证服务端的安全性； （2）. 服务端将公钥发给客户端，客户端将加密后的A+B+C随机数生成的密码传给服务端，服务端通过公钥进行验证，保证了客户端的安全性 （3）. 之后的通信通过安全的对称加密的密钥进行访问的。 3. 证书验证的部分： 证书返回给客户端的内容是： 证书内容（版本、有效期、公钥等） + 数字签名 数字签名是对证书内容进行摘要的指纹 + 密钥进行加密 得到的 所以反向 如果对内容进行摘要算法得到的内容A 和 公钥解密数字签名得到的B 不一致的话，说明内容被篡改
    展开
  • pengzishang
    2020-10-24
    选修课堂中有一句:"对它用指定算法进行摘要，得到指纹 P1；" 我想问这个指定算法是什么算法,没有CA的私钥是怎样得出与P2相同的P1的?

    作者回复: 常见的摘要算法有几种，比如MD5，SHA-1等。客户端没有私钥，但是有公钥，而公钥+数字签名，可以计算得到指纹，这个指纹信息如果和使用摘要算法去算得证书本身得到的指纹一致，那就证实了证书的有效性。

  • Geek_74d3ac
    2020-07-28
    总结思考 1. no + 如果证书是不安全的话可以伪造服务端的公钥 + 加密算法握手的时候未加密，中间人可以删除较强的算法，迫使客户选择较弱的算法（ 这点可以通过报文鉴别码MAC 解决），又或者服务端的本身只支持较弱的算法。 + 位于不安全的网络，如公共 wifi，在更低一层比如网络层，传输层被的位置被监听或者篡改 2. 对称加密安全性不足，特别是对于如何安全的传输密钥的问题难以解决。非对称加密安全性更强，但是效率不高，因此通过非对称加密传递密钥，然后报文通过对称加密传输其实也是在安全性和效率上取得平衡。
    展开
  • 啊啦啦啦啦啦
    2020-05-23
    https保证了传输数据过程中的保密性，但是却牺牲了一部分的性能
  • 陈文
    2020-05-05
    我在centos7的yum源安装的wireshark、wireshark-gnome，tls是无效的filter，要用ssl。
  • 川军团
    2020-02-27
    “证书发布机构对证书做摘要生成指纹” 老师这句话能不能 详细解释一下，什么是做摘要生成指纹 另外客户端 “对它用指定算法进行摘要，得到指纹 P1；” 这两个操作是不是一样的

    作者回复: 摘要生成指纹其实就是一种hash算法，根据一个较长的复杂文本来生成一个较短的指纹字符串，原文本只要有一点点变更，这个指纹就会极大不同。 对，客户端自己用指定算法算得的指纹，必须严格等于使用公钥解密后的指纹，否则就认为这个证书被篡改。

  • Skylight
    2019-10-10
    老师我有俩问题： 1、“快速验证”对对话摘要加密使用的秘钥应该是A+B+C生成的会话秘钥吧？ 2、有了会话秘钥之后，传输数据时为了判断信息是否被篡改，是不是也要对信息进行摘要然后对称秘钥加密后再把信息、摘要发给对方啊？

    作者回复: 1. 是会话密钥 2. 这就不会了，因为前面的机制保证了会话密钥仅此两份

  • CC
    2019-09-23
    思考题1： 如果这个支付功能网站本身就是为了钓鱼设计的，仍然可能出现安全问题。（后看到老师置顶留言，才知道原来不能把 HTTPS 的安全结论推广到整个支付过程。HTTPS 只是支付过程的一部分。） 思考题2： 是安全与效率的取舍。 如果全部使用对称加密，安全性不可靠，相对容易反推秘钥；如果全部使用非对称加密，内容传输的效率低，在数据量大的时候低很多。 严格确认双方身份后，就可以用低成本高效率的方式来沟通。 （后看到老师留言，使用非对称性加密来传输实际数据，没有一过性，反倒会有安全性问题。） 选修课堂和扩展阅读长知识了，谢谢老师。
    展开

    作者回复: 👍

  • liu_liu
    2019-09-18
    1. 不对，因为在建立 TSL 连接的过程中可能会出现中间人攻击。 2. 出于性能和安全性考虑

    作者回复: 感谢回答。 正确，但不完整，你可以看看别人的回答。

  • pyhhou
    2019-09-17
    思考题： 1. 这种想法是不对的，虽然有证书和加密机制做保证，但是黑客们还是可以在请求访问的过程中做文章。在网上找到了个例子：“DNS 劫持”，因为我们在向服务器发送请求的第一步就是去到 DNS，通过域名获取服务器 IP，如果说这一步我们访问的 DNS 服务器是黑客的，这个 DNS 会返回一个错误的 IP，导致我们使用 HTTPS 去和一个错误的 server 去建立所谓的 “安全” 连接。一句话总结就是 HTTPS 安全不等于支付过程安全 2. 回答这个问题之前，先分析一下我们对 TLS/SSL 建立连接的需求和期待： i) 客户端和服务器都能够解密它们之间传输的数据 ii) 保证这个过程效率尽量高 iii) 保证这个过程尽量安全 如果说双方都使用对称性加密算法，确实建立连接的效率很高，双方也可以加密解密彼此的数据，但是这其实并不安全，首先密钥不能够通过安全的方式告知对方，另外动态更新密钥会使得安全性提升，但是告知方式受阻，这里也做不到。 如果说双方都使用非对称性加密算法，由于密钥只有一把，传递出去的都是公钥，公钥只能加密不能解密，这个安全问题解决了，每次传输数据都用对方给的公钥加密，接收数据都用自己生成的私钥解密，数据加密解密确实也可以完成，但是非对称加密算法本身效率不高，加上客户端服务器来回生成公私钥，传递公钥，传输效率也大打折扣。 如果我们结合这两个算法的优缺点，用非对称算法保证传输安全，用对称算法保证解密数据的高效和正确性，确实是一个较为合理的做法。 感谢老师分享，读完文章受益匪浅，花了比较多的时间看整个 TLS/SSL 这个过程，算是初步理解了，扩展阅读给的第一个链接非常不错，简明易懂，这里请教老师几个文章中提到的概念和自己思考的问题： 1. TLS/SSL 建立链接的第四步和第五步中，客户端和服务器都会发送 Encrypt Handshake Message 用于对方做测试使用，这里说需要解密并和 “原串” 对比，不太清楚的是这里的 “原串” 具体指的是什么？ 2. 证书验证部分，客户端需要根据具体算法 “摘要” 得到指纹 P1，然后使用公钥和数字签名解密得到指纹 P2，这里的 “摘要” 指的是什么？ 3. 之前用 node 中的套件调用 Restful API 传输 json 文件进行 server 之间或者 server 和 client 的数据交互，这里是不是默认都是 HTTP 协议呢？如果要改成 HTTPS 的话，需要在 server 上做设定吗，还是说直接在调用套件的时候指明就行？因为没有实做过这一块，如果老师有相关链接分享那是极好的。 问题比较多，劳烦老师指点了，谢谢老师
    展开

    作者回复: 感谢答复！ 第一问，回答举的例子非常好，HTTPS 只能保证连接的可靠，如果连接目标都是错的，那么安全性就无从谈起。 第二问，描述的内容也是正确的，当然，两者都有可以补充的内容。 关于你的三个问题： 1. 无论是客户端还是服务端，对前面所有的传输的数据做一次摘要，再解密对端传过来的消息，二者进行比较。 2. 摘要，其实就是指一种单向的哈希算法，比如 MD5、SHA-1。 3. 这个我不清楚怎样设定。

    共 3 条评论
  • 四喜
    2019-09-15
    请问下关于 Repudiation，否认这项； HTTPS如何保证不被否认的？因为有TLS建立过程，有双方公私钥的参与？

    作者回复: 好问题！ 目前的 TLS 机制无法单独保证 Repudiation（否认），请注意我在文中也写到“第四个问题还需要引入数字签名来解决”。 Repudiation 的解决，必须要靠类似数字签名这样的机制：A 必须收到 B 经过对方私钥加密的消息，这样 A 再使用 B 的公钥解密。而公钥是公开的，也是通过证书等权威形式认证的，所有人都是可以拿到的，公证方一使用 B 的公钥解密，就可以证明这条消息确实来自 B，那么 B 也就无法否认事实了。当然，实际操作的过程中私钥加密的未必是原始信息，也可以是原始信息的散列值，从而保证效率，但效果是一样的，这也是我们看到的数字签名的原理。

    共 3 条评论
  • anginiit
    2019-09-13
    老师 我想问一下 ，那个快速验证，加密的内容是什么 ，服务器端解密后 是怎么知道内容是正确的呢？

    作者回复: 加密的内容包含了前面连接过程所有传输的数据，并进行摘要，得到的这个数据串，发送到对端；而对端也拥有所有的数据，经过同样的摘要，那么它应该和对端传过来的摘要相等。这个过程对于客户端和服务端来说都是类似的。

    共 4 条评论