HTTPS : HTTPS原理详解

目录：

http有什么弊端

http是基于tcp的应用层协议。tcp本身是没有任何安全策略的，所以http传输的数据是不安全的。

https协议简介

https在http协议技术上加入SSL层来实现安全，大致可以概括为通过非对称加密来约定对称加密秘钥。且https默认端口443

什么是对称加密、非对称加密

对称加密

采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密。

非对称加密

对称加密算法在加密和解密时使用的是同一个秘钥；而非对称加密算法需要两个密钥来进行加密和解密，这两个秘钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。

公钥加密的数据只能有与之对应的私钥解密
私钥加密的数据可以被任何与之对应的公钥解密

HTTPS原理

问题一：解决数据加密问题

通过http发送的数据都是明文，如图：

这样传输数据hello很有可能被别人掉包，我们第一时间想到的就是加密，A发送消息给B，那么提前约定好一个对称秘钥S，如图：

但实际情况是我们的网站要面向很多个用户，如图：

现在问题来了，这么多个客户端，保不齐哪个客户端把秘钥S泄露了，这时整个网站都是不安全的了。

于是我们想了另外一种办法，每个客户端都是用不同的加密算法，如图：

但这只是我们理想的情况，实际情况是客户端怎么知道我用那种加密算法，分别进行协商的话如图：

于是我们引入第二个问题：如何保证协商过程是安全的？

问题二：如何保证协商过程是安全的

我们这里通过非对称加密来实现，非对称加密的公钥每个客户端都持有，私钥仅服务器持有。如图：

此时客户端生成随机数通过公钥加密传给服务器，服务器通过私钥解密得到随机数，至此对称加密的秘钥就协商好了。由此可见https通过非对称加密实现了对称加密算法的协商。而且每次https请求都会生成这样的随机数。

但是我们还要解决两个问题：
1.客户端公钥哪里来的
2.客户端如何确认公钥是真的

问题三：客户端公钥哪里来的&客户端如何确认公钥是真的

实际情况是服务器会将公钥发送给客户端，但是又引入了一个新的问题，如果服务器能把公钥安全的发送给客户端，服务器也就能把对称秘钥发送给客户端，那[问题二]也就不存在。所以我们在发送公钥的过程依然面临[问题二]类似问题，如图：

有些同学可能会想到我再用一个私钥(下称私钥2)去加密我要发送的公钥，客户端用公钥2(与私钥2对应)去解密得到我想要的公钥，但是公钥2又是从哪来的，如此循环下去就成了鸡生蛋蛋生鸡的问题。

于是我们想到一种方法，上述所谓的公钥2私钥2我们都用第三方的(像是两小孩大家找老师评理一样的道理)，第三方公钥存在客户端，第三方私钥存在第三方(这个东西我们永远获取不到，是第三方给别人或者给自己颁发证书用的)。而且这个第三方一定是公认的。如下经过第三方的私钥加密过的服务器公钥我们给他起个名字：”数字证书” 这个数字证书并是实际中的数字证书，这里仅为了说明https假设出来的 如下图：

如果客户端能正确的通过第三方公钥解密出服务端发来的公钥证明公钥是真的。如果客户端无法正确解密，证明这个数字证书在传输途中被掉包了

如上我们解决了[问题3]，但是有面临一个新的问题，数字证书我们可以到申请，别人也可以申请，那黑客也可以申请，而且黑客的证书也是合法的。这是就出现了如下问题

第三方机构颁发给我和黑客各自一份证书

客户端认为我和黑客的证书都是合法的

黑客劫持了我的请求，替换成他的证书搞我 - -#

于是我们需要解决问题四：同一机构颁发的不同证书被混用

问题四：同一机构颁发的不同证书被混用

要解决这个问题，必须指定证书隶属于那个网站，一份证书只能属于一个网站使用，当然包含二级域名。
证书完整信息包含以下几个部分(大家可以百度具体查看每个部分的作用)：

• Issuer (证书的发布机构)
• Valid from , Valid to (证书的有效期)
• Public key (我们要发送给客户端的公钥)
• Subject (证书所有者)
• Signature algorithm (签名所使用的算法)
• Thumbprint, Thumbprint algorithm (指纹以及指纹算法)

这其中证书的所有者很关键，如果在用户访问的是a.com 但是拿回来的证书所有者是b.com，那么浏览器是不信任这个证书。

