zoukankan      html  css  js  c++  java
  • HTTPS原理学习笔记

    裸奔

      当前HTTP的局面,客户端和服务器进行通信交互信息都是明文的,这无疑是相当于“裸奔”,黑客轻而易举的可以从此交互中截获信息。


    对称加密

      那么既然是“裸奔”那就穿条裤子呗(对数据进行加密),此时有朋友就提出了一种手段叫做“对称加密”。简单来说下“对称加密”,首先需要准备一个密钥,在对数据进行加密和解密时都使用同一个密钥。

      那么使用该方式进行加密,则需要客户端和服务器之间进行协商确定好密钥,双方则对对数据进行加密和解密。就在双方进行通信协商密钥的过程中,依然会被黑客截取获得密钥从而对传递的数据进行解密。

     


     非对称加密

      基于“对称加密”存在的问题,有朋友又提出了一个加密方法叫“非对称加密”。非对称加密有一对密钥分别是:公钥和私钥。公钥加密的内容需要私钥解密,私钥加密的内容需要公钥解密,其特点和名称一样。

      私钥由服务器进行存储,不对外传送;公钥发送给客户端用于加密传送信息和解密接收信息。这样的加密方式改良了一点:因为私钥是不对外开放的,所以黑客没有渠道获取,则确保了客户端发送给服务器的数据是安全的。但是由于公钥在需要通过网络进行传输,黑客依然可以截获公钥,并将服务器发送给客户端的数据进行破解。


     对称加密+非对称加密

      根据以上的安全改良后发现,“对称加密”和“非对称加密”都存在着安全隐患。“对称加密”实际上在加密性能上是优于“非对称加密”的,但是“非对称加密”可以保证客户端传输给服务器的加密数据是无法被破解的。那么此时又有朋友提出了“完美”的方案,也就是将二者加密算法进行结合,实现一套加密交互机制。

      结合的使用目的:第一次由服务器向客户端发送“非对称加密”的公钥,然后客户端生成一个用于进行“对称加密”的对称密钥,并使用“非对称加密”的公钥对对称密钥进行加密。然后在由客户端将加密后的对称密钥发送给客户端,客户端存储对称密钥并告知客户端收到,双方自此针对后续通信交互的数据均使用“对称密钥”进行加密。如图:


     “中间人”问题(李代桃僵)

      看似“完美”的方案已经抵挡了黑客“凶猛的攻击”,但是对于这种情况黑客依然有方式来攻破你的安全防御。安全领域有一个形象的比喻叫“中间人”,黑客在于客户端和服务器之间交互的过程中充当了一个“中间人”的角色,也就是说黑客相对于客户端他可以伪装成服务器,相对于服务器他可以伪装成与之来往的客户端。那么对于这种情况,就目前对称加密+非对称加密的方式依然无计可施,“中间人”通过伪装可以截获客户端信息并伪造信息发送服务器,密钥依然会被泄露。如图:


    数字证书

      “中间人”问题其实本质伪装身份进行冒充,那我们是不是可以通过某种东西去作为唯一身份的标识。就好居民身份证一样,有非常权威的机构(公安机关)派发证明身份的凭据。这种情况的确就诞生了一个东西叫做数字证书,它不同于生活中的证件是看得见摸得着的实物,而是以数据形式展现的一种证书,所以叫数字证书,我们可以简单理解,它就是网络中服务器的身份证。如图:


     CA机构

      CA全称为:certificate authority,译为凭证管理中心。上面说了服务器在网络需要身份证(数字证书),那么有身份证就有发证的机构,CA就是网络中派发数字证书的机构,并且同我们派发身份证的公安局一样有着权威的合法性。PS:为服务器派发数字证书的CA往往都是需要收取一定费用的。

      在你准备了荷包或者找到了免费的渠道向CA机构获取证书时,往往需要进行申请并提交一些关键的信息,如:域名、企业名、公钥等。CA在审核无误后就会向你下发数字证书。


     数字签名

      有了权威的机构为服务器颁发了证明自己身份的数字证书,但是该证书依然需要传递给客户端,让客户端了解“自己”(服务器)是个有身份的人。那么在这个传书过程中,黑客依然有颁发截获,并且篡改证书的公钥进行伪装,导致后续的安全问题。此时为了防止伪造和篡改就引出了一个新的手动,叫做“数字签名”。

      数字签名怎么去理解呢,类比到生活中它就像你们公司门禁的打卡录入了你的指纹,那么此时不可能有第二个人可以去冒充你进入公司。它就像指纹一样具有绝对的唯一标识性,并且不可模仿修改。

      我们可以试想下这样的一个场景,你爸爸有天要出差,此时你们只能通过写信进行沟通,你爸爸在走之前预先将指纹的样子留下来,以后在写信时会在信上按上他的指纹,以免有人冒充身份给你写信。在接到信件时,你第一时间就是拿着信件上的指纹和你老婆走之前留下的指纹进行对比,如果纹路一样则表示信件时来自你爸爸写的,反之则有人冒充。

      那么基于上诉的特点在回到数字签名中,其实数字签名的方式就类似于上面比喻的场景。数字证书就像上面传递的信件重要无比,那么此时同样也需要一个指纹,那么这里的指纹指的就是根据Hash算法计算出的哈希值也叫摘要,CA在颁发证书之前会对“数字证书”进行哈希运算得出摘要,并且在通过CA的私钥对摘要进行加密得出的数据就是“数字签名”,最后将数字证书和摘要颁发给服务器。

      本质上可以总结为:数字签名就是数字证书的摘要并且同过CA私钥进行了加密,其主要目的是用于给客户端做比对工作,防止篡改。

      服务器向CA申请证书,CA对证书签名并颁发流程如图:


     客户端与CA机构

      上面讲述在数字签名主要是用来防篡改的,那么在其中CA在处理数字签名时有一个细节需要思考,就是CA最终会对数字证书的摘要使用CA自己的私钥进行加密。这个时候就有疑问了,加密后客户端收到签名后如何获取CA机构的公钥对签名进行解密?在解密后获取了摘要,客户端通过什么算法进行计算出摘要从而进行比对?

      针对上诉的问题解释:其实在操作系统或浏览器中以及内置了大量的CA机构信息以免通过传递泄露,客户端在接收服务器的证书时会在本地找到与之匹配的CA机构从而获取CA公钥和哈希算法。

      下图是查看浏览器中内置的CA机构信息:

     


     最终形态

      在使用“对称加密”+“非对称加密”的方案时加入数字证书和数字签名,到目前为止实际上就已经形成了SSL的安全机制,也就是HTTPS的原理,至少可以抵御大部分的安全问题,为什么不是全部?安全永远是相对的,HTTP+SSL至少在一定层面上避免了客户端和服务器在交互之间数据泄露、篡改的问题。

      下面用文字分析和描述SSL安全机制:

    1. 服务器首先会向CA机构申请证书,CA机构审核后会颁发“数字证书”和“数字签名”;

    2. 客户端发送请求获取服务器的“数字证书”和“数字签名”;

    3. 客户端根据“数字证书”的信息在操作系统或者浏览器找到内置CA机构的信息,其中主要的就是CA机构的公钥和摘要的算法;

    4. 客户端使用CA机构的公钥和对“数字签名”解密获取了摘要信息;

    5. 客户端使用对于CA机构的哈希算法将客户端发送的“数字证书”进行哈希运算得到摘要;

    6. 客户端将自己算的摘要和客户端发来进行解密得到的摘要进行比对,如果比对一致则证明没有被篡改,反正篡改。

    7. 客户端生成用于对传输数据进行加密的“对称密钥”;

    8. 客户端从数字证书中取出服务器的公钥将“对称密钥”进行加密并发送给服务器;

    9. 服务器接收到客户端发送的加密信息,并使私钥对加密数据解密获取到“对称密钥”,此时双发已经完成密钥协商工作;

    10. 在后续的通信中客户端和服务器使用“对称密钥”对交互数据进行加密和解密。

      整个安全机制中的关键在于CA机构的私钥由绝对的安全性,黑客无法改变摘要。即使黑客拿到传输的信息,如拿到证书和签名进行了改动,此时客户端通过摘要对比就可以发现是否有篡改。即使黑客截获了客户端的数据没有私钥,是无法解密“对称密钥”的,故只能知道加密后的数据无从下手。

      另外,在整个安全机制中会出现两个公钥,我们需要注意区分和理解。

      其中一个是CA的公钥这是属于机构的,一般会内置在操作系统或浏览器中,用于对数字签名解密获取摘要;

    另一个是服务器的公钥,该公钥会在申请数字证书时递交给CA,CA也会向其包含在数字证书中,主要用于客户端和服务器之间“协商对称密钥”。


     总结

    HTTPS其实就是是一个安全版的HTTP,在HTTP基础上加入了SSL(安全套接字协议)或TLS来保证数据传输的安全。SSL的安全机制和原理就是使用了:对称加密+非对称加密+CA(数字证书、数字签名)来实现的。

     参考文献:https://www.17coding.info/article/22


  • 相关阅读:
    apache安全—用户访问控制
    hdu 3232 Crossing Rivers 过河(数学期望)
    HDU 5418 Victor and World (可重复走的TSP问题,状压dp)
    UVA 11020 Efficient Solutions (BST,Splay树)
    UVA 11922 Permutation Transformer (Splay树)
    HYSBZ 1208 宠物收养所 (Splay树)
    HYSBZ 1503 郁闷的出纳员 (Splay树)
    HDU 5416 CRB and Tree (技巧)
    HDU 5414 CRB and String (字符串,模拟)
    HDU 5410 CRB and His Birthday (01背包,完全背包,混合)
  • 原文地址:https://www.cnblogs.com/green-jcx/p/13646988.html
Copyright © 2011-2022 走看看