什么是HTTPS？
HTTPS是在HTTP的基础上添加了SSL，保证了数据在传输过程中能够通过加密而不被窃取到。
HTTP有什么问题
HTTP是明文传输，有时候我们在访问网站信息的时候并不希望被其他人看到，比如一些转账、管理员登录，又或者是普通用户的一些私密信息等等，类似这样的敏感数据一旦泄露，就会给服务造成严重的安全问题，对于攻击者而言只需要通过一个简单的抓包工具就能轻松截取到这些信息。
所以我们的目的就是让原本明文传输的数据能够得到隐藏，让截取到的人看不懂。
首先能想到的肯定是加密，假设用户要通过浏览器向服务端请求数据，想想要如何加密？之后我们都要围绕这个问题进行一步步分析。
第一版
1、正常的数据请求
2、加密后数据请求
3、如何让服务端明白？
3.1、按照双方约定好的方式，简单来说就是密钥和算法写死在js里面，服务端也一样写死在后端代码中
现在通过抓包看到的请求数据已经是加密过的了，直接看是看不懂的，但是这样有问题吗？加密的方式被写死在了js文件或者任意的前端文件中，那么攻击者直接通过浏览器开发者工具都能找的到，拿到密钥后就可以对文件进行解密。
3.2、所以要改进一下，密钥不能写死，而是每次在请求时随机生成。
现在通过网络传输的方式告诉服务端解密的方式，而不是直接写死在代码中了，但是很遗憾这样依旧存在问题，如果解密的方式存在网络传递过程中，那么拦截者一样能够截取到解密的算法，所以这样加密也是无效的。
第一版最终存在的问题
以上的这种方式是通过对称加密算法来对数据进行加密，客户端可以把原始数据+密钥拼接起来，然后通过加密算法进行加密，要想解密只需要获取密钥调用相关算法的解密方法就可以解出来，所以对称加密的关键就在于密钥不能丢，但是客户端为了让服务端能够解密出来，又必须要把解密的算法（算法+密钥）告诉服务端。
第二版
现在要解决的问题就变成了如何把密钥安全的告诉服务端，而不让别人知道。
该非对称加密上场了。
非对称加密的特点在于密钥有一对，一个公钥，一个私钥，公钥通过私钥生成，公钥加密的数据，公钥解不开只有私钥才能解开（这是解决问题的关键）。
假设服务端把生成好的公钥告诉浏览器，之后浏览器请求数据时，通过公钥对请求的数据进行加密，再传到服务端，由于公钥加密的内容，拿公钥是解不开的，所以公钥在网络中进行传输被截取到也不用担心，这样是不是就解决了对称加密时密钥传输的问题了。
很明显私钥是不能泄露的，公钥是对外公开的，所以私钥肯定是放在服务器，公钥放在客户端。
1、向服务器请求公钥
服务端通过私钥生成公钥，私钥自己保存，然后把公钥返回给浏览器。
2、通过公钥加密数据
公钥加密过的密文拿公钥是解不开的。
3、私钥解密
服务器先通过私钥解密非对称加密的内容，拿到对称加密的密钥后，再用此密钥解密，最终得到xxoo。
现在我们利用非对称加密与对称加密结合的方式完成了数据的加密传输，再看看还有什么问题吧？
中间人攻击
中间人给了浏览器一个假的公钥，浏览器之后的所有数据都通过这个假的公钥进行加密传输，中间人再通过假的私钥解密，得到想要的数据后，还能再通过真的公钥加密，返回给服务器，这样一来一回，在神不知鬼不觉的情况下，浏览器和服务器之间的所有交互过程都暴露无遗。
有人可能会想，公钥为什么不能直接内置在浏览器中，非要通过服务器传过来呢？
你让所有浏览器内置所有服务器的公钥，觉得这样现实吗？（但是如果内置少数的公钥到也可以，之后会了解到CA机构的公钥就被提前内置到浏览器中了。）
第二版最终存在的问题
所以第二版存在的问题就是浏览器无法判断出公钥到底是由服务器生成的还是中间人生成的，理论上如果不是服务器生成的公钥都是不安全的。
第三版
怎么才能解决中间人伪造公钥的问题呢？
找个第三方来担保，服务器生成的公钥也不直接传输了，而是通过一个第三方来完成，第三方用自己的私钥对服务器的公钥进行加密，加密后把数据和第三方的公钥给到浏览器，浏览器用第三方公钥解出服务器的公钥，第三方公钥这个是不需要传递的，直接内置再浏览器端。
这一版有一个关键点就在于，第三方的公钥不需要通过网络传递给浏览器了，而是浏览器内置好的，这样中间就不能自己下发公钥给浏览器了，浏览器也不用再担心公钥是被伪造的了。
在我们当前的场景中，问题已经得到解决了，但是了解HTTPS的朋友应该知道还有个证书我们没有提到，那么这个证书到底有什么用呢？
想一种场景，中间人和你一样也在第三方机构得到了认证，那么中间人就可以把它得到的认证给你，由于都是第三方机构认证的，所以浏览器也可以正常解开，之后浏览器用中间人的公钥加密返回后，中间人就可以用自己的私钥解开得到想要的数据，并且还可以修改，因为他还有服务器的公钥（通过第三方公钥解密得到）。
第四版
现在我们要解决的就是如何防止第三方机构证书被替换，于是人们又想到了利用证书编号的方式，简单的说就是每个证书都有自己的唯一编号，并且是通过证书申请时附带的一些内容生成的，这个内容其中就包含了服务器的公钥，而最终就是通过hash的方式生成摘要信息，然后用第三方私钥对摘要进行加密，得到签名（就是证书编号）。
之后服务器把证书给到客户端，客户端通过第三方公钥解密后得到摘要内容，接着只需要用相同的算法的和内容生成摘要，然后与解密后的摘要进行比对，如果一致则表示是安全的，内容没有被修改过。
HTTPS实现过程
通过上面4个版本的内容，如果你大致了解了其中的演进过程，那么对于HTTPS就设计的方式就明白了。
HTTPS的通信过程
当浏览器请求的是https的连接时，首先会与服务器通过443端口执行几步验证过程。
- 1、浏览器请求服务器，同时告诉服务器自己支持的加密算法。
- 2、服务器匹配加密算法，匹配不上就断开连接，匹配上就把CA机构签发的证书发送给客户端（证书里面有签名算法和服务器公钥等信息）。
- 3、客户端验证证书，确认内容没有被篡改，然后，客户端再生成一个随机数，并用服务器公钥对这个随机数进行加密，然后把加密过的内容返回给服务器。
- 4、服务器用自己的私钥解密出随机数，之后的过程服务端和客户端就可以通过这个随机数对称加密进行数据传输了。
一句话总结
HTTPS整个过程中，用到了对称加密、非对称加密、摘要算法。
要想数据能够安全的在网络中进行传输，就必须对传输过程进行加密，而对称加密是效率比较好的（比非对称要高），但是在客户端与服务器确认密钥的过程中又必须通过非对称的方式来完成，而非对称的过程中又为了避免中间人伪造公私钥的问题，就找了一个CA机构来管理服务器生成的公钥，客户端则直接内置CA机构的公钥，而不进行网络传输，服务器的公钥则先进行hash摘要再用CA机构的私钥来加密，如此一来由于CA机构的私钥不会被泄露，所以这份hash摘要的数据就无法被篡改，最终完成了客户端与服务器安全的协商密钥的过程。