‘壹’ HTTPS加密原理
HTTP、HTTPS在我们日常开发中是经常会接触到的。
我们也都知道，一般 Android 应用开发，在请求 API 网络接口的时候，很多使用的都是 HTTP 协议；使用浏览器打开网页，也是利用 HTTP 协议。看来 HTTP 真是使用广泛啊，但是，HTTP 是不安全的。利用网络抓包工具就可以知道传输中的内容，一览无余。比如我经常会使用 Fiddler 来抓包，搜集一些有趣的 API 接口。
那么问题来了，如何保证 HTTP 的安全性呢？基本上所有的人都会脱口而出：使用 HTTPS 协议。99.9% 的人都知道 HTTPS 会将传输的内容进行加密，但是接着问具体加密的过程和步骤，很多人就哑口无言了。
为了防止出现这种尴尬的局面，所以今天你就要好好看看这篇的内容了。以后就可以装个逼，哈哈！
先科普一下，加密算法的类型基本上分为了两种：
对称加密的意思就是说双方都有一个共同的密钥，然后通过这个密钥完成加密和解密，这种加密方式速度快，但是安全性不如非对称加密好。
举个例子，现在学霸小明这里有一道数学题的答案：123 。他想把答案传给自己一直暗恋的小红。所以他们双方在考试开考前，约定了一把密钥：456 。那么小明就把答案内容经过密钥加密，即 123 + 456 = 579 ，将 579 写在小纸条上扔给小红。如果此时别人捡到了小纸条，不知道他们是加密传输的，看到上面的 579 ，会误以为答案就是 579 ；如果是小红捡到了，她拿出密钥解密，579 - 456 = 123 ，得到了正确的答案。
这就是所谓的对称加密，加解密效率高，速度快，但是双方任何一方不小心泄露了密钥，那么任何人都可以知道传输内容了。
讲完了对称加密，我们看看啥是非对称加密。
非对称加密就是有两把密钥，公钥和私钥。私钥自己藏着，不告诉任何人；而公钥可以公开给别人。
经过了上次作弊后，小红发现了对称加密如果密钥泄露是一件可怕的事情。所以她和小明决定使用非对称加密。小红生成了一对公钥和私钥，然后把公钥公开，小明就得到了公钥。小明拿到公钥后，把答案经过公钥加密，然后传输给小红，小红再利用自己的私钥进行解密，得到答案结果。如果在这个过程中，其他人得到传输的内容，而他们只有小红公钥，是没有办法进行解密的，所以也就得不到答案，只有小红一个人可以解密。
因此，相比较对称加密而言，非对称加密安全性更高，但是加解密耗费的时间更长，速度慢。
对称加密和非对称加密的具体应用我还是深有体会的，因为所在的公司是做金融支付方面的，所以加解密基本上算是天天见了。
说完加密类型后，我们再来看看 HTTPS 。
我们先来看一个公式：
HTTPS = HTTP + SSL
从这个公式中可以看出，HTTPS 和 HTTP 就差在了 SSL 上。所以我们可以猜到，HTTPS 的加密就是在 SSL 中完成的。
所以我们的目的就是要搞懂在 SSL 中究竟干了什么见不得人的事了？
这就要从 CA 证书讲起了。CA 证书其实就是数字证书，是由 CA 机构颁发的。至于 CA 机构的权威性，那么是毋庸置疑的，所有人都是信任它的。CA 证书内一般会包含以下内容：
正好我们把客户端如何校验 CA 证书的步骤说下吧。
CA 证书中的 Hash 值，其实是用证书的私钥进行加密后的值（证书的私钥不在 CA 证书中）。然后客户端得到证书后，利用证书中的公钥去解密该 Hash 值，得到 Hash-a ；然后再利用证书内的签名 Hash 算法去生成一个 Hash-b 。最后比较 Hash-a 和 Hash-b 这两个的值。如果相等，那么证明了该证书是对的，服务端是可以被信任的；如果不相等，那么就说明该证书是错误的，可能被篡改了，浏览器会给出相关提示，无法建立起 HTTPS 连接。除此之外，还会校验 CA 证书的有效时间和域名匹配等。
接下来我们就来详细讲一下 HTTPS 中的 SSL 握手建立过程，假设现在有客户端 A 和服务器 B ：
到此，SSL 握手过程就讲完了。可能上面的流程太过于复杂，我们简单地来讲：
我们可以发现，在 HTTPS 加密原理的过程中把对称加密和非对称加密都利用了起来。即利用了非对称加密安全性高的特点，又利用了对称加密速度快，效率高的好处。真的是设计得非常精妙，令人赞不绝口。
好了，HTTPS 加密原理到这就讲的差不多了，不知道电脑前的你有没有看懂呢？
如果有哪里不明白的地方，可以在底下留言交流。
bye ~~
‘贰’ URL内 参数加密解密
javascript对URL中的参数进行简单加密处理
javascript的api本来就支持Base64，因此我笑笑们可以很方便的来进行编码和解码。
var encodeData = window.btoa("name=xiaoming&age=10")//衡升败编码
var decodeData = window.atob(encodeData)//解码。
下面来个具体的例子来说明如何对url中参数进行转码，并取得解码后的参数
假如要跳转的url = "stu_info.html?name=xiaoming&age=10"
转码：url = "stu_info.html?"+window.btoa("name=xiaoming&age=10");
跳转：window.open(url)或者window.locaton.href = url;
解码：解码时我们首先要从url中获得参数列表，
我们可以通过var paramsString = window.location.search来获取url中?号开始的内容（url的咐颤查询部分）即"?name=xiaoming&age=10"；
然后去掉?号 paramsString = paramsString.substring(1) //"name=xiaoming&age=10"
去掉& paramsString = paramsString.split("&");//["name=xiaoming","age=10"]
需要指出的是 window.btoa这中编码方式不能直接作用于Unicode字符串。只能将ascci字符串或二进制数据转换成Base64编码过的字符串。如果要对Unicode字符进行编码可以将做如下转换。
var encodeData = window.btoa(window.encodeURIComponent("name=小明&age=10"))//编码
var decodeData = window.decodeURIComponent(window.atob(encodeData))//解码。
获取url参数
//获取url参数
function getQueryString(name) {
var reg = new RegExp("(^|&)" + name + "=([^&]*)(&|$)", "i");
var params = window.location.search.substr(1);
params = window.decodeURIComponent(window.atob(params));
var r = params.match(reg);
if (r != null) {
return decodeURI(r[2]);
}
return null;
}
‘叁’ HTTPS 加密算法过程
1、HTTP 协议（HyperText Transfer Protocol，超文本传输协议）：是客户端浏览器或其他程序与Web服务器之间的应用层通信协议 。
2、HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：可以理解为HTTP+SSL/TLS， 即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL，用于安全的 HTTP 数据传输。
3、SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。
4、TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）。
如上图所示 HTTPS 相比 HTTP 多了一层 SSL/TLS。
1、对称加密
有流式、分组两种，加密和解密都是使用的同一个密钥。
例如：DES、AES-GCM、ChaCha20-Poly1305等
2、非对称加密
加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥，公钥和算法都是公开的，私钥是保密的。非对称加密算法性能较低，但是安全性超强，由于其加密特性，非对称加密算法能加密的数据长度也是有限的。
例如：RSA、DSA、ECDSA、 DH、ECDHE
3、哈希算法
将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多，且算法不可逆。
例如：MD5、SHA-1、SHA-2、SHA-256 等
4、数字签名
签名就是在信息的后面再加上一段内容（信息经过hash后的值），可以证明信息没有被修改过。hash值一般都会加密后（也就是签名）再和信息一起发送，以保证这个hash值不被修改。
C++音视频开发学习资料 ：点击 音视频开发（资料文档+视频教程+面试题）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）
HTTP协议在浏览器/服务器间进行数据的传输是明文的，不做任何的加密，通俗来说，就是“裸奔”，这样会产生什么样的问题那，我们来举一个例子：
在这里插入图片描述
上述我们通过两个人物模仿了服务器和客户端的交互，我们可以看出，小明和小花之间进行数据通信的时候采用的是明文传输的、那么此时很有可能被中间人获取信息、并进行数据篡改，这种行为就叫 中间人攻击。
所以 HTTP 传输面临的风险有：
（1） 窃听风险：黑客可以获知通信内容。
（2） 篡改风险：黑客可以修改通信内容。
（3） 冒充风险：黑客可以冒充他人身份参与通信。
哈哈、此时你是不是不能很愉快的上网冲浪了呀，别担心，我们此时可以对明文进行加密：
这样是不是比原来安全多了呀！但是这样就足够安全了吗？显然不是的，如果小明和小花在第一次聊天的时候，信息被中间人截取到了，那么中间人是不是也就有密钥了，同样可以对数据进行加解密和修改了那
这可怎么办那？ 加密的数据还是不安全的啊？ 别急，上面我们采用的是对称加密（换句话说就是我们发送的密钥技能加密、也能解密，那么中间人只要拿到密钥消息对他而言就是透明的了），我们还可以采用非对称加密方式进行加密数据(非对称加密一般都会有一个私钥和公钥组成。可以通过公钥加密，私钥解密，也可以通过私钥加密，公钥解密两种方式) ，对密钥的传送在格外加一层保护，当小明和小花在建立通信的时候，小花会把公钥KEY发送给小明，当小明拿到公钥KEY 后，会自己生成一个 密钥 KEY2 , 并用 KEY 对KEY2 进行加密（此时小明用的是公钥加密）
在通信过程中，即使中间人一开始就获取到了公钥KEY ,但是他不知道私钥，就对数据无法进行解密，仍旧是没办法获取KEY2。这样加密后，数据是不是就安全多了呀。这种情况下就可以和妹子愉快的进行聊天了吗？别急、所谓道高一尺魔高一丈，常言道：流氓不可怕，就怕流氓有文化。这种状态下我们的数据，相当来说是比较安全的，但是如果此时中间人获取公钥后，发送给小明一个伪公钥，又会产生什么问题那？
好吧，说到这里，大家是不是快恨死这个中间人了啊，哈哈~~~还有据俗话别忘记了，魔高一尺道高一丈，对于这种情况。我们可以借助与第三方证书平台，证书平台具备产生证书的功能，服务器（小花）可以去证书机构申请证书，证书机构通过小花提供的信息（网址、机构、法人等、公钥），生成公钥和私钥（证书机构的），通过私钥进行数据的非对称加密生成证书、将证书颁发给小花。那么此时小花就可以在进行数据交互的时候，传递证书了。
小明只需要知道证书的发证机构、就可以很方便的获取到证书的公钥、从而对证书进行校验并获取公钥、然后进行后续的操作。
那么此时小伙伴是不是又有疑问了，如果 中间人 获取到证书、并伪造证书给小明、怎么破？？？
不错不错、如果大家有这个想法的话，说明大家都在认真思考了。那么我们假设中间人获取到了证书、中间人也可以在证书机构获取公钥，并通过证书机构公钥获取 服务器发送的公钥，中间人此时也可以自己生成公钥，并向证书机构申请证书、并发送伪证书给小明，但是因为证书是经过签名认证的，包含（网址、机构、法人等、公钥）等信息，小明在拿到伪证书后，通过证书公钥很容易就发现证书是不合法的(网址、法人的信息可定不符，否则申请不到证书的)。
上述我们分享的内容就是HTTPS的主体思想，HTTPS增加了SSL安全层，上述介绍的所有认证流程都是在SSL安全层完成验证的。今天我就分享HTTPS的实现原理就说这么多了。 ﹏
HTTPS 缺点：
（1）SSL 证书费用很高，以及其在服务器上的部署、更新维护非常繁琐。
（2）HTTPS 降低用户访问速度（多次握手）。
（3）网站改用HTTPS 以后，由HTTP 跳转到 HTTPS 的方式增加了用户访问耗时（多数网站采用302跳转）。
（4）HTTPS 涉及到的安全算法会消耗 CPU 资源，需要增加大量机器（https访问过程需要加解密）。
‘肆’ 加密、签名、证书的作用及运用场景
本文主要是简单介绍了常见的加密类型、各自的运用场景、为什么需要数字签名和数字证书、HTTPS涉及到的加密流程等。这里主要从使用者的角度出发，对算法本身不做过多介绍。
对称/非对称加密均属于 可逆加密，可以通过密钥将密文还原为明文 。
有时候，我们希望明文一旦加密后，任何人（包括自己）都无法通过密文逆推回明文，不可逆加密就是为了满足这种需求。
不可逆加密主要通过 hash算法实现：即对目标数据生成一段特定长度hash值 ；无论你的数据是1KB、1MB、1GB，都是生成特定长度的一个Hash值（比如128bit）。这里大家应该能感受到一点 不可逆 的味道，加密后128bit的hash值显然无法还原出1个G甚至更大的不规则数据的， hash可以看做是原来内容的一个摘要 。
常见算法：
小明给小红写信：
经过九转十八弯后，信的内容有可能：1. 被窥视 2. 被篡改（冒充小明发送假消息） ：
小红先 生成对称加密的密钥key1 ，然后通过一个安全的渠道交予小明。
传输数据时，小明 使用key1加密 ，而小红收到后再 使用key1解密 。
这时候 中间者既看不到原来的内容，也没办法篡改 （因为没有密钥）：
【对称加密】实现简单，性能优秀 ，算法本身安全级别高。然而对 密钥的管理 却是个很头疼的问题：一旦密钥交到对方手里，对方对密钥的保管能力 我方是没办法控制 的，一旦对方泄露的话，加密就形同虚设了。
相对而言，【非对称加密】的公钥就没有这个忧虑，因为 公钥 的设计就是为了 可以公开的 ，尽管对方泄露，我方也不会有任何损失。
小红生成一对公私钥，自己持有私钥（pri_key1），将公钥（pub_key1）交予小明。
传输数据时，小明使用 公钥加密 ，小红使用 私钥解密 。
因为 中间者没有私钥，公钥加密的内容是无法获取的 。此时达到了 防窥视 的效果：
然而因为 公钥是可以公开的 ，如果 中间者知晓公钥 的话，尽管没有办法看到原来的内容，却 可以冒充小明发送假消息 ：
这时小红在想，如果小明发送消息时，能带上 只有他自己才能生成 的数据（字符串），我就能 验证是不是小明发的真实消息 了。
通常这个 能证实身份的数据（字符串） 被称之为 数字签名（Signature）
小明再生成一对公私钥 ，自己持有私钥（pri_key2），将公钥交予小红（pub_key2）。
当小明传输数据时（可能很大），除了公钥加密明文之外，还要带上签名：(1) 对明文做一个hash摘要 (2)对摘要进行私钥加密，加密结果即签名（传输内容=内容密文+签名）
小红收到后：(1) 解密签名获取hash (2)解密内容密文，对解密后的明文进行hash；如果两个hash一致，说明验签通过。
尽管中间者修改了传输内容，但因为签名无法冒认（没有私钥），小红验签失败，自然不会认可这份数据：
通常 非对称加密要做到防窥视和防篡改，需要有两对公私钥 ：对方的公钥用于内容加密，自己的私钥用于签名（让对方验证身份）。
因为HTTP协议明文通信的安全问题，引入了HTTPS：通过建立一个安全通道（连接），来保证数据传输的安全。
服务器是 没办法直接将密钥传输到浏览器的 ，因为在 安全连接建立之前，所有通信内容都是明文的 ，中间者可窥视到密钥信息。
或许这时你想到了非对称加密，因为公钥是不怕公开的：
然而在第2步， 中间者可以截取服务器公钥，并替换成了自己的公钥 ，此时加密就没意义了：
为了 防止公钥被假冒，数字证书（digital certificate ）便诞生了 。
当服务器需要告诉浏览器公钥时，并不是简单地返回公钥，而是响应 包含公钥信息在内的数字证书 。
证书主要包含以下内容：
浏览器通过 【颁发机构的公钥】进行解密验签 ，验签通过即说明证书的真实性，可以放心取 证书拥有者的公钥 了。（ 常用CA机构的公钥都已经植入到浏览器里面 ）
数字证书只做一件事： 保证 服务器响应的 公钥是真实的 。
以上保证了 [浏览器⇒服务器] 是加密的，然而 [服务器⇒浏览器] 却没有（上图第4步）；另外一个是 性能问题 ，如果所有数据都使用非对称加密的话，会消耗较多的服务器资源，通信速度也会受到较大影响。
HTTPS巧妙地结合了非对称加密和对称加密，在保证双方通信安全的前提下，尽量提升性能。
HTTPS（SSL/TLS）期望 建立安全连接后，通信均使用【对称加密】 。
建立安全连接的任务就是让 浏览器-服务器协商出本次连接使用的【对称加密的算法和密钥】 ；协商过程中会使用到【非对称加密】和数字证书。
特别注意的是：协商的密钥必须是不容易猜到（足够随机的）：
其中比较核心的是随机数r3（pre-master secret），因为之前的r1、r2都是明文传输的， 只有r3是加密传输 的。至于为什么需要三个随机数，可以参考：
以上是一个比较简单的HTTPS流程，详细的可以参考文末的引用。
参考资料：
[1] 数字证书应用综合揭秘
[2] SSL/TLS协议运行机制的概述
[3] 图解SSL/TLS协议
[4] 《图解HTTP》