从http看https的诞生缘由
本文重点不在于http，所有对http的原理和过程不做过多仔细的说明。我们熟悉的http的大致请求过程如下：
- 客户端连接到Web服务器
- 发送HTTP请求
- 服务器接受请求并返回HTTP响应
由于HTTP协议采用明文传输，通过抓包很轻松的获取到HTTP所传输的数据。因此，采用HTTP协议是不安全的。这才催生了HTTPS的诞生。HTTPS相对HTTP提供了更安全的数据传输保障。主要体现在三个方面：
-
内容加密。客户端到服务器的内容都是以加密形式传输，中间者无法直接查看明文内容。
-
身份认证。通过校验保证客户端访问的是自己的服务器。
-
数据完整性。防止内容被第三方冒充或者篡改。
HTTPS的握手过程
-
客户端发送开始请求，包含一个随机数 random1。
-
服务端回复客户端请求，包含一个随机数 random2，携带了证书公钥 P。
-
客户端接收到 random2 之后就能够生成 premaster_secrect （对称加密的密钥）以及 master_secrect（用premaster_secret加密后的数据）。
-
客户端使用证书公钥 P 将 premaster_secrect 加密后发送给服务器 (用公钥P对premaster_secret加密)。
-
服务端使用私钥解密得到 premaster_secrect。又由于服务端之前就收到了随机数 1，所以服务端根据相同的生成算法，在相同的输入参数下，求出了相同的 master secrect。
上面过程需要结合以下内容加以理解。
加密方式
在分析HTTPS原理之前我们得先了解一下两种加密方式： 对称加密和非对称加密。
对称加密
所谓的对称加密算法就是指客户端和服务端的密钥是同一个。比如客户端A使用密钥S对请求数据进行加密，服务端收到请求后同样使用密钥S解密。这就是对称加密算法，其中密钥S同时扮演加密和解密的角色。具体细节，本文以后添加。
对称加密算法本事的破解难度很大，如果说这个密钥S不公开给其他第三方，一般是无法破解的，也就能解决我们请求过程中加密的问题。但是实际情况中，服务器和客户端是一对多的关系，也就是说需要针对不同客户端使用不同的加密密钥：
由此引出两个问题
1.服务器端怎么告诉客户端该使用哪种对称加密算法？
通过协商，服务端告诉具体的客户端它该使用哪种加密算法
要达到服务器针对每个客户端使用不同的对称加密算法，同时，我们也不能让第三者知道这个对称加密算法是什么，怎么办？
使用随机数，就是使用随机数来生成对称加密算法。这样就可以做到服务器和客户端每次交互都是新的加密算法、只有在交互的那一该才确定加密算法。
也就是为什么HTTPS协议握手阶段会有这么多的随机数的原因了。
2.如果协商的过程被第三方截取怎么办?
那就再对协商过程进行加密好了呗。那协商过程的加密的过程还是没有加密啊。鸡生蛋，蛋生鸡的问题出来了。
对称加密的缺点就在于对称加密需要在网络上传输密钥和密文，一旦被黑客截取很容就能被破解。
非对称加密
在了解了对称加密算法，对非对称加密应该有个大概的概念了。非对称加密 即加密和解密使用不同的密钥，分别称为公钥和私钥。用公钥对数据进行加密，但必须要用私钥才能解密。在网络上只需要传送公钥，私钥保存在服务端用于解密公钥加密后的密文。
同样的引出一个问题
客户端如何获得服务端的公钥呢？
如果客户端在发送数据之前没有得到公钥，还怎么进行加密呢？所有，客户端在一开始就需要先持有公钥。那客户端获取服务端公钥的过程怎么保证是安全的呢？这里引用一张网上的图来加以理解：
显然让客户端保存所有网站的公钥是不现实的。为了解决这个问题，引入了第三方机构的概念，也就是指数字证书签发机构（CA）。第三方机构使用它的私钥对我们的公钥进行加密后，再传给客户端。客户端再使用第三方机构的公钥进行解密。如果能解密，就说明这个公钥没有被中间人调包。因为如果中间人使用自己的私钥加密后的东西传给客户端，客户端是无法使用第三方的公钥进行解密的。
数字证书
第三方机构不可能只给你一家公司制作证书，它也可能会给中间人这样有坏心思的公司发放证书。这样的，中间人就有机会对你的证书进行调包，客户端在这种情况下是无法分辨出是接收的是你的证书，还是中间人的。因为不论中间人，还是你的证书，都能使用第三方机构的公钥进行解密。
第三方机构向多家公司颁发证书的情况：
客户端能解密同一家第三机构颁发的所有证书：
最终导致其它持有同一家第三方机构证书的中间人可以进行调包：
证书分类：
- CA机构颁发的证书，受信任的证书
- 非CA机构即是不受信任的机构颁发的证书，理所当然这样的证书是不受信任的。
- 自签名证书，就是自己给自己颁发的证书。当然自签名证书也是不受信任的。
数字签名，解决同一机构颁发的不同证书被篡改问题
要解决这个问题，我们首先要想清楚一个问题，辨别同一机构下不同证书的这个职责，我们应该放在哪？
只能放到客户端了。意思是，客户端在拿到证书后，自己就有能力分辨证书是否被篡改了。如何才能有这个能力呢？
我们从现实中找灵感。比如你是HR，你手上拿到候选人的学历证书，证书上写了持证人，颁发机构，颁发时间等等，同时证书上，还写有一个最重要的：证书编号！我们怎么鉴别这张证书是的真伪呢？只要拿着这个证书编号上相关机构去查，如果证书上的持证人与现实的这个候选人一致，同时证书编号也能对应上，那么就说明这个证书是真实的。
我们的客户端能不能采用这个机制呢？像这样：
可是，这个“第三方机构”到底是在哪呢？是一个远端服务？不可能吧？如果是个远端服务，整个交互都会慢了。所以，这个第三方机构的验证功能只能放在客户端的本地了。
客户端本地怎么验证证书呢？
客户端本地怎么验证证书呢？答案是证书本身就已经告诉客户端怎么验证证书的真伪。
也就是证书上写着如何根据证书的内容生成证书编号。客户端拿到证书后根据证书上的方法自己生成一个证书编号，如果生成的证书编号与证书上的证书编号相同，那么说明这个证书是真实的。
同时，为避免证书编号本身又被调包，所以使用第三方的私钥进行加密。
这地方有些抽象，我们来个图帮助理解：
证书的制作如图所示。证书中的“编号生成方法MD5”就是告诉客户端：你使用MD5对证书的内容求值就可以得到一个证书编号。
当客户端拿到证书后，开始对证书中的内容进行验证，如果客户端计算出来的证书编号与证书中的证书编号相同，则验证通过：
但是第三方机构的公钥怎么跑到了客户端的机器中呢？
其实呢，现实中，浏览器和操作系统都会维护一个权威的第三方机构列表（包括它们的公钥）。因为客户端接收到的证书中会写有颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥。比如Android系统中已经内置了所有CA机构的根证书，也就是只要是CA机构颁发的证书，Android是直接信任的。
总结
HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。同时因为https请求过程中需要多次加密和解密，所有其性能比http差。
网友评论