HTTPS为何封神，密码学是如何将其推向神座

很高兴又能与各位读者见面，在之前的文章中笔者曾提到，HTTP是被公认的在互联网上使用最多的协议。而在实际生活中我们却发现，目前大多数网站采用了HTTPS技术。首先来看下图：

当用户使用chrome浏览器打开百度时，会自动发起HTTPS请求，图中红框里的小锁图标代表着使用的是安全的HTTPS协议。这难道说明优秀的HTTP协议早已经不香了？这肯定不能够。HTTPS=HTTP+SSL。客户端与服务端的的交互依旧使用HTTP的方法，只是在其外面加了层衣服，导致互联网的黑客无法读懂内部的内容。

为啥要穿上衣服？这里就要提到HTTP的不安全性，HTTP默认不带任何加密和验证机制。所谓加密很好理解，就是对报文加密，谁都读不懂。而验证则代表服务端可以感知到报文是否被篡改，可惜的是HTTP并不具备这些功能。就像我给朋友转了一千元，黑客截取报文后，把一千改成了一，导致朋友只收到一元，相信这种事是谁都无法忍受的。但现实中这种情况却基本不曾发生。这里除了应用层面本身逻辑机制的保证以外最大的功劳要归属于HTTPS。因为我们给HTTP穿上了SSL的衣服。对于HTTP+SSL我们看下面这张图：

快递相信大家都寄过，我们把想要给对方的文件放入快递袋形成一个包裹。包裹经过快递公司的传送，最终达到对方手中。在正常情况下，包裹里的内容是安全的。对方收到后，拆开快递袋，也会拿到其想要的文件。但也会存在特殊情况，例如包裹在传输过程中丢失，那么捡到该包裹第三方则可随意阅读包裹中文件的内容。

SSL实际上就是起的快递袋的作用，将HTTP报文封装起来。但跟快递的本质区别是，即使我们的报文在公网被截取，窃取者也根本无法读懂，即这个快递袋拆不开。这貌似说的挺绝对，那么是否有高手真的能解开SSL，读取篡改里面的数据呢？任何事情都不能说是100%的肯定，但如果真有这样的情况，其不仅需要超高的技术还需要不太可能存在的运气成分。这里所说的运气比中彩票的几率还要小的多，故称为不太可能存在。

那么SSL是如何做到这一步的，下面的章节将逐渐带您进入这一迷人的领域。

在上一个章节，笔者吹嘘了很多。那么既然夸出海口了，最后是否又能自圆其说，本节带您逐渐开始深入了解。首先，想要了解HTTPS，必须要对密码学有一定认识。

密码学我们抛开复杂的定义，直接进入正题。世界上最广为人知的密码就是凯撒密码，以伟大的尤利乌斯凯撒的名字命名。其原理为把一个字母向后偏移3位，即A变为了D。当凯撒想发送一段命令给将军们的时候，例如他想发的命令原本是ABC，经过刚才提到的算法ABC会变为DEF。当将军们拿到DEF时会反推出原本的内容得到ABC这个真实的命令。这就是最简单的密码学，将原本的内容加密传输，第三方即使获取了DEF这个信息，也并不知道真实的意思。当然该算法的缺陷就是过于简单，且第三方如果截取了内容，可以把DEF篡改为XYZ。这就导致将军们解密后可能会根据错误的命令做出错误的决定。不过，这是在古罗马时期就出现的密码，其也为后续密码学的发展起到了奠基作用。

初步认识之后，我们要了解密码学发展至今具体有哪几类算法。其主要算法分为对称加密、非对称密加密（也叫公钥密码学）、哈希散列算法等。上面提到的凯撒密码可以归类为对称密码学的一种。后面，笔者将带大家一一了解。

 对称加密  

对称加密实际上很简单，假如有一个原始数据为A，A代表一串要被加密的数据，然后选择一个对称加密算法，再使用密钥X对A进行数据加密，然后得到一个被加密的密文简称B。类似下图：

