通过 HTTPS 和 SSL 确保安全
HTTPS加密过程和TLS证书验证
HTTPS
HTTPS的加密过程:
image.png
- 客户端发起HTTPS请求：用户在浏览器里输入一个HTTPS网址，然后连接到服务端的443端口。
- 服务端的配置：采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。
- 传送证书：这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
- 客户端解析证书：这部分工作是由客户端的SSL/TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警示框，提示证书存在的问题。如果证书没有问题，那么就生成一个随机值。然后用证书（也就是公钥）对这个随机值进行加密。
- 传送加密信息：这部分传送的是用证书加密后的随机值，目的是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
- 服务端解密信息：服务端用私钥解密后，得到了客户端传过来的随机值，然后把内容通过该随机值进行对称加密，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。
- 传输加密后的信息：这部分信息就是服务端用私钥加密后的信息，可以在客户端用随机值解密还原。
- 客户端解密信息：客户端用之前生产的私钥解密服务端传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。
SSL（TLS）
SSL发展到3.0版本后改成了TLS。TLS主要提供三个基本服务：
- 加密
- 身份验证，即证书验证
- 消息完整性校验
加密
image.png
TLS协议是基于TCP协议之上的，图中第一个蓝色往返是TCP的握手过程，之后两次橙色的往返，我们可以叫做TLS的握手。握手过程如下：
- client1：TLS版本号+所支持加密套件列表+希望使用的TLS选项
- Server1:选择一个客户端的加密套件+自己的公钥+自己的证书+希望使用的TLS选项+（要求客户端证书）；
- Client2:(自己的证书)+使用服务器公钥和协商的加密套件加密一个对称秘钥（自己生成的一个随机值）；
- Server2:使用私钥解密出对称秘钥（随机值）后，发送加密的Finish消息，表明完成握手
证书机制/证书验证
image.png
- 客户端获取到了站点证书，拿到了站点的公钥；
- 要验证站点可信后，才能使用其公钥，因此客户端找到其站点证书颁发者的信息；
- 站点证书的颁发者验证了服务端站点是可信的，但客户端依然不清楚该颁发者是否可信；
- 再往上回溯，找到了认证了中间证书商的源头证书颁发者。由于源头的证书颁发者非常少，我们浏览器之前就认识了，因此可以认为根证书颁发者是可信的；
- 一路倒推，证书颁发者可信，那么它所颁发的所有站点也是可信的，最终确定了我们所访问的服务端是可信的；
- 客户端使用证书中的公钥，继续完成TLS的握手过程。
证书颁发者一般提供两种方式来验证证书的有效性： CRL 和 OCSP。
- CRL（Certificate Revocation List）即 证书撤销名单。证书颁发者会提供一份已经失效证书的名单，供浏览器验证证书使用。当然这份名单是巨长无比的，浏览器不可能每次TLS都去下载，所以常用的做法是浏览器会缓存这份名单，定期做后台更新。这样虽然后台更新存在时间间隔，证书失效不实时，但一般也OK。
- OCSP(Online Certificate StatusProtocol)即 在线证书状态协议。除了离线文件，证书颁发者也会提供实时的查询接口，查询某个特定证书目前是否有效。实时查询的问题在于浏览器需要等待这个查询结束才能继续TLS握手，延迟会更大。
Android SSL证书
在Android中，通常使用知名颁发机构（称为证书授权机构 (CA)）颁发的证书配置服务器。主机平台一般包含其信任的知名 CA 的列表。从 Android 4.2 (Jelly Bean) 开始，Android 目前包含在每个版本中更新的 100 多个 CA。CA 具有一个证书和一个私钥，这点与服务器相似。为服务器颁发证书时，CA 使用其私钥为服务器证书签名。然后，客户端可以验证该服务器是否具有平台已知的 CA 颁发的证书。
网友评论