共计 6309 个字符，预计需要花费 16 分钟才能阅读完成。
前言
很快乐遇见你~
Https 当初根本曾经笼罩所有的 http 申请了，作为一个平凡的创造，保障了咱们的通信安全。在 Android 中对于 HTTPS 其实感知不多，因为这些内容都有成熟的框架帮咱们实现了，例如 okHttp。咱们发动一个 http 或 https 的申请简直感触不到区别。
但最近在钻研 okHttp 的源码的时候，发现很多的内容没看懂，最初发现是 http 相干的网络常识不扎实，再一次回过头来，把 https 学了一遍。正如后面所说，得益于框架，咱们简直不须要学习 https 背地到底产生了什么，然而产生了相干的 bug 也就无奈修复（面试要问[狗头]）。所以，作为一个 android 开发者，也还是很有必要学一下 https。
HTTPS 的指标就是解决网络通信的平安问题。本文首先论述网络中存在的危险，而后再探讨其波及的加密办法、证书验证，最初再同从申请的角度解析整个平安连贯的流程。
网络存在的危险
在没有通过任何加密伎俩的 HTTP 通信中，面临着三大危险：音讯监听、音讯篡改、假冒身份。
音讯监听
咱们发送的音讯须要通过很多的两头路由器，咱们无奈确保网络中每一个节点都是平安的，所以咱们发送的数据会被歹意的对象截取到。如果咱们的音讯没有通过任何加密，那么歹意用户就能够监听到咱们通信的所有数据。如下图：
解决的办法是：对通信数据进行加密。如下图：
通过加密的数据，即时被黑客截取到，他也无奈晓得数据的内容。
音讯篡改
第二个危险是音讯篡改。咱们收回的数据会通过危险的两头节点，黑客能够监听咱们的数据，也能够对咱们的数据进行批改。如下图：
解决篡改的办法是：利用 MD5 等 hash 算法伎俩来测验数据的完整性。上面会详解。
假冒身份
HTTP 并没验证身份的流程，咱们无奈保障咱们接管到的数据是服务器响应的，服务器也无奈甄别申请的用户是否是歹意用户。如下图：
解决的办法是：应用证书来测验对方的身份。
HTTP 通信面临的这些问题，让咱们的网络通信变得极其不平安，HTTPS 就是在 HTTP 的根底上来解决平安问题。
加密算法
加密算法仍旧是 HTTPS 平安通信中的重头戏。在现实的状况下，如若有一个加密算法使得 仅有 用户和服务能够加密解密，那么其实是不存在下面的平安问题的。但黑客自身，他也能够作为一个客户存在，一般客户能够加密解密，那么黑客也就能够做到。所以须要附加上动静因子来保障算法的平安。
这里解释一下什么是动静因子算法（这个名字我本人起的，仅仅为了帮忙了解）
如果当初须要发送的数据是：123
算法是：数据 + 动静整数当初通信单方磋商的动静因子是：5，那么
- 发送方对数据进行加密：123+5=128
- 接管方对数据进行解密：128-5 =123
即便黑客晓得具体的算法就是数据 + 动静整数，然而他不晓得具体的动静整数是多少，也就无奈解出原始的数据内容。这个动静整数称之为 密钥。
上面介绍 HTTPS 中用到的加密算法。
对称算法
对称算法比较简单：加密和解密数据应用雷同的密钥。如下图：
对称算法的长处就是效率很高，能够对长数据进行加解密。但对称算法也存在毛病。
第一是单方应用雷同的密钥，无奈分别数据到底是由服务器加密还是客户端加密，也就是无奈辨别一个音讯是由服务器收回还是由客户端收回。解决这个问题办法也很简略：单方加密应用不同的密钥。
第二，通信单方难以确保拿到平安的密钥。因为第一步总是须要通过网路通信来磋商密钥，那可不可以应用固定的密钥？后面讲过，黑客也是一个客户，那么他也能够拿到密钥，这个算法就失去意义了。
解决这个问题的办法是：应用非对称算法
非对称算法
对称算法是加密解密应用雷同的密钥，而非对称算法是 加密与解密应用不同的密钥。如下图：
- 非对称加密有两把密钥：公钥和私钥
- 公钥可公开给所有人，私钥必须本人窃密，不给任何人拿到
- 客户端能够应用服务器的公钥加密数据，而这份密文，只有服务器的私钥能力解开
- 反过来，应用私钥加密的数据，也只有公钥能够解开
非对称算法很好地解决了对称算法存在的问题：无奈平安替换密钥。服务器的公钥能够公开给所有的用户，当客户端首次拜访服务器，服务器便把公钥返回即可。
然而对于非对称算法有一个很重大的毛病：性能极差。所以咱们能够将对称与非对称算法联合起来，解决上述问题。
对称 + 非对称
对称算法存在的问题是无奈平安地调换密钥；因而第一步咱们能够应用非对称算法来替换密钥，后续应用对称算法来进行通信。如下图：
- 当客户拜访服务器时，服务器返回一个公钥；
- 客户端拿到公钥之后，对客户端密钥应用公钥进行加密之后发送给服务端；
- 服务端拿到客户端密钥之后对服务端密钥进行加密发送给客户端；
这样就实现了单方密钥的替换，后续能够应用密钥进行高效率通信。
到此咱们的网络传输仍旧不是平安的，因为，咱们无奈保障第一步服务器返回的公钥不会被黑客篡改。如果黑客把服务器返回的公钥转换成本人的公钥，后续他就能够对客户端的的所有音讯应用本人的私钥解密。而问题的实质在于：咱们无奈分别返回的数据是否是真的由服务器返回的 。这个问题的解决办法就是： 应用数字证书来证实信息发送方的身份。
数字证书
通过后面加密算法的探讨，对称 + 非对称算法 曾经能够解决大部分的网络安全问题。但第一步服务器返回的公钥仍旧有被黑客篡改的危险，因为咱们 无奈确保通信对方的身份。数字证书的引入，就是为了解决这个问题。
证书概述
数字证书是由公认的证书机构颁发给服务器的一个用于验证身份的数字认证。
数字证书能够用身份证来进行类比：
身份证是咱们本身身份信息的一个认证，颁发的机构是咱们全国人民认可的公安局。
同理，服务器的数字证书也是服务器身份的一个认证，颁发的机构是互联网中广泛认可的证书机构。
服务器的证书中，蕴含有服务器信息例如公钥等、证书签名、证书机构信息等。客户端拿到服务器的证书，进行证书验证后，就能够精确失去服务器的公钥，利用这个公钥，就能够实现上述的算法加密了。
总之，数字证书的作用就是 证实数据的起源，平安获取到服务器的公钥进行加密通信。
证书验证
客户端如何验证服务器的证书呢？首先得看看证书是怎么做进去的：
- 服务器向证书机构申请证书，同时提供本人的域名、地址、公钥等信息；
- 证书机构对服务器的信息应用 hash 算法得出一份 128 位的 摘要 ，并对这份摘要应用本人的私钥进行非对称加密失去 证书数字签名。
- 证书机构把服务器信息（明文）+ 数字签名 + 证书机构信息（蕴含证书机构公钥）发送给服务器
- 客户端申请服务器时，服务器把证书返回给客户端
客户端验证证书的重点就是：比拟摘要：
- 客户端拿到证书，失去服务器信息、数字签名、证书机构信息
- 客户端对服务器信息进行 hash 算法计算得出一份摘要 S1
- 客户端应用证书机构的公钥对数字签名进行解密失去一份摘要 S2
- 比照 S1 和 S2 即可分别此证书是否来自服务器且没通过篡改
通过下面的证书验证流程，客户端就能够胜利拿到服务器的公钥，进行下一步的加密流程。至于为什么通过比拟摘要即可晓得证书平安，上面进行探讨。
证书链
客户端验证证书的流程很简略：应用证书机构公钥解开证书的数字签名后进行比对即可。但这里有一个问题：如何保障证书机构的公钥可信？如果黑客应用本人的私钥加密，同时把证书机构的公钥批改成本人的公钥，那岂不是十分危险？
互联网中的主机对象十分多，但证书机构却不多。计算机产商，会在零碎中装置一些 根证书机构 的信息，其中就蕴含了这些机构的公钥。这些公钥是在肯定水平上是相对平安的，是能够信赖的。客户端能够应用这些公钥对数字签名进行解密。平安问题，终于失去了完满的解决。
零碎中预装的证书机构是无限的，但世界上每时每刻申请数字证书却十分多，他们“忙不过来”，因而有了二级证书机构。二级证书机构由根证书机构签发，二级证书机构再去给服务器签发证书。那么此时如何进行证书验证呢？还是一样的情理：
- 利用根证书机构给二级证书机构签发的时候同样是一份数字证书，其中蕴含了二级证书机构信息、数字签名、根证书机构信息
- 服务器的数字证书中蕴含了二级证书机构的数字证书
- 客户端应用根证书机构的公钥对二级证书机构的数字签名进行解密失去摘要再进行比对，失去二级证书机构的公钥
- 应用二级证书机构的公钥对服务器证书进行验证
同理，三级、四级证书机构验证都类同。在浏览器中，咱们能够查看网站的证书链：
能够看到这是一个蕴含了两级证书机构的证书链，最顶层的证书机构，即是根证书机构。
hash 算法
咱们会发现，证书并不是间接对服务器信息进行加密，而是利用 hash 算法失去服务器信息的摘要，再对摘要进行加密。那这里可能会有这些问题：
- 间接对信息进行加密不能够吗？为什么多此一举？
- 只对摘要进行加密，那么原文内容不是泄露了吗？
hash 算法最罕用的就是 MD5，他能够把一段数据转化成一个 128 位的长度的摘要，不同的数据，会失去不同的摘要。
摘要的长度更短，应用非对称加密的效率更高。因而，证书中对摘要而不是间接对信息进行加密能够 进步网络效率。而服务器信息自身并不是敏感信息，不怕被黑客截取监听，所以能够应用明文传输。
hash 算法不仅为了提高效率，更重要的是能够 分别信息是否蒙受了篡改。
如果在证书中咱们间接对服务器信息进行私钥加密，黑客截取到咱们的数据后，他尽管看不懂，然而他能够间接对密文进行篡改。最初接管方解密之后失去的就是一分谬误的信息。
如果信息是一个文本，咱们能够很显著地辨别出来；但如果是一个数字编号，那么很难晓得是否蒙受了篡改。举个例子：
- 服务器发送货物编号 123，对 123 进行加密之后失去 098
- 黑客截取后无奈解密，将 098 批改成 048 之后发送给客户端
- 客户端解密 048 之后失去 129，数据蒙受了篡改；尽管黑客不晓得咱们发送什么，然而能够让咱们的业务产生谬误
此时如果对密文进行 hash 失去一份摘要，同时对摘要进行加密。客户端拿到数据之后，对密文进行 hash 再加密，再与服务器发送过去的摘要进行比对即可晓得数据是否产生了篡改。黑客不论是批改密文 or 摘要密文，最初都会导致最初两者的摘要不等。
hash 算法的优化
MD5 算法是有毛病的，他会产生碰撞。例如一年只有 366 天，但中国有 13 亿人口，必定会有十分多的人生日雷同。同理，摘要的长度只有 128 位，无奈 惟一示意 所有的数据，存在肯定的危险：两份不同的数据失去雷同的摘要。让黑客变得无隙可乘，所以须要引入一种优化计划：HMAC（音讯认证码）。
HMAC 与 MD5 的差异在于，他并不是间接对数据进行 hash，他还须要一个 随机数来独特作用 hash，只有保障每次的随机数不同，黑客拿不到随机数，也就无奈对 hash 算法进行破解；即便两次的数据一样，因为随机数不同，最终得出的摘要也不同；这更进一步保障了平安。
然而随机数须要通信单方进行协商拟定，所以在证书中无奈应用 HMAC。然而在 HTTPS 平安通信中，则能够退出随机数来实现 HMAC，进步安全性。
平安模型
这一大节次要讲一下 HTTPS 为咱们建设的宏观平安模型。
须要特地留神的是，HTTPS 并不是一个新的利用协定来取代 HTTP，而是在 HTTP 的根底上，减少了网络安全的内容。HTTPS 的全称：Hyper Text Transfer Protocol over SecureSocket Layer，建设在平安 socket 档次上的超文本传输协定，能够认为 HTTPS = HTTP+SSL。HTTPS 与 HTTP、TCP 的关系如下：
HTTPS 在 HTTP 和 TCP 之间建设了一个平安连贯层。SSL/TLS 档次和 TCP 很相似，单方建设 TCP 连贯之后，须要再建设平安连贯。与 TCP 连贯一样，SSL 连贯实质上，是对单方平安信息的记录，并不是一个真正意义上的连贯。HTTP 通过平安连贯，即可与指标主机进行平安的通信，不怕被监听、篡改、假冒身份。
这里的 SSL 与 TLS 指的都是平安协定。SSL 全名 Secure Sockets Layer，安全套接字层协定；TLS 全名 Transport Layer Security，平安传输层协定。TLS 从 SSL 倒退而来，SSL 是晚期的平安层协定；前期逐步发现了其安全漏洞，倒退出了 TLS。当初应用的最多的是 TLS1.2、TLS1.3 版本，如咱们查看掘金的证书：
能够看到应用了 TLS1.2 版本。平安协定版本须要通信单方进行协商，只有应用雷同版本的协定，能力建设平安连贯。
此外，建设平安连贯是比拟耗费性能的。如果每次申请都建设一次平安连贯，那么网络的效率将会大打折扣。因而，在建设一次平安连贯之后，服务器会存储客户端的平安相干信息，在肯定工夫内通信时无需再次建设平安连贯，服务器会把先前的密钥等信息发送给客户端，间接应用此前曾经记录的平安信息即可。
平安连贯建设流程
和 TCP 连贯类同，平安连贯也须要一个建设的流程。然而通过了后面 HTTPS 加密算法以及证书体系的学习，了解 HTTPS 平安连贯建设流程就非常简单了。根本就是把下面的流程走了一遍。先来看一张总体图：
客户端申请服务器建设平安连贯，附加客户端反对的 SSL 与 TLS 版本、反对的加密算法版本、随机数。
加密算法与平安协定版本有很多，但服务不肯定反对最新版本的协定预算法。所以客户端把所以反对的版本发送给服务器，让服务器去抉择。
随机数十分重要，后面讲 hash 算法的时候讲到，随机数是一个动静因子，让 hash 算法更加平安。同时，随机数也参加了对称密钥的生成。
服务器响应申请，附加抉择的协定版本、加密算法版本、服务器随机数。
服务器从客户端反对的协定版本中，抉择一套本人最喜爱的。
为了分别音讯是由哪一方加密并收回的，须要筹备两个对称密钥。因而服务器也须要产生一个随机数。
服务器向客户端发送证书
服务器向客户端发送本人证书，其中就蕴含了服务器的公钥。
- 服务器发送 hello done 示意 hello 阶段完结
客户端验证证书，拿到服务器公钥；利用两个随机数，生成 pre-master secret，并应用服务器的公钥加密发送给服务器。
证书验证步骤参考下面的证书大节；
pre-master secret 是一个十分重要的货色，单方利用 pre-master secret 生成 master-secret，利用后面的两个随机数生成两个对称加密密钥和两个 HMAC 密钥，两对密钥别离用于客户端加密和服务器加密。
- 客户端发送 changeCipherSpec 提醒服务器尔后应用 pre-master secret 产生的密钥加密通信
- 客户端发送 FIN 报文，示意完结
- 服务器也发送 changeCipherSpec 报文
- 服务器也发送 FIN 报文，示意完结
- 单方能够开始平安通信了
至此，对于 HTTPS 的加密流程，曾经比拟清晰了。
Android 中使用
无论是 HTTP 还是 HTTPS，事实上开源网络框架都曾经为咱们实现了这些细活累活，例如 okHttp。失常状况下，发动 HTTP 和 HTTPS 申请并没有任何异同。但有时候会呈现一些非凡的问题，就须要咱们本人入手解决：
- 零碎过于老旧，没有装置根证书。不足根证书的公钥，那么无奈验证服务器证书是否平安。
- 自签名证书。本人的 app 拜访本人的服务器，有时候为了节约经费，能够本人给本人的服务器签名。
- 证书信息不足要害信息，如颁发证书的机构。
对于下面的问题，咱们能够本人重写证书验证流程，或者在 okHttp 中增加信赖的服务器公钥，能够解决下面的问题。
最初
HTTPS 要解决的就是计算机网络中的平安问题，不同问题的解决办法要分明：
- 避免音讯监听：加密
- 避免音讯篡改：hash 算法
- 验证身份：数字证书
HTTPS 就是利用这些办法，为通信单方建设平安连贯，从而来实现平安通信。
如果文章对你有帮忙，还心愿能够留下您的点赞激励一下作者~
全文到此，原创不易，感觉有帮忙能够点赞珍藏评论转发。
有任何想法欢送评论区交换斧正。
如需转载请评论区或私信告知。另外欢迎光临笔者的集体博客：传送门
