目录

前言

HTTPS加密原理概述

HTTP 为什么不安全

安全通信的四大原则

HTTPS 通信原理

对称加密：HTTPS 的最终加密形式

非对称加密：解决单向的对称密钥的传输问题

数字证书：解决公钥传输信任问题

证书一整个被掉包怎么办？

总结

其它 HTTPS 相关问题

什么是双向认证？

什么是证书信任链？

为什么不能随便认证第三方的证书？

前言

网上很多讲https加密的文章，很多技术区大佬用专业的话语将https的加密原理讲得很透彻，但是不好理解，自己看了很多篇文章才能理解核心意思。

为了便于后人理解和自己复习，于是自己借助了网上的图和部分文章的摘抄，为了助于理解，对文章的前后逻辑进行了修改和简化，写下了这篇通俗易懂的讲https加密原理的文章。

参考资料：18 张图彻底弄懂 HTTPS 的原理！ (baidu.com)

HTTPS加密原理概述

（此处与下方的总结内容相同）

https的核心本质还是使用高效的对称通信方式来进行传输，但是想使用这种方式就得对这个传输方式的密钥通过各种手段保证可靠。

通过非对称传输密钥的方式，实现了客户端到服务器的可靠性。服务器将公钥给客户端，然后客户端将对称通信的密钥传给服务器，而服务器这边是使用只有自己才知道的私钥才能进行解密的。

为了保证服务器给客户端的公钥是可靠的，服务器向第三方认证的机构CA申请证书，然后服务器再将公钥附在证书上传给客户端。客户端收到证书后，首先判断域名是否为目标域名，然后比对数字签名和使用摘要算法得出的信息是否正确（即验签）。这样即可实现https的加密传输。

HTTP 为什么不安全

HTTP 由于是明文传输，主要存在三大风险：窃听风险、篡改风险、冒充风险。

1.1 窃听风险

中间人可以获取到通信内容，由于内容是明文，所以获取明文后有安全风险。

1.2 篡改风险

中间人可以篡改报文内容后再发送给对方，风险极大。

1.3 冒充风险

比如你以为是在和某宝通信，但实际上是在和一个钓鱼网站通信。

HTTPS 显然是为了解决这三大风险而存在的，接下来我们看看 HTTPS 到底解决了什么问题。

HTTPS 无非就是 HTTP + SSL/TLS。

而 SSL/TLS 的功能其实本质上是：如何协商出安全的对称加密密钥，以利用此密钥进行后续通讯的过程。

安全通信的四大原则

看了上一节，不难猜到 HTTPS 就是为了解决上述三个风险而生的，一般我们认为安全的通信需要包括以下四个原则: 机密性、完整性，身份认证和不可否认。

机密性：即对数据加密，解决了窃听风险，因为即使被中间人窃听，由于数据是加密的，他也拿不到明文；

完整性：指数据在传输过程中没有被篡改，不多不少，保持原样，中途如果哪怕改了一个标点符号，接收方也能识别出来，从来判定接收报文不合法；

身份认证：确认对方的真实身份，即证明“你妈是你妈”的问题，这样就解决了冒充风险，用户不用担心访问的是某宝结果却在和钓鱼网站通信的问题；不可否认: 即不可否认已发生的行为，比如小明向小红借了 1000 元，但没打借条，或者打了借条但没有签名，就会造成小红的资金损失。接下来我们一步步来看看 HTTPS 是如何实现以满足以上四大安全通信原则的。

HTTPS 通信原理

对称加密：HTTPS 的最终加密形式

既然 HTTP 是明文传输的，直接思路就是给报文加密即可。

如下图所示：双方使用对称加密的方式来给报文进行加密和解密。

对称加密具有加解密速度快，性能高的特点，也是 HTTPS 最终采用的加密形式。

（记住这点，这是最终的形式，不要下面看了那么多原理忘了这点。）

但是如果通过报文的方式直接传输密钥，中间人仍然可以劫取密钥，然后篡改内容：

有人说对这个密钥加密不就完了，但对方如果要解密这个密钥还是要传加密密钥给对方，依然还是会被中间人截获的，这么看来直接传输密钥无论怎样都无法摆脱俄罗斯套娃的难题，是不可行的。

下面看另外一种方式，这种方式没法直接解决这把对称密钥的传输问题，但是可以保证单方向（客户端到服务器）对称密钥传输的安全！

非对称加密：解决单向的对称密钥的传输问题

直接传输密钥无论从哪一端传从上节分析来看是不行了，这里我们再看另一种加密方式：非对称加密。

非对称加密即加解密双方使用不同的密钥，公钥和私钥。

公钥加密的密文只有私钥可以解密，私钥加密的内容，也只有公钥可以解密。