那么如何将B解密为A呢，直接使用算法加上密钥X进行解密即可得到原文：

实际上，现在我们理解了为什么叫对称，因为加解密的密钥都是用X，而算法是一组规则，就像加法对应减法一样。常见的对称加密算法有DES，3DES，AES等，其中AES算法目前最为安全。既然能称为算法，那必然具有其复杂性。发明算法的都是天才般的数学家。像笔者这种凡人只能是站在巨人的肩膀上去应用这些算法。对于其深入的原理，以笔者的智商就不给自己添堵了，有兴趣的伙伴可以去深入学习。

 非对称加密  

在了解对称加密后，我们接下来开始接触非对称加密，也叫公钥密码学。废话不多说，看图：

从图中我们可以发现，非对称和对称的根本区别在于加解密密钥的不同。原文A被X加密后成为B，而B却要被Y解密才能得到A，这就是非对称加密的核心魅力。目前常见的非对称加密算法有：RSA，DH，国密SM2等。其中RSA被广泛使用，DH则是IPSEC所使用的核心算法。而国密SM2是我国自己发布的算法，复杂度最高。刚才提到非对称加密又叫公钥密码学。这是怎么个情况？其实还是拿X和Y这两个密钥来说。我们先定义X为公钥，Y为私钥。如字面意思X是需要对公发布的而Y是务必要自己保留的，也就是说私钥Y绝对不能泄露。这个时候客户端把原文用X加密，发送给服务端，而服务端用自己的Y解密。问题就解决了，貌似很完美。

 真的如此完美？  

从上面看，问题应该解决了。当客户端把数据发送给服务端的时候，无论用对称还是非对称加密，报文都是加密的，谁也看不懂。但我们不要高估黑客的心理承受能力。他看不懂，胡乱篡改还不行吗。把上面说的密文B改成C，服务端拿到C，鬼知道C解密出来是个什么玩意。那怎么办，无解了？优秀的天才数学家们岂能被此等小事拖住前进的步伐，故之前提到的哈希算法随之出现。

 哈希散列算法  

依旧抛开网上复杂的定义，哈希就是把任意长度的数据打散，随后通过算法生成一个定长的数值。拿MD5算法举例来讲，数字1被哈希后会得到一个128位定长的数值，我们姑且称之为a。数字2被哈希后也会得到一个128定长的数值，我们称为b。首先一般把a和b称为摘要，同时a和b一定都是128位，且重点是a绝对不等于b。更令人震惊的是永远不可能有人利用所谓逆向工程把a反推回1，b也同理。但这有什么作用，看图：

这块先从客户端说起，客户端要发送一个原文，会先对原文进行哈希，得到原文摘要，同时把原文加密得到密文，密文和原文摘要组成了整体报文。随后经过网络传输发送至服务端。服务端收到后，将密文解密得到解密后的数据，再把此部分进行哈希得到解密后的数据的摘要，将此摘要与客户端发过来的原文的摘要进行对比。如果相同，代表数据未被篡改。这个原理也很好理解，如果密文被篡改，解密后得到的数据将与原文不一致，从而摘要一定与原文摘要不一致。这个时候服务端就能感知到数据一定被篡改，随后丢弃该报文。

至此密码学基础介绍完毕，实际上密码学保证了数据的机密性和完整性。机密性就是传输过程中即使被窃取，但谁也看不懂。而完整性代表即使数据被篡改，通信双方也有能力感知。

通过上一章节的介绍，我们看似完美的解决所有问题。把报文加密让黑客看不懂，通过对比摘要来确认报文是否被篡改，通信双方由此可以高枕无忧。但其实还有一个至关重要的细节，那就是如何交互密钥。假如密钥是X，先不管X是对称加密的密钥还是非对称加密的公钥，反正服务端希望客户端用X加密报文。这时如果服务端简单的告知客户端，你用X加密报文吧，但这个时候黑客刚好截取了此消息，随后把服务端告知客户端的密钥X这个消息进行篡改，把X改为Y，随后再发给客户端，客户端此时完全无能力感知，其会永远认为服务端就是希望我使用Y密钥与其加密进行通信。这同样会造成通信双方的混乱，无法正常通信。

 初步认识CA及数字证书  

