Android 深入Http（3）Https的工作机制

例如用户登录了一个银行网站，然后又去访问了坏人的网站，然后嗨客就更改了Cookie信息，等到用户下次登录银行网站后，做转钱操作，这个时候Cookie就会更改请求信息，把转钱的url改一下，就转到嗨客手中了。

解决方案是使用：Referer

Authorization

---

Authorization有两种类别，一种是Basic，一种是Bearer

Basic

用Http的Request来介绍：

【GET /user Http/1.1

Host：XBao.com

Authorization：Basic：<username:password(Base64)>】

↑其中的xxxx就是信息的Base64码

比如 （rikka：123）–》Base64编码 ，然后放在Basic中。

然后发送请求后，服务器通过验证Basic，来判断用户本人。

但是这个是不是也忒不安全了，毕竟Base64通过码表就能破解了，信息如果被捕获，那不就完了。

所以一般这种东西都是存在本地，在本地做验证…

Bearer

相当于一个授权凭证、令牌。

格式为：

Authorization：Basic：< bearer token>

这个token是api的token。这个token是授权方给的，所以相较于Basic，它更加安全。

OAuth2

OAuth2是基于Bearer的第三方授权，可以让开发更加安全。

比如我要登录CSDN，然后可以用QQ来授权登录，这个时候 我和QQ是第一方和第二方，CSDN是第三方。（这里也不用分的太清楚）

然后在登录的网页的URL就能看到 一个Client_Id:

这个client_id是CSDN传过去的，是CSDN给QQ的指定id。

Client-ID它的作用是传给QQ后，QQ识别后，你这个是CSDN登录，我给你整一个快速登录的界面，这个界面是专门的 用于CSDN的快速登录。

在了解完OAuthor2的概念后，我们来具体看一下OAuthor2的工作流程

OAuthor2的工作流程

---

首先，CSDN向QQ发送授权请求，并且发送client_id，这个client_id是CSDN和QQ在一开始就协商好的，csdn给到qq后，qq说OK，用户要在csdn申请QQ登录，了解。

然后呢QQ接收到了client_id，就会给CSDN返回一个授权码Authorization code

这个并不是token，因为token很重要，而且OAuthor2不要求使用HTTPS，所以这个中间的信息很有可能被盗用，所以不能传token。那么token如何获取呢？

这个时候CSDN会把Authorization code给其服务器，而这个过程是绝对安全的，不怕被窃取的。

然后CSDN的服务器会去向QQ的服务器发送请求，发送的时候带上了Authorization code 和 client_secret

client_secret是CSDN第三方登录时产生的，是绝对安全的，只有Server才有，而它传向QQ的传输过程绝对是HTTPS连接。

所以 QQ获取了 client_secret，它就有足够的信息知道，对方是CSDN用户在操作了，这个时候，它就把token传过去了。

这个时候Server拿到token后，OAuthor2的流程就已经结束了。

之后CSDN通过权限，比如去获取QQ的头像、用户名什么的，就会通过Bearer获取：

比如发送一个Request获取头像：

【GET /user/avator Http/1.1

Host：QQ.com

Authorization：Bearer< rikka token (base64)>】

微信登录

其实流程就是和上述差不多，也是个标准的OAuthor2流程。

access_token可能会失效，可以通过 https的Refresh Token向对方刷新token，这个时候怎么让对方知道你是原来之前那个人而不是新的人过来骗他盗取信息呢？那只能是通过 client_secert来让对方知道啦。

所以 client_secert真的很重要，必须要保密。

登录和授权就介绍到这里。

主要是介绍了 Cookie、Authorization，都是比较好理解的。

接下来来介绍下TCP/IP协议族

4、TCP/IP协议族

===========================================================================

一系列协议所组成的一个网络分层模型。

我们这里就不再讲解TCP的三次握手四次挥手了。因为那个比较简单，大家都懂。

这里主要讲一下为什么网络要分层？

首先看一下下面的数据在网络中的传输图：

从客户端到服务端的数据传输会经过许许多多的节点、路由器。

最理想的情况当然是直接从一个客户端，一条线连接到服务端。数据不走任何节点，但这个不可能发生的。

就是因为经过这么多的节点，所以会出现：总会有那么几个网络节点不稳定。整个网络是不可能一直保持的稳定的，数据的丢失和重传是一定会发生的。比如那种更大数据，就必须使用分段传输了。

而分段传输就必须要分层了。

所以网络的分层模型必须要抽出一层来做数据包分发，这一层就是传输层，TCP。

而TCP、UDP都有网络的需求，它们如果又要分包又要查包又要传包，那它们的工作也太多了。

所以这个时候又专门抽出一层来蒙头传，它不管包的顺序，也不管包到了没有，就是 通过给上层给自己的目标、路由表进行 寻址，然后传数据，这就是网络层、IP层，等传完之后，服务端的网络层把数据往上层 传输层传，让传输层来判断 有没有数据丢了，如果丢了，就告诉自己的TCP层，然后自己的TCP层又装好包让IP层去传数据。

数据链路层就是真实的传数据（每个包的数据），而且是二进制的，10101001的传。

都是些文字，没有图片。可以总结出：网络分层的根本原因是网络不稳定

TCP/IP就到这里，不用多讲，因为本blog并不是专门研究TCP/IP的。

TCP的连接就不讲啦，我们只需知道：

HTTP的连接指的就是TCP的连接，因为HTTP本来就是无连接的、无状态的，这是一个概念性的东西。