那么我们让服务器这边保留有私钥，将公钥发布给其他客户端，让客户端用这把密钥，将上面提到的对称交流的这把密钥传给服务器，然后服务器用自己的私钥即可解密，解密后即可获得那把对称交流的密钥了。

中间人由于没有私钥，所以就算截取了这段报文，也无法解密。

如下图所示：客户端用公钥加密最终密钥，然后传给服务器。

这样保证了从客户端到服务器这段传输的安全性。（但只能保证单向）

上述方法只有单向的安全性，那如何保证初始时服务器向客户端传过来的信息不被篡改呢？

即server 怎么把公钥安全地传输给 client 呢？

因为如果直接传公钥，也会存在被中间人调包的风险。

数字证书：解决公钥传输信任问题

如何解决公钥传输问题呢？从现实生活中的场景找答案。员工入职时，企业一般会要求提供学历证明，显然不是什么阿猫阿狗的本本都可称为学历，这个学历必须由第三方权威机构即教育部颁发。

也就是说我们可以用一个第三者来帮助验证真实性。

服务器向 CA （Certificate Authority，简称 CA）申请证书，在证书中附上公钥，申请的时候会提交 DNS 主机名等信息，CA 会根据这些信息生成证书。

服务器有了证书后，这样服务器传给客户端的不再是公钥，而是含有公钥的证书。这个证书的存在是为了确保传输的这把公钥是正确的。

那有人说那中间人截取这个证书，然后做一个假的证书不就行了？

事实上是证书没有那么容易伪造，因为证书具有防伪造的手段。下面具体讲解

下面的内容较为复杂，什么时候绕晕了，就回头来看看核心思想。

核心思想就是，证书上有两个东西，一个是公开的，一个是加密过的，这个加密的东西只有客户端自己才能解密的而中间人没法解密。

证书如何防伪呢，就是当这两个东西能互相对应时，说明该证书是真实正确的。

具体来说，证书上有两个东西：

  1. 一个是证书信息，是没有加密过的，
  2. 一个是数字签名，是经过CA上的私钥加密过，只有客户端用一开始就存在于操作系统内部存储的公钥才可以解密。

数字签名是什么，有什么作用？

证书的数字签名该如何产生的呢？简单来说就是对证书的各种信息，例如下图：序列号啊、过期时间、DNS等的信息进行随机摘要（例如使用MD5摘要算法）。

  • 提问：为什么要摘要，而不是直接对全部内容加密？

回答：直接对整个内容加密的话，客户端解密会很费时间。

另一方面，一般来说，只要内容不同，产生的摘要必然不同。也就是说摘要相同则证书信息相同。

那验证该证书真伪的方法，就是客户端拿到证书后，也用同样的摘要算法对证书明文计算摘要，两者一比对就可以发现报文是否被篡改了。

提问：那光摘要就可以验证是否被篡改了，那为啥要用第三方权威机构（Certificate Authority，简称 CA）私钥对摘要加密呢？

因为摘要算法是公开的，中间人可以用假的明文替换掉证书明文，再根据摘要算法计算出摘要，然后把证书上的摘要也给替换掉！这样客户端拿到证书后计算摘要发现一样，误以为此证书是合法就中招了。

所以必须要用 CA 的私钥给摘要进行加密，这样的话客户端得用 CA 的公钥来给签名解密。

而这个公钥，是被操作系统信任，内置在客户端的操作系统上的CA证书上的。所以无需传输，因此也不会被劫取。这意味着中间人是没有这个公钥的。

如果用的是 Mac 的同学，可以打开 keychain 查看一下，可以看到很多内置的被信任的证书。

我们接下来看，服务器将证书传给客户端后，客户端的验证签名过程如下：

服务器传输 CA 颁发的证书，客户收到证书后使用内置 CA 证书中的公钥来解密签名，然后对信息生成摘要，判断二者是否相同即可。如下图所示

于是：

如果客户端收到的证书中，数字签名被篡改，该证书上的数字签名使用 CA 的公钥是无法解密的。

如果客户端收到的证书中，证书信息被篡改，那么对该信息做出来的摘要肯定也是错误的，那么和真正的数字签名就会比对不成功，客户端也会认定此证书非法。

这样的话就解决了公钥传输过程中被调包的风险，保证了从服务器到客户端传输的公钥是真实正确的。

证书一整个被掉包怎么办？

不过此处还有一个问题，上面是实现了，利用证书的两部分信息互相验证的机制保证正确。

如果证书一整个被调包怎么办？

实际上任何站点都可以向第三方权威机构申请证书，中间人也不例外。

正常站点和中间人都可以向 CA 申请证书，获得认证的证书由于都是 CA 颁发的，所以都是合法的。

