Shell / Bash算法
Linux 基础：HTTPS 原理与加密机制详解
HTTPS 是一种基于 HTTP 协议并引入加密层（SSL/TLS）的应用层协议。由于 HTTP 明文传输易受中间人攻击和篡改，HTTPS 通过对称加密与非对称加密结合的方式保障数据安全。文章介绍了对称加密、非对称加密及数据摘要的概念，详细阐述了通过数字证书验证公钥权威性以防止中间人攻击的完整流程，确保通信双方安全协商密钥并进行加密传输。
HTTPS 是一种基于 HTTP 协议并引入加密层（SSL/TLS）的应用层协议。由于 HTTP 明文传输易受中间人攻击和篡改，HTTPS 通过对称加密与非对称加密结合的方式保障数据安全。文章介绍了对称加密、非对称加密及数据摘要的概念，详细阐述了通过数字证书验证公钥权威性以防止中间人攻击的完整流程，确保通信双方安全协商密钥并进行加密传输。
本文从 HTTPS 是什么、为什么需要 HTTPS 的角度，基于 HTTP 协议认识 HTTPS，介绍加密原理，包括对称加密和非对称加密，引出五种不同的通信方加密方式及证书相关概念。
HTTPS 也是一个应用层协议。它是在 HTTP 协议的基础上引入了一个加密层，可以理解为 SSL+TLS+HTTP 构成。
由于 HTTP 的内容是明文传输的，明文数据会经过路由器、WiFi 热点、通信服务运营商、代理服务器等多个物理节点。如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击。因此我们需要对信息进行加密。
早期的 HTTP 在网络中明文传递，是暴露的，能被修改。
其中：
在这个加密和解密的过程中，往往需要一个或者多个中间的数据辅助进行这个过程，这样的数据称为密钥（正确发音 yuè 四声，不过大家平时都读作 yào 四声）。
因此：
HTTPS 就是在 HTTP 的基础上进行了加密，进一步来保证用户的信息安全。
采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密。
常见对称加密算法（了解）：DES、3DES、AES、TDEA、Blowfish、RC2 等。 特点：算法公开、计算量小、加密速度快、加密效率高。
因此：
我们只需要记住：加密密钥和解密密钥是同一把，这在某种意义上成为了它的缺点。
一个简单的对称加密：按位异或。
假设明文 a=1234，密钥 key = 8888，则加密 a ^ key 得到的密文 b 为 9834，然后针对密文 9834 再次进行运算 b ^ key，得到的就是原来的明文 1234。（对于字符串的对称加密也是同理，每一个字符都可以表示成一个数字）。当然，按位异或只是最简单的对称加密，HTTPS 中并不是使用按位异或。
需要两个密钥来进行加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。
常见非对称加密算法：RSA, DSA, ECDSA。 特点：算法强度复杂、安全性依赖于算法与密钥，但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。 最大的缺点就是运算速度非常慢，比对称加密要慢很多。
因此：
这里只需要记住：公钥加密只有私钥解开，私钥加密只有公钥解开。
数字指纹（数据摘要），其基本原理是利用单向散列函数（Hash 函数）对信息进行运算，生成一串固定长度的数字摘要。数字指纹并不是一种加密机制，但可以用来判断数据有没有被篡改。
摘要常见算法：有 MD5、SHA1、SHA256、SHA512 等，算法把无限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）。 摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常用来进行数据对比，比如数据库管理使用摘要。
也就是我们只使用一把密钥进行通信。
理想情况：
实际情况：
这种理想上被中间人截取的也只能是密文，无利用价值，但是服务端和每个客户端都要有个密钥来维护，这样就比较麻烦，因此一般采取的是先发送密钥进行协商，但是这样就被中间人获取密钥了，因此这种方案是不可行的。
因此就导致了这样：
服务端发送信息前提是先要和浏览器协商（把公钥发给它），然后用私钥加密，给浏览器，这样信息就暴露了（服务器到浏览器的信息暴露），但是浏览器拿到后，进行发送用公钥加密（只能私钥解密），此时无法暴露，服务器就能正常收到信息。
比如：
交换公钥，公钥加密，私钥解密。
它们俩互相交换了公钥（用于加密），有没有可能中间人也用公钥进行加密然后比如从客户端发给服务端，这样服务端也就分不清了或者中间人用自己的公钥给客户端，然后进行信息窃取。
总结：
因为非对称加密效率低，而且还有安全问题。
也就是服务端先把公钥给客户端，客户端用它进行对称密钥加密然后给服务端（中间人无私钥，无法解密），最后他俩就用这个对称公钥进行加密。
过程如图所示：
这样看似是没有毛病的，但是有没有可能中间人把自己的公钥 m 给 client，然后不就得到了这个被 m 加密的 x 了，然后再用 s 进行加密给服务端这个 x，之后 s 与 c 用 x 通信不就被中间人掌握了吗。
结局就成了这样：
因此：
关键问题还是防止中间人攻击，也就是如何确保 client 收到的公钥来自 server 而不是中间人呢？
这种方式的前两次非对称加密都是为了保证最后一次对称加密的安全性。 证书 = 签名 + 明文
服务端在使用 HTTPS 前，需要向 CA 机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性。
下面看一下申请证书过程图：
这里需要记住：
那么此时浏览器拿到证书如何核对有没有在 server 与 client 传播过程中被中间人修改呢？
CA 机构在形成证书的时候会拿着私钥对明文信息散列后的摘要进行加密作为签名。然后当客户端收到证书后会拿着 CA 公钥对签名解密拿到的数据和明文信息散列后进行对比；如果相同就证明没有被修改，拿着公钥进行传递对称密钥。被修改了就警告。保证了 client 一定拿到 server 的公钥。
如图：
但是如果中间人修改 server 发给 client 的证书的明文/签名/或者整体替换呢（中间人如果要想成功传递自己的秘钥必须修改签名）？
中间人动机：
但是，均行不通。
永远记住：中间人没有 CA 私钥，所以对任何证书都无法进行合法修改，包括自己的。
因此总结： 中间人无法修改证书和伪造新的证书。
因此，它来了。
这里可以理解成：
首先进证书申请 + 客户端验证证书（第一次非对称加密以及解密）；接着就是 client 拿到对应的 server 的公钥，然后进行传递接下来进行非对称加密的秘钥，服务端然后拿着自己的私钥进行解密拿到（第二次非对称加密以及解密）；接着就是用这个非对称秘钥进行通信了（非对称加密及解密）。
也就是这样：
注意：这里的易混点是签名和解签名只能用 CA 的私钥和公钥；而不是服务器的私钥公钥（过程中服务器会泄露公钥但私钥不会泄露）。
下面看张更加详细的图：
详细步骤：
超详细大白话叙述过程：
首先服务器拿着相关信息（域名，csr，明文信息等），然后生产对应的私钥（自己保存），公钥（交给 CA）然后向 CA 申请证书，ca 检查严格审核后，拿着自己的专属私钥进行对明文散列后数据签名，接着交给 server，最后 server 把证书给 client，client 拿着自己内置信任的 CA 机构的公钥容纳后进行解密签名看是否合法（明文散列是否相同，域名等是否匹配），不合格就发出警告（上报，或者浏览器阻止用户访问等），合格的话就拿到对应服务器的公钥，自己产生对称秘钥，然后发给服务端（中间人稚嫩获得密文，无法解密），然后服务端解密后，他俩就利用对称秘钥进行通信了。
总结： 这一切的目的就是保证这个对称秘钥通信的时候是安全的。
为什么要进行签名加密：
为什么明文不直接加密而是先生成摘要呢：
如何成为中间人：
可以看到有很多信任的证书，点击可以看到公钥等信息：
接下来点击安全选项：
首先点击浏览器对应设置：
通过本篇对 HTTPS 的基础认识，建立了大致的了解，知道了它背后的原理等。此次学习虽然是大致的，但是也看到了 HTTPS 背后的基本原理，为以后对它更加深入的学习奠定了基础。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML转Markdown在线工具，online
通过删除不必要的空白来缩小和压缩JSON。 在线工具，JSON 压缩在线工具，online