阿main面试记之HTTPS篇：没有人比我更懂HTTPS了

大家好，我是人见人爱花见花开但是却从不见人从不看花的谢顶道人 --- 老李。

众所周知，阿main最近被「一个神奇的网站」优化调整了一波儿，从家人眼中的「帝都高级白领IT从业人员」摇身变成了老李眼中的「一个潜在的社会不安定因素」。心理上讲他慌乱了几天，他告诉我似乎投递出去的简历都像肉包子打了狗，自己在家放个屁还有点儿味儿呢。不过我看他最近稳了稳神儿，似乎稳住了，其实人一旦冷静下来稳住了，眼中能看到的问题和风险都不叫问题和风险，因为能看到的问题和风险一定会被解决掉，最怕的就是未知的问题和风险。

刀爷给他内推了一把著名搜索公司，他十分开心地面试了一波儿，然后被问到了一坨令人绝望的问题，大概如下：

你们先感受下这些问题换你们能答出来多少。老李今天挑选了其中一个巨经典贼恶心很繁琐的问题：HTTPS是如何保证安全的。

没有人比我更懂HTTPS了

我比任何都更了解对称加解密和非对称加解密

又有谁能比我更清楚协商呢

我比谁都更知道CA了

... ... ... ... ... ... .

HTTPS是数学、密码学与网络通信的集大成者，了解HTTPS整个流程中涉及了众多学科，如果一旦中间某个流程上你陷入细节纠纷那就完了，所以千万不要陷入细节，所以我们尝试先从整个流程上说明白，细节部分都直接黑盒子一把：将军赶路，不追小兔。

再次郑重提醒声明：HTTPS完整流程中涉及到了大量的技术方案名词，HTTPS是众多中技术方案组合起来进行综合运用的结果，而且部分逻辑十分绕弯弯，为了能阐述清楚整个过程，需要先搞明白整个流程，不要陷于其中某个环节或者某个名词的技术细节实现，然后请准备好一张纸画一画流程。

鉴于整个流程说清比较复杂，所以整篇文章我将分为上下两篇文章组成。

在正式开始之前，我先介绍几个名词，请大家直接记住他们存在的意义即可（请开始你的背诵）：

• 对称加解密：常用算法是AES，过程如下A和B通信，双方都使用同一个密钥（比如123456）对数据进行加解密。A先使用123456对数据“ Hello B ”进行加密，然后传送给B，B再利用123456对收到的数据进行解密就可以得到原文“ Hello B ”。对称加解密的目的是为了保证消息的保密性。
• 非对称加解密：常用算法是RSA，过程如下生成一对公钥和私钥，私钥自己持有藏到裤裆里藏好，公钥可以像小广告一样发给任何人。A持有公钥，B持有私钥，A首先利用公钥对消息“ Hello B ”进行加密然后发送给B，B收到消息后利用藏在裤裆里的私钥进行解密得到“ Hello B ”；那B如果想给A发送消息咋办呢？利用藏在裤裆里的私钥对“ Hello A ”进行加密然后发送给A，A收到消息后利用公钥进行解密得到“ Hello A ”，好像没问题是吧？仔细琢磨下，公钥任何一个人都可以从B那里获取到，这样B用私钥加密的消息岂不是大家都能解密？这下可逗逼了...所以非对称加解密的正确使用方法是「公钥加密私钥解密实现加解密」、「私钥加密公钥解密实现数字签名和数字验签」。非对称加解密的目的一是为了保证消息的保密性，二是为了保证消息来源身份三方确认（数字签名的作用）。
• 密钥协商：一种乍一听起来比较神奇的算法，就是A和B可以在交换部分公开数据的情况下，分别在自己这里算出一个相同的数字。举个一个很简单的例子 --- A和B先沟通下都选择好一个相同的数字100（可以公开），然后A自己再选定一个数字比如3（藏到裤裆里），B也自己心里默默选好一个数字比如9（藏到裤裆里），A将3乘以100得到300（可以公开），B将9乘以100得到900（可以公开），然后AB之间互相交换300和900，截止到目前为止A拥有100，3，900三个数字，而B拥有100，9，300三个数字，看好了！A将3乘以900得到2700，B将9乘以300得到2700，2700可以作为一个密钥进行加解密通信了，而且整个过程中2700没有在网络上进行传播。
• 单向散列：这个应该好理解，其实就是哈希，常见犹如MD5或者SHA1、SHA2、SHA3等。单向散列是为了保证消息的完整性，粗暴说就是保证消息没有被篡改。
• 数字签名：非对称加解密中的RSA就可以实现，一般是为了保证消息来源身份三方确认。就是说这个数字签名就是用来确认发送方身份的。这种技术非常厉害，TA对如下问题作出保证 --- B用私钥进行加密生成数字签名，A用公钥对数字签名逆向解密，如果成功就一定表示该数据来源于B；如果有第三个人C利用自己私钥生成数字签名，然后C劫持了B和A中间的网络，C冒充B将自己的数字签名发送给A，那么A利用B的公钥对数字签名进行解密时候，会报错！
• 数字证书：CA们颁发给申请者的，粗暴理解数字证书目的就是「向所有人保证来自于A的公钥真的是来自A的公钥」。数字证书中包含内容有：公钥内容，公钥内容的单向散列值，计算单向散列所用的方法，对钥内容的单向散列值的数字签名，数字证书的颁发日期以及过期时间等等众多内容...其实就是你访问HTTPS网站浏览器里那个玩意，大概长这样：