于是假如客户端收到的是一个 被掉包，但是合法的证书，那进行上面的验证签名的过程自然不会有问题。

那么此时中间人是否可以在传输过程中将正常站点发给 client 的证书替换成自己的证书呢，如下所示：

上图的思想看上去好像很完美，但是有一个致命的弱点！

答案是不行，因为客户端除了通过验签的方式验证证书是否合法之外，还需要验证证书上的域名与自己的请求域名是否一致，中间人中途虽然可以替换自己向 CA 申请的合法证书，但此证书中的域名与 客户端请求的域名不一致，客户端会认定为不通过！

于是，这样就实现了https的加密功能了。

总结

https的核心本质还是使用高效的对称通信方式来进行传输，但是想使用这种方式就得对这个传输方式的密钥通过各种手段保证可靠。

通过非对称传输密钥的方式，实现了客户端到服务器的可靠性。服务器将公钥给客户端，然后客户端将对称通信的密钥传给服务器，而服务器这边是使用只有自己才知道的私钥才能进行解密的。

为了保证服务器给客户端的公钥是可靠的，服务器向第三方认证的机构CA申请证书，然后服务器再将公钥附在证书上传给客户端。客户端收到证书后，首先判断域名是否为目标域名，然后比对数字签名和使用摘要算法得出的信息是否正确（即验签）。这样即可实现https的加密传输。

其它 HTTPS 相关问题

什么是双向认证？

以上的讲述过程中，我们只是在 client 端验证了 server 传输证书的合法性。

但 server 如何验证 client 的合法性呢？

还是用证书，我们在网上进行转账等操作时，想想看是不是要先将银行发给我们的 U 盾插到电脑上？其实也是因为 U 盾内置了证书，通信时将证书发给 server，server 验证通过之后即可开始通信。

画外音：身份认证只是 U 盾功能的一种，还有其他功能，比如加解密都是在 U 盾中执行，保证了密钥不会出现在内存中

什么是证书信任链？

前文说了，我们可以向 CA 申请证书，但全世界的顶级 CA（Root CA） 就那么几个，每天都有很多人要向它申请证书，它也忙不过来啊，怎么办呢？想想看在一个公司里如果大家都找 CEO 办事，他是不是要疯了，那他能怎么办？授权，他会把权力交给 CTO，CFO 等，这样你们只要把 CTO 之类的就行了，CTO 如果也忙不过来呢，继续往下授权啊。

同样的，既然顶级 CA 忙不过来，那它就向下一级，下下级 CA 授权即可，这样我们就只要找一级/二级/三级 CA 申请证书即可。怎么证明这些证书被 Root CA 授权过了呢，小一点的 CA 可以让大一点的 CA 来签名认证。比如一级 CA 让 Root CA 来签名认证，二级 CA 让一级 CA 来签名认证,Root CA 没有人给他签名认证，只能自己证明自己了，这个证书就叫「自签名证书」或者「根证书」，我们必须信任它，不然证书信任链是走不下去的（这个根证书前文我们提过，其实是内置在操作系统中的）

证书信任链现在我们看看如果站点申请的是二级 CA 颁发的证书，client 收到之后会如何验证这个证书呢，实际上 service 传了传给二级 CA 的证书外，还会把证书信任链也一起传给客户端，这样客户端会按如下步骤进行验证：

浏览器就使用信任的根证书（根公钥）解析证书链的根证书得到一级证书的公钥+摘要验签；拿一级证书的公钥解密一级证书，拿到二级证书的公钥和摘要验签；再然后拿二级证书的公钥解密 server 传过来的二级证书，得到服务器的公钥和摘要验签，验证过程就结束了。

为什么不能随便认证第三方的证书？

上面的证书调包给了我们一种思路，什么思路？

大家想想，HTTPS 既然是加密的， charles 这些中间人为啥能抓到明文的包呢？其实就是用了证书调包这一手法，想想看，在用 charles 抓 HTTPS 的包之前我们先要做什么，当然是安装 charles 的证书。

这个证书里有 charles 的公钥，这样的话 charles 就可以将 server 传给 client 的证书调包成自己的证书，client 拿到后就可以用你安装的 charles 证书来验签等，验证通过之后就会用 charles 证书中的公钥来加密对称密钥了。整个流程如下：

由此可知，charles 这些中间人能抓取 HTTPS 包的前提是信任它们的 CA 证书，然后就可以通过替换证书的方式进行瞒天过海，所以我们千万不要随便信任第三方的证书，避免安全风险。

