HTTPS加密原理

Header

HTTP、HTTPS在我们日常开发中是经常会接触到的。

我们也都知道,一般 Android 应用开发,在请求 API 网络接口的时候,很多使用的都是 HTTP 协议;使用浏览器打开网页,也是利用 HTTP 协议。看来 HTTP 真是使用广泛啊,但是,HTTP 是不安全的。利用网络抓包工具就可以知道传输中的内容,一览无余。比如我经常会使用 Fiddler 来抓包,搜集一些有趣的 API 接口。

那么问题来了,如何保证 HTTP 的安全性呢?基本上所有的人都会脱口而出:使用 HTTPS 协议。99.9% 的人都知道 HTTPS 会将传输的内容进行加密,但是接着问具体加密的过程和步骤,很多人就哑口无言了。

为了防止出现这种尴尬的局面,所以今天你就要好好看看这篇的内容了。以后就可以装个逼,哈哈!

Body

加密类型

先科普一下,加密算法的类型基本上分为了两种:

  • 对称加密,比较有代表性的就是 AES 加密算法;
  • 非对称加密,经常使用到的 RSA 加密算法就是非对称加密的;

对称加密的意思就是说双方都有一个共同的密钥,然后通过这个密钥完成加密和解密,这种加密方式速度快,但是安全性不如非对称加密好。

举个例子,现在学霸小明这里有一道数学题的答案:123 。他想把答案传给自己一直暗恋的小红。所以他们双方在考试开考前,约定了一把密钥:456 。那么小明就把答案内容经过密钥加密,即 123 + 456 = 579 ,将 579 写在小纸条上扔给小红。如果此时别人捡到了小纸条,不知道他们是加密传输的,看到上面的 579 ,会误以为答案就是 579 ;如果是小红捡到了,她拿出密钥解密,579 - 456 = 123 ,得到了正确的答案。

这就是所谓的对称加密,加解密效率高,速度快,但是双方任何一方不小心泄露了密钥,那么任何人都可以知道传输内容了。

讲完了对称加密,我们看看啥是非对称加密。

非对称加密就是有两把密钥,公钥和私钥。私钥自己藏着,不告诉任何人;而公钥可以公开给别人。

经过了上次作弊后,小红发现了对称加密如果密钥泄露是一件可怕的事情。所以她和小明决定使用非对称加密。小红生成了一对公钥和私钥,然后把公钥公开,小明就得到了公钥。小明拿到公钥后,把答案经过公钥加密,然后传输给小红,小红再利用自己的私钥进行解密,得到答案结果。如果在这个过程中,其他人得到传输的内容,而他们只有小红公钥,是没有办法进行解密的,所以也就得不到答案,只有小红一个人可以解密。

因此,相比较对称加密而言,非对称加密安全性更高,但是加解密耗费的时间更长,速度慢。

对称加密和非对称加密的具体应用我还是深有体会的,因为所在的公司是做金融支付方面的,所以加解密基本上算是天天见了。

HTTPS

说完加密类型后,我们再来看看 HTTPS 。

我们先来看一个公式:

HTTPS = HTTP + SSL

从这个公式中可以看出,HTTPS 和 HTTP 就差在了 SSL 上。所以我们可以猜到,HTTPS 的加密就是在 SSL 中完成的。

所以我们的目的就是要搞懂在 SSL 中究竟干了什么见不得人的事了?

这就要从 CA 证书讲起了。CA 证书其实就是数字证书,是由 CA 机构颁发的。至于 CA 机构的权威性,那么是毋庸置疑的,所有人都是信任它的。CA 证书内一般会包含以下内容:

  • 证书的颁发机构、版本
  • 证书的使用者
  • 证书的公钥
  • 证书的有效时间
  • 证书的数字签名 Hash 值和签名 Hash 算法

正好我们把客户端如何校验 CA 证书的步骤说下吧。

CA 证书中的 Hash 值,其实是用证书的私钥进行加密后的值(证书的私钥不在 CA 证书中)。然后客户端得到证书后,利用证书中的公钥去解密该 Hash 值,得到 Hash-a ;然后再利用证书内的签名 Hash 算法去生成一个 Hash-b 。最后比较 Hash-a 和 Hash-b 这两个的值。如果相等,那么证明了该证书是对的,服务端是可以被信任的;如果不相等,那么就说明该证书是错误的,可能被篡改了,浏览器会给出相关提示,无法建立起 HTTPS 连接。除此之外,还会校验 CA 证书的有效时间和域名匹配等。

接下来我们就来详细讲一下 HTTPS 中的 SSL 握手建立过程,假设现在有客户端 A 和服务器 B :

  1. 首先,客户端 A 访问服务器 B ,比如我们用浏览器打开一个网页 https://www.baidu.com ,这时,浏览器就是客户端 A ,百度的服务器就是服务器 B 了。这时候客户端 A 会生成一个随机数1,把随机数1 、自己支持的 SSL 版本号以及加密算法等这些信息告诉服务器 B 。
  2. 服务器 B 知道这些信息后,然后确认一下双方的加密算法,然后服务端也生成一个随机数 B ,并将随机数 B 和 CA 颁发给自己的证书一同返回给客户端 A 。
  3. 客户端 A 得到 CA 证书后,会去校验该 CA 证书的有效性,校验方法在上面已经说过了。校验通过后,客户端生成一个随机数3 ,然后用证书中的公钥加密随机数3 并传输给服务端 B 。
  4. 服务端 B 得到加密后的随机数3,然后利用私钥进行解密,得到真正的随机数3。
  5. 最后,客户端 A 和服务端 B 都有随机数1、随机数2、随机数3,然后双方利用这三个随机数生成一个对话密钥。之后传输内容就是利用对话密钥来进行加解密了。这时就是利用了对称加密,一般用的都是 AES 算法。
  6. 客户端 A 通知服务端 B ,指明后面的通讯用对话密钥来完成,同时通知服务器 B 客户端 A 的握手过程结束。
  7. 服务端 B 通知客户端 A,指明后面的通讯用对话密钥来完成,同时通知客户端 A 服务器 B 的握手过程结束。
  8. SSL 的握手部分结束,SSL 安全通道的数据通讯开始,客户端 A 和服务器 B 开始使用相同的对话密钥进行数据通讯。

到此,SSL 握手过程就讲完了。可能上面的流程太过于复杂,我们简单地来讲:

  1. 客户端和服务端建立 SSL 握手,客户端通过 CA 证书来确认服务端的身份;
  2. 互相传递三个随机数,之后通过这随机数来生成一个密钥;
  3. 互相确认密钥,然后握手结束;
  4. 数据通讯开始,都使用同一个对话密钥来加解密;

我们可以发现,在 HTTPS 加密原理的过程中把对称加密和非对称加密都利用了起来。即利用了非对称加密安全性高的特点,又利用了对称加密速度快,效率高的好处。真的是设计得非常精妙,令人赞不绝口。

Footer

好了,HTTPS 加密原理到这就讲的差不多了,不知道电脑前的你有没有看懂呢?

如果有哪里不明白的地方,可以在底下留言交流。

bye ~~

References

俞其荣 wechat
欢迎订阅我的微信公众号来获取我的动态!
坚持原创技术分享,您的支持将鼓励我继续创作!