• CA机构：颁发数字证书的机构。文章中有详解。

第一步：光着腚的数据们

众所周知，只有HTTP的时候，我们信息都是在光着屁股满大街跑的欢，此处不要陷入偷窥癖是如何偷窥我们的细节中。

第二步：对称加解密强顶一波儿

一般说来要「解决数据裸奔」的问题，脑海里第一时间想起来的一定是「对数据加密」，所以我们考虑一下对称加密（友情提示：不要陷入对称加密细节）。对称加密就是你我都用同一个密码对数据进行加解密的方法。应用到场景里就是：广义上的客户端和服务器都持有123456这个密钥，双方在发送数据前先使用123456对数据进行加密，双方收到数据后再用123456这个密钥进行解密。

但是问题来了，广义上的客户端包括手机APP也有浏览器们甚至还有cli客户端，当一个新的网站上线后，浏览器刚开始可是没有123456这个密钥的；手机APP或许还可以通过手机APP直接内置的方式...所以，设计一个接口获取123456？这TM就有点儿扯了...你们仔细感受下，是不是陷入「先有?还是先有?」了？

而手机APP也好不到哪里去，既然123456密钥是内置的，只要努努力总是能扒出来的。

所以这种方法，虽然能用用能xue微顶一顶提高一下成本偷窥成本，但是应用场景有限且没有解决安全问题，所以GG。

第三步：非对称加解密强顶一波儿

既然对称加解密方案有问题，就升级一下：非对称加解密方案（友情提示：不要陷入非对称加解密算法细节）。

非对称加解密大概就是服务器有一对公钥和私钥，其中公钥是对任何人都开放的，而私钥必须是藏到裤裆里绝不能泄漏的。而其使用方法也非常简单：

• 私钥加密的数据，公钥可以解密
• 公钥加密的数据，私钥可以解密
• 公钥和私钥是成双成对的，不可以乱配对乱戴帽

一般说来，正规用法都是：公钥加密私钥解密。因为业务场景都是公钥都是像电线杆子上的小广告那样满天飞的，就是任何人都可以获取到的。所以你感受下「私钥加密公钥解密」这个流程是不是有点儿沙雕？结合一个具体的交互过程你们感受一下：

• 浏览器从服务器获取到公钥
• 浏览器先使用公钥加密数据「一支穿云箭」，然后发送给服务器
• 服务器收到数据「一支穿云箭」，然后使用藏在裤裆里的私钥解密

在这个过程里，由于偷窥的人没有私钥，所以TA毛都看不到，嗯，截止到目前为止，似乎还没有遇到问题，然后我们接着交互：

• 服务器准备应答浏览器，他用藏在裤裆里的私钥加密好「千军万马来相见」，然后返回给了浏览器
• 浏览器使用公钥进行解密

这个过程就比较逗逼了，公钥是公开的，谁都能解开「千军万马来相见」，这太扯了...实际上我在文章开头也提过了，非对称加解密的用法是「公钥加密私钥解密实现加解密」、「私钥加密公钥解密实现数字签名和数字验签」。

如果我们完全不在意服务器返回给客户端数据？假设说服务器返回给客户端的都是OK，加密没有任何意义。

这样就没问题了吗？然而并没有，因为还有个王炸。在众多的偷窥癖里有一类偷窥癖可以顺利成为「夹在客户端和服务器之间的中间人」（此处不要陷入到如何成为中间人的细节中），此时客户端和服务器的交流变成了这样shai儿的，你们感受下：

这种攻击就是传说中的「中间人劫持」攻击，我只画出了前两步，大家可以看到此时非对称加密后的数据此时对于中间来说就是纯透明的。

在客户端面前，中间人就是服务器；在服务器面前，中间人就是客户端。客户端和服务器那些个破事儿全被扒光了。

这有点儿扯，所以也GG了。

第四步：恰饭的CA机构和证书

所以我们看到非对称加解密的方案里，问题根源就直接出在了第一步：获取的公钥本身就是假的。现在问题集中在如何保证第一步沟通里的「公钥」不是伪造这个问题上来了，此时一个恰饭的机构就应运而生了：CA，他们会给你的公钥颁发一个证书，用证书告诉世界上所有人这公钥没问题，俗称证书机构。

这个机构啥意思呢，就是说：我们是全球人类都承认的客观、独立、第三方的机构，管理证书没有人比我们更专业、没有人比我们更懂证书管理、我们比任何人都更加懂保证证书真假。

所以，之前的客户端们、中间人们、服务器们三个主角中，又多来了一位：CA们。现在变成了四方大战、满身大汉！场面一度十分混乱，变成如下这样了，我整理好你们感受下：