好，[问题四]被解决了，我们有面临一个新的问题，这个证书所有者被改了怎么办，黑客把自己的证书所有者改成了你的网站域名，然后把证书发给了用户，又让这些可恶的人算计了。

问题五：如何防止证书不被篡改

下意识想到的可能是我们可能想到的是每次让客户端到第三方那里认证下证书的真伪，但是这样效率是在太低了。于是我们引入新的概念：数字签名

数字签名步骤：
1.根据证书信息(主要是用户名和该用户的公钥)通过哈希(图示MD5，但是实际非MD5)生成信息摘要(通俗理解为证书编号)
2.用第三方私钥对信息摘要加密生成数字签名

数字签名+上边提到数字证书的内容 = 完整的真实的数字证书

客户端收到数字证书的验证工作如下：
1.通过本地的第三方公钥对摘要信息解密
2.通过数字证书中的Signature algorithm (签名所使用的算法)对证书进行hash计算。
3.对比1和2的结果是否一致。

这里的第三方机构其实就是CA，通过以上操作，我们已经完成了非对称加密实现对称加密秘钥协商的所有动作。

最后一个问题，客户端的第三方公钥从哪里获取

问题六：客户端的第三方公钥从哪里获取

实际第三方公钥存在于颁发用户证书的中级证书里，中级证书和用户证书没有任何区别，那么中级证书的真伪如何判断，最终就是通过根证书。

可信渠道认证根证书，根证书认证中级证书，中级证书认证中级证书……，中级证书认证个人证书，个人证书认证用户拿到的公钥。如图：

这里的根证书是操作系统安装好以后就存在的。

鸣谢

写这篇博客触发点是今天面试别人的时候问到了这个问题，但是突然想不起细节了，所以今天写一下，主要是做个笔记。感谢以下两位的博客：
呦呦鹿鸣，食野之芩 ： http://blog.csdn.net/zbuger/article/details/51595229
翟志军 ：https://mp.weixin.qq.com/s/8Y2BX80Ka9B8McmZOqMVQg （原谅我比较懒，大部分图都是从这里摘的）

写在最后

其实我在理解https时有一个疑惑：
https通过CA公钥解密摘要信息，然后和证书信息做hash后的值做了对比，从而判断证书的真伪。这里为什么不能直接省掉做hash的过程，直接对整个证书内容进行CA私钥加密，如果客户端用根证书中的公钥能解密则证书是真的，当然这里的能解密不是严格意义上的能解密，而是解密后的格式和正常格式一致，就认为能解密。而不能解密则认为证书是假的。
我自己的猜测：
1.数字证书需要找到这个证书的颁发者来验证证书真假，意味着颁发者一定是不能加密传输的，所以造成证书一部分加密，一部分非加密。很不整齐，虽然现在也是一部分加密，一部分非加密，但是加密部分仅是摘要信息，除摘要信息外部分是没有加密的。
2.如果整个证书加密，那客户端解密时根本不确定这个证书是真还是假，相比较对hash解密而言，对整个证书解密效率肯定会差很多。
3.如果整个证书加密，意味者证书发送到客户端，客户端完全不发看到证书的任何信息，除证书的颁发者。对维护、问题定位造成很大困难。
4.如果证书恰巧被篡改，而且篡改完的用户名和用户公钥随便通过一个私钥加密后传给客户端，客户端此时拿着本地CA公钥解密恰好解密出一个和正常公钥用户信息格式一样的数据，会骗过所有认证。客户端误认为这个证书是真的。虽然这种情况发生后，客户端拿到的公钥一定是不正确的（因为被篡改的证书不是通过CA私钥加密的），但客户端依然会用这样的一个错误公钥加密信息传递数据。这样的数据即无法被服务器解析也无法被篡改者解析，直接造成了https不可用。

以下10-26补充
用对hash的原因今天上午查了很多资料,最终原因是:

但是我还是认为我上边的猜测一部分也是合理的哈,就不删除上边的猜测了.

hash的不可逆特性作用

hash是不可逆的,数字签名基于这个特点通过判断hash是否发生变化来判断整个数字证书是否发生篡改,但是如果hash出现碰撞,意味着别人可以通过碰撞hash篡改数字证书内容.篡改的内容如果恰好是服务器发给客户端的公钥,整个数字证书就都失效了.

参考资料

360doc vavava : http://www.360doc.com/content/10/1116/18/61151_69907721.shtml
sohu: http://www.sohu.com/a/168303317_99901444
沃通论坛 : https://www.wosign.com/basic/codesign_basic.htm