当然，这个恼人的问题依旧无法阻挡互联网事业的蓬勃发展，CA随即站出来解决了这最后一个问题。CA全称Certificate Authority，是证书颁发机构，用来颁发数字证书。可能很多朋友读到这里都有些懵了，感觉这套机制有些复杂，什么是数字证书也没听说过。没关系，加把劲朋友们，这是我们通向真理的最后一道关卡了。

一步一步来，先简单认识一下证书。看图：

依旧先用浏览器打开百度，点开域名输入栏旁边的小锁，随后点开弹出小页面的证书（有效），接下来出现了下图：

忽然发现出现了一个叫证书的东西，这就是刚才说的数字证书，同样也能看到证书是颁发给baidu.com的。颁发者叫GlobalSign Organization Validation CA- SHA256-G2，这个颁发者就是大名鼎鼎的CA。这个CA将这张数字证书颁发给了百度，同样还有个有效期。目前看来，百度是有证书的。其实CA也有自己的证书，先不用管这些证书干嘛用的，看看CA的证书再说。

第一步，打开浏览器设置，选择左侧隐私设置和安全性，再点击安全：

然后再里面翻阅的时候发现，确实有刚才提到的GlobalSign Organization Validation CA-SHA256-G2：

至此我们见识了证书，但并未提及这部分的原理。现在笔者将为这冲向胜利的最后一战吹响冲锋号。

 数字证书的签发  

还是用百度来说明，百度首先针对baidu.com这个域名生成一对公钥X和私钥Y，私钥Y自己保留，公钥X交给这个叫GlobalSign的机构。GlobalSign会为公钥X生成一个数字证书，再返还给百度。这样百度手里同时拥有了私钥Y以及包含公钥X的证书。

流程是这样没错，但重点是制作证书的过程。首先作为CA的GlobalSign在拿到公钥X后，会开始制作证书，证书包含许多信息，再打开百度证书看看：

点击详细信息后，可以看到证书包含颁发者、有效期、使用者、那个公钥X还有一堆附加信息，这些先称之为证书主体。随后CA会对该证书主体进行一遍哈希得到摘要。最后CA会用自己的私钥对摘要再进行加密（CA同样拥有自己的公钥和私钥）。这个被CA加密过的摘要叫数字签名，证书主体及数字签名组成了完整的证书。

CA在生成了完整证书后，会把此证书交付给百度。这样百度手里攥着私钥Y和一个公钥X的完整证书。既然倚天剑屠龙刀都在手了，那血雨腥风不可避免了。

 完美解决了所有问题  

接下来就是客户端访问百度时发生的事了。客户端会把百度的公钥X证书获取至本地，随后将完整证书一分为二，分为刚才提到的证书主体和数字签名。接下来对证书主体进行哈希，同时将数字签名解密。数字签名解密？咋解密？别忘了数字签名是CA私钥加密的，还记得我们浏览器里有CA的证书吗，CA证书包含啥？证书是不是都包含公钥？没错，我们抽出CA证书中的CA公钥对数字签名进行解密，然后得到的就是加密前的证书主体的摘要。此时证书主体已经被哈希了，也形成了摘要，此时两个摘要进行对比，如果完全一致，则大功告成，证明客户端在请求百度证书时，证书在传送过程中并未被篡改。

此时，客户端自信的认为百度要告诉自己的密钥就是X，于是用X加密数据，百度收到数据后用私钥Y解密。通信过程完美保障。

最后再说一下CA，CA不光只有GlobalSign这一家机构，国内外有众多CA机构。作为企业，需要根据自身情况及性价比等选择适合自己的CA机构申请证书。且刚提到的GlobalSign Organization Validation CA-SHA256-G2这个东西不是顶级CA，而是中级CA。有关这块内容，笔者不在赘述了。有了刚才的基础，朋友们自行百度一下就能很快掌握。最后提个概念，刚才提到的这一系列流程和知识就是传说中的PKI体系。简简单单的一篇文章不可能阐述整个体系，旨在为大家入门。

