图解https演变以及各种加密解密过程一篇就够!(通俗易懂白话文)

1,867 阅读6分钟

图解https演变以及各种加密解密过程

HTTP->HTTPS原因

HHTP 访问
HHTP 访问
HTTPS 访问
HTTPS 访问

· 直接原因,如上图,使用http和https访问网站,最明显的差别就是 使用http进行访问的,浏览器直接标志为“不安全”网站,平时上网遇到这样的网站心里都会发毛,涉及到要支付钱的应该没人敢随意支付吧。

· 主要原因,浏览器也不是吃饱了没事做逼着大家改协议,主要是因为http是明文传输,那就相当于在网络环境里面裸奔啊,这是相当危险的,试想一下你要支付,银行卡密码什么的被别人劫持了,你可不就gg了。因此浏览器提醒的行为是对用户负责,还不改变的网站要么是没钱,要么是懒,要么这个网站是大爷客户爱上不上~

试想一下,http这么不安全,让你设计一个安全的,大家肯定第一反应就是数据加密嘛,那么怎么加密,来看看演变过程。

对称加密

谍战剧里面两个电台进行通信,发的电报都是些毫无规律的密码文,双方就靠着密码本来进行破译情报,密码本都靠着地下工作的间谍特工们进行传递,这个过程对应到网络传递消息就如下图:

WechatIMG74
WechatIMG74

采用单钥密码系统的加密方法,同一个密钥可以同时用作信息的加密和解密,这种加密方法称为对称加密,也称为单密钥加密。我这里只讲思路模型,具体加密解密算法过程不做解释。对应到网络应用大家可以看图参照,这是理想情况下,你好我好大家好,但是会出现两个问题:

· 第一步的密码本传递过程,如果特工里面出现了叛徒,叛徒得到了密码本照抄一份给他的组织,然后不动神色的继续传递密码本,那么接下来电台之间的密文传递在敌军组织眼里就跟明文没什么区别了,对应到网络中秘钥被黑客截取的过程。

· 密码本管理问题,电台每天要负责那么多的信息传递,为了安全又不可能所有地方发来的电报都用一把密码本破译,那样一旦密码本泄漏整个被一锅端了,因此对应到网络应用中,就是服务器端需要为每个用户单独生成一个秘钥并且管理,互联网中客户如此多,秘钥的管理代价就会很大,web服务场景肯定是行不通的。

常见的对称加密算法有DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES,感兴趣的可以自行百度。

非对称加密

玩归玩闹归闹,别拿安全开玩笑,有一说一,“野狼disco”是首不错的歌 WechatIMG12

过程说明: 非对称加密主要解决安全问题,客户端和服务器各自生成一对秘钥对,私钥自己保管,公钥暴露给对方,然后传输加密用对方给的公钥进行加密,对方有自己公钥的钥匙,以此达到解密数据的目的。各自保管一份私钥,不需要传输,就不会出现密码本泄漏的情况.

公钥与私钥是一对,如果用公钥对数据进行加密,只有用对应的私钥才能解密。因为加密和解密使用的是两个不同的密钥,所以这种算法叫作非对称加密算法。

这种方式,服务器只需要保存自己的秘钥就可以,管理秘钥问题得到解决,加密数据的目的也达到了,但是还会有问题:

· 最大的问题出现在了第一步公钥传递上面,我怎么信任你这把公钥呢?要知道这个地方还是在裸奔啊,如果出现了“中间dog”故意使坏,破解不了你但是要搞残你,将双方发送给对方的公钥篡改,冒充成随便一个公钥,那么双方用这个假公钥加密对方永远都解密不出来数据。

· 第二是加密和解密花费时间长、速度慢,只适合对少量数据进行加密。

https全过程 = 对称加密 + 非对称加密 + 数字证书

现实世界中,解决信任问题一般是“权威机构”或者权威人物背书,https就是这样,操作系统里面一开始就内置了各大数字认证权威机构(Certificate Authority,缩写为CA)的数字证书,作为系统根证书,macOS可以通过【钥匙串->系统根证书】查看,如图: WechatIMG79

· 服务器发送的证书里(chrome浏览器点击地址栏最左边,能看到证书的详细内容),数字证书主要包含了以下几个内容:

  1. 证书发布机构,即哪家CA
  2. 证书的有效期
  3. 证书的所有者,以及相关的证书的域名、公司名等等
  4. 公钥
  5. 证书签名

· 客户端校验证书的可信性,可以简单分为下面几步:

  1. 校验证书声明的CA在操作系统的根证书里面
  2. 校验证书在有效期内
  3. 校验证书的签名,这一步能够证明此证书确实是由CA机构颁发的。

· 其中校验证书签名是关键,证书签名是网站申请证书时,CA机构对一个hash值使用CA私钥对称加密后的字符串。 可以用表达式表达为:

sign = encrypt(hash("证书机构" + "证书有效期" + "证书所有者" + "公钥"))

· 校验签名的步骤:

  1. 客户端从系统根证书中取出对应CA的公钥,然后对签名解密获取到hash值。
  2. 客户端使用相同的方式拼接证书信息,使用相同算法得到hash值。
  3. 比较解密出来的hash值和客户端拼接的hash值是否相同,相同则通过。

这个过程其实完成了这么一件事情,客户端看了一眼证书提供的信息,然后通过CA公钥解密,证明了证书提供的信息是被拥有CA私钥的机构确认过的(证书的签名),便相信了证书提供的信息。

就像现实生活中的票据,相信票据中的信息,因为有一个独一无二的机构签章(虽然可以伪造,但是非对称机密的签章是不可伪造的)

· https的流程图如下: WechatIMG78

解决的问题:

  1. 非对称加密只用来传输密码本,实际数据传输用的对称加密,解决了非对称加密解密速度慢的问题

  2. CA机构数字证书验证公钥,解决公钥传输的信任问题

一步一步的,所有的问题都解决了,是不是特别的nice!!!

需要指出的是,HTTPS尽管可以保护数据在传输环节的安全,但HTTPS不是万能的,不能解决所有的安全问题。HTTPS无法解决跨站脚本XSS攻击、跨站资源冒用CSRF、跨站脚本跟踪XST、SQL注入攻击、病毒攻击,HTTPS依然无法解决。解决这些安全问题,需要在通信的终端采取措施来保证用户数据安全。