我们也都知道，一般 Android 应用开发，在请求 API 网络接口的时候，很多使用的都是 HTTP 协议；使用浏览器打开网页，也是利用 HTTP 协议。看来 HTTP 真是使用广泛啊，但是，HTTP 是不安全的。利用网络抓包工具就可以知道传输中的内容，一览无余。比如我经常会使用 Fiddler 来抓包，搜集一些有趣的 API 接口。
那么问题来了，如何保证 HTTP 的安全性呢？基本上所有的人都会脱口而出：使用 HTTPS 协议。99.9% 的人都知道 HTTPS 会将传输的内容进行加密，但是接着问具体加密的过程和步骤，很多人就哑口无言了。
一、加密类型
先科普一下，加密算法的类型基本上分为了两种：
- 对称加密是指加密和解密使用相同的密钥
- 典型的有DES、RC5、IDEA（分组加密），RC4（序列加密）；
- 非对称加密又称为公钥加密算法，是指加密和解密使用不同的密钥（公开的公钥用于加密，私有的私钥用于解密
- 比如A发送，B接收，A想确保消息只有B看到，需要B生成一对公私钥，并拿到B的公钥。于是A用这个公钥加密消息，B收到密文后用自己的与之匹配的私钥解密即可。
- 反过来也可以用私钥加密公钥解密。也就是说对于给定的公钥有且只有与之匹配的私钥可以解密，对于给定的私钥，有且只有与之匹配的公钥可以解密
- 典型的算法有RSA，DSA，DH；
- 散列算法：散列变换是指把文件内容通过某种公开的算法，变成固定长度的值（散列值），这个过程可以使用密钥也可以不使用。
- 这种散列变换是不可逆的，也就是说不能从散列值变成原文。因此，散列变换通常用于验证原文是否被篡改。
- 典型的算法有：MD5，SHA，Base64，CRC等。
对称加密的意思就是说双方都有一个共同的密钥，然后通过这个密钥完成加密和解密，这种加密方式速度快，但是安全性不如非对称加密好。
举个例子，现在学霸小明这里有一道数学题的答案：123 。他想把答案传给自己一直暗恋的小红。所以他们双方在考试开考前，约定了一把密钥：456 。那么小明就把答案内容经过密钥加密，即 123 + 456 = 579 ，将 579 写在小纸条上扔给小红。如果此时别人捡到了小纸条，不知道他们是加密传输的，看到上面的 579 ，会误以为答案就是 579 ；如果是小红捡到了，她拿出密钥解密，579 - 456 = 123 ，得到了正确的答案。
这就是所谓的对称加密，加解密效率高，速度快，但是双方任何一方不小心泄露了密钥，那么任何人都可以知道传输内容了。
讲完了对称加密，我们看看啥是非对称加密。
非对称加密就是有两把密钥，公钥和私钥。私钥自己藏着，不告诉任何人；而公钥可以公开给别人。
经过了上次作弊后，小红发现了对称加密如果密钥泄露是一件可怕的事情。所以她和小明决定使用非对称加密。小红生成了一对公钥和私钥，然后把公钥公开，小明就得到了公钥。小明拿到公钥后，把答案经过公钥加密，然后传输给小红，小红再利用自己的私钥进行解密，得到答案结果。如果在这个过程中，其他人得到传输的内容，而他们只有小红公钥，是没有办法进行解密的，所以也就得不到答案，只有小红一个人可以解密。
因此，相比较对称加密而言，非对称加密安全性更高，但是加解密耗费的时间更长，速度慢。
对称加密和非对称加密的具体应用我还是深有体会的，因为所在的公司是做金融支付方面的，所以加解密基本上算是天天见了。
二、HTTPS
我们先来看一个公式：
HTTPS = HTTP + SSL
从这个公式中可以看出，HTTPS 和 HTTP 就差在了 SSL 上。所以我们可以猜到，HTTPS 的加密就是在 SSL 中完成的。
2.1 SSL 与 CA 证书
所以我们的目的就是要搞懂在 SSL 中究竟干了什么见不得人的事了？
这就要从 CA 证书讲起了。CA 证书其实就是数字证书，是由 CA 机构颁发的。至于 CA 机构的权威性，那么是毋庸置疑的，所有人都是信任它的。CA 证书内一般会包含以下内容：
- 证书的颁发机构、版本
- 证书的使用者
- 证书的公钥
- 证书的有效时间
- 证书的数字签名 Hash 值和签名 Hash 算法
- …
正好我们把客户端如何校验 CA 证书的步骤说下吧。
- CA 证书中的 Hash 值，其实是用证书的私钥进行加密后的值（证书的私钥不在 CA 证书中）。
- 然后客户端得到证书后，利用证书中的公钥去解密该 Hash 值，得到 Hash-a ；
- 然后再利用证书内的签名 Hash 算法去生成一个 Hash-b 。
- 最后比较 Hash-a 和 Hash-b 这两个的值。
- 如果相等，那么证明了该证书是对的，服务端是可以被信任的；
- 如果不相等，那么就说明该证书是错误的，可能被篡改了，浏览器会给出相关提示，无法建立起 HTTPS 连接。
- 除此之外，还会校验 CA 证书的有效时间和域名匹配等。除此之外，还会校验 CA 证书的有效时间和域名匹配等。
2.2 HTTPS 中的 SSL 握手建立过程
在 HTTPS 加密原理的过程中把对称加密和非对称加密都利用了起来，SSL协议是用非对称密码算法来协商密钥，并使用密钥加密明文并传输的
假设现在有客户端 A 和服务器 B ：
- 首先，客户端 A 访问服务器 B ，比如我们用浏览器打开一个网页 https://www.baidu.com ，这时，浏览器就是客户端 A ，百度的服务器就是服务器 B 了。
- 这时候客户端 A 会生成一个随机数1，把随机数1 、自己支持的 SSL 版本号以及支持的加密算法(譬如说，对称加密算法有DES,RC5,密钥交换算法有RSA和DH，摘要算法有MD5和SHA)等这些信息告诉服务器 B。
- 服务器 B 知道这些信息后，然后确认一下双方的加密算法，”用DES－RSA－SHA这对组合好了“，然后服务端也生成一个随机数 B ，并将随机数 B 和 CA 颁发给自己的证书一同返回给客户端 A。
- 客户端 A 得到 CA 证书后，会去校验该 CA 证书的有效性，校验方法在上面已经说过了。校验通过后，客户端生成一个随机数3 ，然后用证书中的公钥加密随机数3 并传输给服务端 B 。
- 服务端 B 得到加密后的随机数3，然后利用私钥进行解密，得到真正的随机数3。
- 最后，客户端 A 和服务端 B 都有随机数1、随机数2、随机数3，然后双方利用这三个随机数生成一个对话密钥。之后传输内容就是利用对话密钥来进行加解密了。这时就是利用了对称加密，一般用的都是 AES 算法，也就是上文约定好的协议。
- 客户端 A 通知服务端 B ，指明后面的通讯用对话密钥来完成，同时通知服务器 B 客户端 A 的握手过程结束。
- 服务端 B 通知客户端 A，指明后面的通讯用对话密钥来完成，同时通知客户端 A 服务器 B 的握手过程结束。
- SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户端 A 和服务器 B 开始使用相同的对话密钥进行数据通讯。
到此，SSL 握手过程就讲完了。可能上面的流程太过于复杂，我们简单地来讲：
- 客户端和服务端建立 SSL 握手，客户端通过 CA 证书来确认服务端的身份；
- 互相传递三个随机数，之后通过这随机数来生成一个密钥；
- 互相确认密钥，然后握手结束；
- 数据通讯开始，都使用同一个对话密钥来加解密；
三、 Android借鉴
如果没用HTTPS的话，为了确保传输安全，还需对传输的数据进行加密，这里我推荐用AES+RSA进行加密：
- 先由服务器创建RSA密钥对，RSA公钥保存在安卓的so文件里面，服务器保存RSA私钥。
- 安卓创建AES密钥（这个密钥也是在so文件里面），并用该AES密钥加密待传送的明文数据
- 安卓发送信息时，用存储的RSA公钥加密AES密钥，最后把用RSA公钥加密后的AES密钥同密文一起通过Internet传输发送到服务器。
- 当服务器收到这个被加密的AES密钥和密文后，首先调用服务器保存的RSA私钥，并用该私钥解密加密的AES密钥，得到AES密钥。最后用该AES密钥解密密文得到明文。