• 客户端们
• 中间人们：假公钥假私钥
• 服务器们：真公钥真私钥
• CA们：CA公钥和CA私钥

这里流程就变成这样了，你们看下（听我说，开始动笔画图吧）：

1. 服务器A生成一对自己的公钥私钥，然后将公钥和自己的基本信息发送给CA们。这里的基本信息就是我叫啥、住哪儿、电话号码、域名信息等。
2. 然后这里有一步至关重要的流程，那就是CA们是如何证实公钥就是来自于服务器A的呢？这里一般涉及到的认证方式有很多，比如我们用letsencrypt时候有一种认证方式就是通过DNS来证明，甚至有些通过电话认证，更甚至通过当面+身份ID认证，这里有一个专门的CPS认真业务准则，你们有兴趣可以了解下。总之不必限于细节，我们无条件信任这个流程是100%没问题的即可。这个步骤就杜绝了CA们收到的不是中间人们的公钥，确保一定收到的是服务器们的公钥！
3. CA们自己也生成了一对CA公钥和CA私钥，CA们第一步对你的公钥先进行一次单向散列（其实就是哈希），第二步再利用自己的CA私钥对第一步里生成的单向散列值进行数字签名（这个过程请记住顺序，但是此处不必陷于单向散列和数字签名细节）形成数字证书，给服务器A（PS：这个流程CA们会收费恰饭）。数字证书中包含的内容有：服务器A的公钥明文，服务器A的公钥明文进行单向散列后的值，单向散列的具体算法，单项散列值的数字签名（此处再保留一个问题：如果服务器A得到的数字证书是伪造的呢？）
4. 客户端A所在操作系统中会内置世界上所有CA们的公钥，是的这个不用你操心，反正你操作系统生产商替你包办了这个流程，此处不必陷于细节。这一步确保客户端们得到CA公钥们不是中间人伪造的公钥！
5. 客户端A向服务器A发起请求，服务器A将CA们颁发给TA的数字证书发送给客户端A，此时我们已经知道客户端A已经拥有了：CA们的公钥，CA们颁发给服务器A的数字证书。这一步就算是中间人们发送的假数字证书也无所谓，先往下看第6步。
6. 此处开始高能，请慢慢看流程：首先客户端A再从数字证书中获取到单向散列的具体算法和服务器A的公钥和数字签名，其次客户端A再利用CA们的公钥对数字签名进行「逆向」解密，此处如果解密失败表示有问题。如果没有问题解密成功，将会得到服务器A的公钥的散列值，而散列算法也是已知的，所以客户端A会利用相同算法对服务器A的公钥进行单向散列，然后和数字证书中的服务器A的公钥的单向散列值进行对比，如果不一样，就说明这个公钥不是服务器A的公钥表示有问题。如果客户端计算出来的散列值和数字证书里的散列值一样，就说明完全没问题了。当然还会包括有效期的验证等等，你们应该都见过HTTPS证书过期后是啥样的吧？

我们再回到第3个步骤里保留的那个问题：如果服务器A得到的数字证书是伪造的呢？这个问题实际上已经不存在了，因为第6步里客户端A利用CA公钥对数字签名进行逆向解密的时候，就是验证数字证书真伪的过程。

再经历了上述六个流程后，终于解决了开头的问题：HTTPS向客户端保证了公钥就是来自于服务器的公钥，而不是偷窥者们仿造的公钥，此处就是HTTPS解决中间人劫持的关键。

好了，现在既然已经可以保证公钥没问题，那么就是说客户端和服务器已经可以进行通信了，但是我们依然还有一个问题尚未解决：那就是客户端利用服务器公钥加密数据发送给服务器，这个方向上是没问题的；但是服务器返回给客户端的方向上加密是有问题的，因为服务器私钥加密，但是公钥任何一个人都有！怎么办？

所以在这里，HTTPS又用到了「密钥协商」和「对称加解密」技术（此处不必陷于「密钥协商」细节），流程上讲大概就是先通过「密钥协商」技术协商出一个对称加解密的密钥，然后客户端和服务器再利用这个密钥使用「对称加解密」技术对数据进行加解密工作。

这就是整个HTTPS的大体流程

大佬们，我们可以看到这整个流程中包含了「对称加解密技术」、「密钥协商技术」、「非对称加解密技术」、「单向散列技术」、「数字签名技术」等等，这些技术的综合应用才能完整地走完整个HTTPS流程，这其中的每一项技术都是为了解决某一个步骤中出现的某一个问题，所以一直以来如果想彻底搞明白HTTPS就必须要搞明白很多基础知识以及它们为了解决什么。

HTTPS解决了三个问题：

• 消息的保密性：消息本身是加密的
• 消息的完整性：消息本身没有被中间人修改过
• 消息的发送方确认性：消息一定是从来往于服务器和客户端之间，不存在任何第三方中间人中转

我看了下，现在已经5518字了，今天先到这里：记住今天主要是理清楚大概流程，不要陷于「每项具体技术的具体细节」，总之就是「这项技术就是能解决某个难题」，就行了，下一篇我们将聊具体技术细节。