上两个章节主要探讨了密码学和CA的相关知识，却忽略了本文的重点SSL。没关系，作为本文最后一个技术章节，将为大家展现，SSL是如何为HTTP穿上嫁衣的。这部分内容就很简单了，有了前面知识的铺垫，只需了解SSL是如何运用这些技术即可。

SSL协议分为握手协议和记录协议，这里只探讨SSL握手时发生的事情。看图：

不是说最后很简单么，咋交互过程这么复杂。别紧张，我们只需要了解前5个报文即可。其中前四个报文以明文传输，最后一个加密。

1. Client hello：第一个报文由客户端发送hello，告知服务端，自身支持的SSL版本，支持的加密方法等。还会告诉服务端一个随机数，例如是A，先记住A，不管有什么作用。

2. Server hello：当服务端知道有人向他打招呼，他也会很友好的回复hello。同时会告知服务端支持的SSL版本，支持的加密方法以及一个随机数B，同样先记住B。

3. Server certificate：随后重点来了，服务端会把自己的数字证书发给客户端。客户端收到后会通过查看证书有效期、域名信息，还会通过第三章所讲方法来验证证书是否可信。

4. Server hello done：这个没啥好说的，客户端告诉服务端，我打完招呼了。

5. Client key change：第五个报文，客户端会告诉服务端一个X，这个X名称为预主密钥。这个X会被加密，密钥用的就是刚才数字证书中的公钥。

至此SSL最重要的前5个报文介绍完毕。接下来该分析客户端和服务端目前手里有什么。从客户端来讲，手里有自己生成的随机数A，服务端发来的随机数B，以及自己生成的预主密钥X。而服务端手里有客户端发来的A，自己生成的B以及客户端发来的一段密文。服务端会用自己的私钥解开密文，得到原始数据X。好了，现在客户端和服务端手里都有A、B、X三个数，随后通过这三个参数，双方通过一个算法算出一个数，先简称为Y。Y是什么，其实是一个对称加密的密钥。对称加密？SSL这套体系不都应该是非对称的吗？对！您没听错。SSL握手阶段使用了非对称加密的技术，但HTTPS实际上在传输HTTP内容数据的时候用的都是对称加密算法。这里要重点了解两点：

1. 为什么使用对称密钥加密HTTP数据，因为非对称加密算法非常复杂，会过度消耗服务端计算资源，故导致整体交互速度降低，会影响对用户的体验。

2. 密钥Y，并不是由服务端直接告诉客户端，而是通过交互几个随机数算出来的。就像假如密钥是数字6，并不是直接把6告诉对端，而是双方之前交互了1、2、3这三个数，由1+2+3=6得出的。这样更能保证安全性，当然算法肯定不会是加法。

实际上笔者想阐述的SSL内容就这么多。SSL完美利用了密码学和PKI体系将HTTP包裹的万无一失。

其实当笔者一开始接触SSL的时候也是一头雾水，但在笔者启蒙老师的带领下，逐渐通过学习，了解SSL的真正魅力。当豁然开朗的那一瞬间，笔者内心有的只是无比的敬佩及感叹。对那些发明密码学的天才数学家以及那些将密码学知识完美的应用到互联网上的先驱者，笔者愿把他们的成就称为绝活。正是因为有无数的天才投入到IT事业中，IT事业才能如此蓬勃发展。笔者作为一个小学徒，永远不能停下，要一直追随先驱者们伟大的脚步，不停向前迈进。

最后跟各位朋友留个思考题，有人说MD5已经被破解了。在第二章中笔者曾提到过哈希算法永远不可逆。那到底是笔者在信口雌黄，还是这句话有其他含义，请谈谈您的看法。

往期回顾

欢迎关注EBCloud