最通俗易懂的讲解HTTPS的加密原理【多图、易懂】相关推荐

  1. 你是否了解HTTPS的加密原理？（面试常问）

    梦梦前段时间面试,以及工作之后负责的模块多多少少都会涉及到一些网络协议的知识,今天就抽出时间整理了其中两个常见的协议:HTTP和HTTPS的区别. 什么是网络协议? HTTP和HTTPS的基本概念 H ...

  2. 通俗易懂的讲解二极管三极管工作原理

    本文转自:https://www.zhihu.com/question/25032358 https://blog.csdn.net/a10615/article/details/51627619 先 ...

  3. HTTPS接口加密和身份认证

    1.为什么要用HTTPS代替HTTP HTTPS和HTTP的区别 1)https协议需要到CA申请证书,一般免费证书很少,需要交费 2)http是超文本传输协议,信息是明文传输,https则是具有安全 ...

  4. https与http的区别以及https加密原理

    https与http的区别以及https加密原理 一.什么是HTTPS 二.为什么要用HTTPS替代HTTP 三.HTTPS 与 HTTP 的区别 四.HTTPS如何解决HTTP上述问题? 1. 对称 ...

  5. Https 加密原理分析

    众所周知,HTTP 协议通过明文传输,是不安全的.于是,就在 HTTP 协议的基础上,进行了数据加密,也就诞生了 HTTPS 协议.注意,HTTPS 并不是一个新的协议,它只不过是在 HTTP 的基础 ...

  6. HTTPS加密原理(转)

    Header HTTP.HTTPS在我们日常开发中是经常会接触到的. 我们也都知道,一般 Android 应用开发,在请求 API 网络接口的时候,很多使用的都是 HTTP 协议:使用浏览器打开网页, ...

  7. 解析HTTPS加密原理

    文章目录 一.背景 二.工作过程 1. 对称加密 2. 非对称加密 3.中间人攻击 4. 公证机构 三.HTTPS加密原理总结(重点) HTTPS简单来说,就是HTTP的兄弟,不同的是, HTTP是明 ...

  8. mos管工作原理动画图讲解_MOS管工作原理电路图简述【通俗易懂】

    mos管工作原理动画图讲解_MOS管工作原理电路图简述[通俗易懂] 发布时间:2020-01-18 09:06人气:461 很多朋友对mos管原理都不是太了解,今天小编就给各位普及一下关于MOS管工作 ...

  9. HTTPS 加密原理

    主要内容: HTTPS 加密原理.CA证书链验证过程.通信过程 为什么需要加密? HTTP 协议缺点: 通信使用明文,内容存在被窃听风险 不验证通信双方身份,可能遭遇伪装 无法验证报文完整性,可能遭篡 ...

最新文章

  1. 实验6-选第K小元素
  2. linux java 获取路径怎么写_linux中java获取路径的实例代码
  3. 计算机技术基础期末考试,《计算机网络技术基础》期末考试试卷
  4. PKUWC2020游记与题面整理
  5. python简单小游戏代码_一个简单的python小游戏---七彩同心圆
  6. nginx mozilla_我发现Mozilla的私人浏览模式存在重大缺陷。
  7. 离散余弦变换原理及实现过程【转载】
  8. 售票系统的组件图和部署图_门禁安装大样图、管线图、系统图、电锁安装图
  9. idea java代码格式化_IDEA java 代码格式化统一
  10. Peer-To-Peer 综述（P2P技术综述）
  11. ug齿条插件_NX9.0齿轮齿条运动仿真—齿轮工具箱巧用及渐开线制作
  12. 云上财务经营的成本管理
  13. 肿瘤基因检测的解读流程
  14. 自动驾驶域控制器话题下的软件系统设计和研发管理
  15. ASUS华硕天选2 FX506H INTELI711代CPU 原装出厂系统恢复原厂系统
  16. SMS短信PDU编码详细解析
  17. Qt软键盘使用和修改软键盘参数 支持中文
  18. mongoose http 源码解析(1)
  19. 牛客小白月赛28 J.树上行走
  20. 工行融e联，绿色通道便捷办理

热门文章

  1. python中label函数_python实现在函数图像上添加文字和标注的方法
  2. Redis一打开一闪而过，没有出现主界面的解决办法及原因
  3. 最方便的短信发送平台：中国网建
  4. error: cannot lock ref ‘refs/remotes/origin/release/xxxx‘: ‘refs/remotes/origin/release‘ 已存在，无法创建
  5. C++程序启动时报“0xC000007B”无法启动的问题排查
  6. Ubuntu16.04如何设置自动休眠时间
  7. 假如魔兽由其他公司来做
  8. python 图灵完备_区块链学习6：图灵完备和图灵不完备
  9. 360快传号，会成为下一个自媒体风口吗？
  10. 计算机网络工程职业学院,湖南网络工程职业学院理工学院