本来的主题是介绍一下我之前做的搜索与推荐的业务，但9月份开始我主要开始承担一些医那块的业务测试，就想做点别的分享，但换成医的业务介绍，想了想我目前对医的了解程度，实在没勇气拿出来分享，所以就换了这个主题。
这个主题其实也是早有预谋，一个初衷是想对某一个通用性的技术，说白了就是跑到哪里都能用上的技术，利用1个小时左右的时间里能够和大家一起对它进行探讨学习。
针对通用性，我举个例子，目前我们说到要做性能，就需要用到什么平台？在座的很多大佬应该都用过，王明啊王鑫啊进标啊，有几个人可能还参与到研发过程。是莫扎特，但是大家对这个平台了解多少，有没有从头到尾梳理过莫扎特的源码，如果没有，那其实就只是使用平安健康公司的一个平台完成一个日常工作任务，如果没有莫扎特平台，或者我说直白点你假使有一天想换个公司，你还能完成压测任务吗？这个我相信大家都有过思考。。。。。。。。
那你在当前公司里能用上，甚至跑到哪都能用上的技能就具有通用性。
这里我解释下就是，这么说不是为了鼓励大家离职啊，只是解释了一下通用性这个词。
然后，我之前想再研究下这个https的原因，就是在国际化部门的时候，想对一个https接口做压测，但是当时国际化那一套莫扎特不支持，所以用的JMeter，这个工具大家应该也都用过或者至少听过，这就涉及到证书的配置，当时就深入了一下https。
所以本次分享可能会给我们带来以下收获：
理解HTTPS原理的概念
什么是对称加密和非对称加密？
什么是数字签名？怎么生成？怎么校验？
啥时候是对称加密？啥时候是非对称加密？啥时候进行算法加密？什么算法？
第三方机构包含哪些？
HTTPS 是什么？具体流程
HTTPS和HTTP的区别
现在网站为什么不都用HTTPS？
对称加密、非对称加密的概念
HTTPS的加密机制
不止了解它是什么，更要了解为什么是它，那样才能深刻！同时也能感受到人类的智慧是很伟大的！
废话我就不多说了，我们开始今天的分享。虽然大家都很忙，但诚恳希望大家也能既来之则安之，能够稍微浪费点脑细胞，我们一起感受下什么叫从入门到放弃。
HTTPS就是在传统HTTP协议上引入了一个加密层，
为什么需要加密？
有部比较老的电视剧，讲的是清末宫廷内斗的故事。有个场景就是有人想要谋反干掉慈禧，恭亲王奕䜣得到密报，上了一份折子，为了掩人耳目呢，上面看似都是些拉家常的话，但是只要套上一张挖了洞的纸，就能看到真正要说的话：
慈禧先发制人悄无声息的把这些人一锅端。今天从历史角度看这些人到底算忠还是奸暂且不说，从这个上面可以引出来我们今天主题涉及到的一些概念：
奏书全文： 密文（加密后的内容）
当心肃顺，端华，戴恒： 明文（解密后的内容）
挖了洞的纸： 密钥（解密的工具）
如果不加密，可能会导致机密泄露，打草惊蛇，对方提前行动，来不及应对。加密的重要性对于古代尚且如此，对于今天日渐恐怖的互联网来说，更是不可或缺。
目前，加密有好多种方式，上文中提到的奏折加密，今天就叫做对称加密。
密钥像一把钥匙一样，可以锁上门，也可以打开门。
但是这样安全吗？
首先我们知道你向服务器发送请求，整个传输过程是可以在很多阶段被劫持的，只要有一次被劫持，密钥就被拿到，来往所有的请求，在劫持者那边都是没穿衣服的裸奔状态。
那有办法解决这个问题吗？
浏览器和服务器各自生成两个密钥，一个叫公钥，一个叫私钥，传输内容可以用公钥加密，但必须要私钥解密。这种方式叫做非对称加密。
怎么样实现公钥加密，私钥解密？
这是一个比较深入而且难啃的技术，暂且不在我们今天讨论范围之内。我们只需要了解有这个加解密方式，有兴趣的话后面可以再一起深入探讨。
服务器公钥A，私钥A，浏览器公钥B，私钥B
两方数据传输，数据都通过自己的公钥加密，对方用私钥解密。
这样看上去是可行的。但是HTTPS没用！为什么？最大原因是这种非对称加密非常耗时，比起对称加密效率低很多。那我们能否结合一下两者，保证数据安全的情况下，保证下性能呢？
非对称加密+对称加密
1.某网站拥有用于非对称加密的公钥A、私钥A’。
2.浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
3.浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
4.服务器拿到后用私钥A’解密得到密钥X。
5.这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。
完美！HTTPS基本就是采用了此方案。但是矛与盾永远同时在升级。
如果在数据传输过程中，中间人劫持到了数据，此时他的确无法得到浏览器生成的密钥X，这个密钥本身被公钥A加密了，只有服务器才有私钥A’解开它，然而中间人却完全不需要拿到私钥A’就能干坏事了。请看：
某网站有用于非对称加密的公钥A、私钥A’。
浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
服务器拿到后用私钥A’解密得到密钥X。
攻击者狸猫换太子，抓住了浏览器无法知道服务器传给它的公钥已经被调包的漏洞，从浏览器手里成功骗取到了浏览器的密钥X。
怎样才能防止单纯的浏览器被骗呢？
可能有人会想到，传输公钥的时候，也进行非对称加密，但这是套娃，最上面一层的非对称加密使用的公钥，永远都需要明文传输。
一般剧情发展到这边，就需要有个中间商站出来赚取差价，这个中间商叫做CA（Certificate Authority，证书授权）机构，它是当今互联网世界正常运作的前提。网站需要使用HTTPS，可以向CA机构申领一份数字证书。其中含有证书持有者信息，公钥信息，hash算法等。
服务器把证书传给浏览器，浏览器从中获取服务器公钥。
CA机构颁发的数字证书有自己的一套防伪技术。
来源：https://cheapsslsecurity.com/blog/digital-signature-vs-digital-certificate-the-difference-explained/
数字签名的制作过程：
CA机构拥有非对称加密的私钥和公钥。
CA机构对证书明文数据用私钥加密，得到数字签名。
（其中有一步是对数据进行hash，这么做一个是性能问题，hash算法可以将任意长度的二进制值引用为较短的且固定长度的二进制值，所以处理速度会更快。另一个也有安全原因，这个相对较深，感兴趣可以参考
https://crypto.stackexchange.com/questions/12768/why-hash-the-message-before-signing-it-with-rsa/12780#12780）
明文和数字签名共同组成数字证书，颁发给网站。
浏览器拿到服务器传来的数字证书后，需要验证它是不是真的（有没有被篡改、掉包），过程如下：
拿到证书里的明文数据和数字签名后，
用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S’。
用证书里指明的hash算法对明文D进行hash得到D’。
显然通过以上步骤，Data’应当等于S‘，除非明文或签名被篡改。所以此时比较S’是否等于T’，等于则表明证书可信。
这种方式还可能被篡改吗？
要篡改必须拿到CA机构的密钥，不可能。
可能整个证书被调包吗？
攻击者是否可以模拟之前获取浏览器密钥X的方式获取到服务器传给浏览器的证书，再换成自己的证书B传给浏览器，浏览器拿到B里的公钥，用此公钥加密浏览器密钥X后发出去呢？证书里关于网站的信息有很多，浏览器拿到证书后解密，