这里了解完就可以进入HTTPS的学习了。

5、HTTPS的机制

==========================================================================

这里进入正题。

HTTPS就是在HTTP的基础上使用了SSL协议（又称TLS协议）

先说大致的步骤：

1. 客户端请求建立TLS连接

2. 服务器返回证书

3. 客户端验证服务器证书

4. 验证通过后，和服务器协商对称密钥（这个过程是非对称加密）

5. 使用对称加密开始通信

看到了密钥，就说明了Https里确实是用到了对称加密，先用非对称加密协商对称加密的私钥，再用对称加密来进行交流。

这里先说一下为什么不全程用非对称加密，因为非对称加密太慢了，本来https就很慢，如果通信还是非对称加密的话那就更慢了。

然后我来文字+图解Https的连接，就是客户端向服务端完成一个Https连接的过程。

1. 客户端向服务端发送一个 “连接请求”，比如发送一个字符串“I am Client，Hello”

除了这个字符串，还会附加一些信息，比如可用的TLS版本，Cipher Suite（可以接受的对称加密算法、非对称加密算法、Hash算法），和一个客户端随机数（后面会在加密的时候用到）

2. 服务器收到后，向客户端发送一个“确认”，发送一个字符串比如：“I am Server，Hello”

然后从客户端所带的信息里，挑选自己想要使用的 TLS版本、自己喜欢的加密算法。

传过去以后，双方就已经确认好了 TLS版本、Cipher Suit，和各自的随机数。

3. 服务器继续发送一个证书，这个证书很重要

这个证书包含了服务器的公钥和三级证书。

我们来逐个分析这整个服务器发送给客户端的证书：

（1）一级证书：它包含了服务器的地址、服务器加密公钥和证书签名，要求客户端使用这个公钥，但由于传输不是安全的，所以有可能这个证书是伪造的！所以我们需要验证该证书的签发机构是否是可靠的。所以就这里就带了二级证书。

（2）二级证书：它首先包含了证书机构的自身信息，并且带上了一级证书的公钥，用这个公钥可以解开一级证书中的证书签名（所以这个地方使用到了是签名验证），但是坏人万一很厉害，可以自己搞一个证书机构，然后自己做一对密钥，然后以及证书也是这样伪造出来的，那怎么搞？所以最权威的三级证书出现了

（3）三级证书：它又称根证书，它可以验证二级证书是安全的！并且它最权威，它的可靠是官方认证的。根证书保存于我们的操作系统（苹果官方、谷歌官方、微软官方..官方认证！），也就是说，它从操作系统创建的时候，就已经存在了。是最老大的签发机构，所以当验证完了根证书后，那么这整个证书的可靠性就能知道了。

当然，如果连根证书都是有问题的话，那我们是不可能有办法的（因为我们必须无条件信任根证书）

一般都有三级证书，大家（如果是Chrome浏览器）可以点击网站左边的 锁头，然后就可以查看三级证书信息了（根证书很忙的，所以一般不会直签三级证书）

4. 然后服务器还没有发完！它在这个时候正式的使用了并且是唯一一次非对称加密（上面那个验证签名的不算）

服务器用其发送的 证书公钥非对称加密了一个 Pre-master Secret，它也是一个随机数。

5. 双方根据Pre-master Secret和客户端随机数+服务器随机数 算出 Master Secret，这个一听名字就很隐私。

（我也不知道，虽然客户端随机数和服务器随机数都是明文传输的，但是数学上和实际上，这样更加的安全 = =！）

6. 双方根据Master Secret计算出密钥，而且是6个（其中有2个不重要）

这样客户端发消息，服务端就可以用自己的密钥来解。反之，客户端可以用自己的密钥解开服务端发来的消息

MAC Secret可以用来验证HMAC。就相当于用来验证双方的身份。

7. 双方验证加密算法能不能用，客户端声明使用加密通信

8. 客户端发送“END"（自定义的字符）+前面所获取的所有东西进行对称加密打包发送过去

9. 服务器验证完客户端HMAC后，使用客户端的加密密钥来验证信息，声明使用加密通信

10. 服务器发送“END”（自定义的字符）+前面获取的所有信息对称加密打包发过去

11. 客户端验证完了，HTTPS就建立了。

到此Https的流程包括机制就讲完了。这个流程多么的复杂。

但是完成连接后，他们之后发送的消息就是 这样的：应用层： @asiohagoaihtga@￥

根本就看不懂，连是不是Http消息都不知道，所以知道这样是有多安全。

Https在Android的使用

---

一般情况下是直接使用。

如果不是直接使用的情况下，一般都是

• 内网（自签名证书）

• 证书信息不全

• 手机操作系统比较旧，没有安装最新的根证书。

总结

---

Https到这里就讲完了。流程是最重要的

如果你在面试的时候，不要和网上的那种“浅显”的分步走，建议直接装逼嗷：

不要讲什么服务器发送了证书，而是要将：服务器发送了一个包含了信任链的证书（一二三级讲一讲）

然后扯到了证书的签名（用公钥和私钥可以互解讲一讲）
然后非对称加密加密了Pre-Master Secret （非对称加密讲一讲）
又用Master Secret算出了四个密钥（HMAC可以讲一讲，我这里没有介绍，大家可以自行百度）
哇，简直，很帅的好吧。

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
…(img-4WE54VWA-1715353126760)]

[外链图片转存中…(img-1N4xIDZC-1715353126761)]

[外链图片转存中…(img-UvErjjYH-1715353126764)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！