数字证书原理
一、HTTPS通信原理
以下内容实际非常接近HTTPS的通信原理。
- 客户端向服务器请求信息，
服务器将一段信息的明文以及用私钥加密过的密文以及加密算法返回给客户端。
客户端用公钥解密，判断是否同明文一致。如果一致，则证明--服务器拥有的私钥和自己的公钥是一对。
实际意味着服务器不是冒牌的。
服务器有一个，客户端有多个。服务器拥有私钥，公钥是公开的。
客户端需要知道服务器是否是冒牌的，只需知道服务器是否拥有私钥即可。
服务器为了证明自己拥有私钥，用私钥加密一段信息，并附上明文。客户端用公钥解密验证即可。
实际应用中，是由客户端发送一个随机字符串，服务器用私钥加密后返回给客户端，
客户端用数字证书中的公钥解密，看是否与随机字符串一致
- 以上场景中，服务器用私钥加密信息仅仅是为了证明拥有私钥
而不能真正的保证通信加密。
因为公钥是公开的，任何人都可以获得。
服务器用私钥加密后的内容，任何人都可以用公钥解密。
服务器发给客户端的信息相当于没有加密。
（然而，客户端可以用公钥加密信息，发给服务器。加密的信息仅能被持有私钥的服务器解密）
- 要解决双向加密（主要是服务器发给客户端的信息），需要引入对称加密
步骤1中，客户端已知道服务器身份可信，
可以告诉服务器"接下来使用对称加密来通信，这是xxx算法和密钥。"，这一段信息使用公钥加密的
因此只有服务器能解密。
每个客户端都可以有自己的密钥和算法。
服务器收到请求后，立即采用客户端指定的算法和密钥。接下来的通信便全部采用对称加密。
总结一下，RSA加密算法在这个通信过程中所起到的作用主要有两个：
因为私钥只有“服务器”拥有，因此“客户”可以通过判断对方是否有私钥来判断对方是否是“服务器”。
客户端通过RSA的掩护，安全的和服务器商量好一个对称加密算法和密钥来保证后面通信过程内容的安全。
上面的过程已经十分接近HTTPS的真实通信过程了，完全可以按照这个过程去理解HTTPS的工作原理。但是有些细节没有说到，有兴趣的人可以看下这部分的内容。可以跳过不看，无关紧要。
【问题1】
上面的通信过程中说到，在检查完证书后，“客户”发送一个随机的字符串给“服务器”去用私钥加密，以便判断对方是否真的持有私钥。
但是有一个问题，“黑客”也可以发送一个字符串给“服务器”去加密并且得到加密后的内容，这样对于“服务器”来说是不安全的，因为黑客可以发送一些简单的有规律的字符串给“服务器”加密，
从而寻找加密的规律，有可能威胁到私钥的安全。
所以说，“服务器”随随便便用私钥去加密一个来路不明的字符串并把结果发送给对方是不安全的。
〖解决方法〗
每次收到“客户”发来的要加密的的字符串时，“服务器”并不是真正的加密这个字符串本身，而是把这个字符串进行一个hash计算，
加密这个字符串的hash值(不加密原来的字符串)后发送给“客户”，
“客户”收到后解密这个hash值并自己计算字符串的hash值然后进行对比是否一致。
也就是说，“服务器”不直接加密收到的字符串，而是加密这个字符串的一个hash值，这样就避免了加密那些有规律的字符串，从而降低被破解的机率。
“客户”自己发送的字符串，因此它自己可以计算字符串的hash值，然后再把“服务器”发送过来的加密的hash值和自己计算的进行对比，同样也能确定对方是否是“服务器”。
【问题2】
在双方的通信过程中，“黑客”可以截获发送的加密了的内容，虽然他无法解密这个内容，但是他可以捣乱，例如把信息原封不动的发送多次，扰乱通信过程。
〖解决方法〗
可以给通信的内容加上一个序号或者一个随机的值，如果“客户”或者“服务器”接收到的信息中有之前出现过的序号或者随机值，
那么说明有人在通信过程中重发信息内容进行捣乱，双方会立刻停止通信。
有人可能会问，如果有人一直这么捣乱怎么办？那不是无法通信了？
答案是的确是这样的。。。。。。
例如有人控制了你连接互联网的路由器，他的确可以针对你。
但是一些重要的应用，例如军队或者政府的内部网络，它们都不使用我们平时使用的公网，因此一般人不会破坏到他们的通信。
【问题3】
在双方的通信过程中，“黑客”除了简单的重复发送截获的消息之外，还可以修改截获后的密文修改后再发送，
因为修改的是密文，虽然不能完全控制消息解密后的内容，但是仍然会破坏解密后的密文。
因此发送过程如果黑客对密文进行了修改，“客户”和“服务器”是无法判断密文是否被修改的。
虽然不一定能达到目的，但是“黑客”可以一直这样碰碰运气。
〖解决方法〗
在每次发送信息时，先对信息的内容进行一个hash计算得出一个hash值，
将信息的内容和这个hash值一起加密后发送。接收方在收到后进行解密得到明文的内容和hash值，
然后接收方再自己对收到信息内容做一次hash计算，与收到的hash值进行对比看是否匹配，
如果匹配就说明信息在传输过程中没有被修改过。如果不匹配说明中途有人故意对加密数据进行了修改，立刻中断通话过程后做其它处理。
二、数字证书--解决公钥的发布问题
还有一个问题，服务器如何发布公钥
任何人都可以生成公钥、私钥，无法确认公钥是谁的。黑客也可以生成公钥和私钥冒充服务器。
为了解决这个问题，需要数字证书。
数字证书可以保证证书里的公钥确实是这个证书的所有者的
三、数字证书的构成
Issuer:发布机构(是指创建证书的机构)
Valid from, Valid to: 有效期
Public key: 公钥
Subjet:证书的所有者。证书是发布给谁的，一般是某个人或者某个公司名称、机构的名称、公司网站的网址等。
四、通信模型
角色：
证书发布机构：CA
证书使用者：Subject
客户：browser/outlook等
-
CA
微软等公司会根据一些权威安全机构的评估选取一些信誉很好并且通过一定的安全认证的证书发布机构，
把这些证书发布机构的证书默认就安装在操作系统里面了，并且设置为操作系统信任的数字证书
这些证书里有CA自己的公钥 -
Subject
CA作为商业公司，收钱给Subject制作证书。比如给ABC公司生成证书
把Issuer,Public key,Subject,Valid from,Valid to等信息以明文的形式写到证书里面
并且附上数字签名，证明证书的完整性。
数字签名：
用一个指纹算法计算出这些数字证书内容的一个指纹
然后用CA自己的私钥和签名算法对指纹和指纹算法进行加密，也就是数字签名
同时，还会给ABC公司一个私钥
也就是说，CA是Subject的担保人
ABC公司花了钱，拿到CA给定做的证书和私钥；私钥自己保存，同事要验证证书是否是完整的，没有被篡改的。
验证方法是，用CA的公钥（在操作系统里有CA自己的证书，含CA自己的公钥）解密证书的数字签名得到指纹和指纹算法
然后自己用指纹算法计算证书，比较两个指纹即可。最终证明这个CA不是冒牌货骗钱的
（数字签名的意义在于，证明一段数据没有被修改过。
一段数据，用某种hash算法算出一个值，将这个值和hash算法加密后，就是数字签名。
加密时使用的是一个私钥，只有数据所有者知道。）
- app
客户和ABC通信过程的开始，ABC把证书发给app(IE/Outlook等等)
app读取证书的Issuer为SecureTrust CA
然后去操作系统受信任的发布机构中找SecureTrust CA的证书(如果找不到，说明是非法发布机构)
如果找到了，就从SecureTrust CA的证书中读取公钥，这个公钥用来解密ABC证书的数字签名。
解密后的数字签名是一个hash值和hash算法；用这个hash算法计算证书得到另一个hash值，
对比两个hash值，如果一致，说明ABC这个证书是完整的，没有被篡改过。
然后就可以放心使用ABC证书的公钥和ABC通信了
网友评论