Shell / Bash算法
HTTPS 加密原理、数字指纹与 CA 认证详解
HTTPS 协议通过在应用层和传输层之间增加 SSL/TLS 加密层保障数据安全。文章对比了 HTTP 与 HTTPS 的区别，阐述了对称加密与非对称加密的原理及优缺点。针对密钥交换中的中间人攻击问题，提出了非对称加密结合对称加密的方案，并引入 CA 认证机制验证公钥合法性。最终详解了 HTTPS 完整工作流程，包括证书验证、密钥协商及数据传输加密过程，确保通信安全。
HTTPS 协议通过在应用层和传输层之间增加 SSL/TLS 加密层保障数据安全。文章对比了 HTTP 与 HTTPS 的区别，阐述了对称加密与非对称加密的原理及优缺点。针对密钥交换中的中间人攻击问题，提出了非对称加密结合对称加密的方案，并引入 CA 认证机制验证公钥合法性。最终详解了 HTTPS 完整工作流程，包括证书验证、密钥协商及数据传输加密过程，确保通信安全。
HTTP 协议无论是使用 GET 还是 POST 方法传输数据，都是以明文形式进行传输，这意味着传输过程中的数据很容易被拦截或篡改。
HTTPS 协议则通过在应用层和传输层之间增加一个加密层（SSL/TLS），为数据传输提供安全保障。
HTTPS 的工作原理如下：
HTTPS 也是一个应用层协议。只是在 HTTP 协议的基础上引入了一个加密层。
加密方式的定义？
web 组织定义的
站在一个黑客角度
HTTP 与 HTTPS 在工作方式和应用场景上有显著区别：
加密是将明文数据通过一定的规则转换成密文的过程，从而保证数据在传输过程中不会被非法获取或篡改。
以下是加密相关的术语：
数字签名是对摘要进行加密后的结果，用来确保数据的完整性和身份验证。
通过非对称加密技术，使用私钥对摘要加密，接收方用公钥解密，经过比对，可以验证数据是否被篡改。
既然要保证数据安全，就需要进行'加密'。 网络传输中不再直接传输明文了，而是加密之后的'密文'。 加密的方式有很多，但是整体可以分成两大类：对称加密和非对称加密
其实在网络通信，我们要解决的是如下问题：
如果通信双方都各自持有同一个密钥 X，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）
服务器同一时刻其实是给很多客户端提供服务的。这么多客户端，每个人用的秘钥都必须是不同的 (如果是相同那密钥就太容易扩散了，黑客就也能拿到了)。因此服务器就需要维护每个客户端和每个密钥之间的关联关系，这也是个很麻烦的事情~
缺点：
上面还不是最重要的，最重要的是最开始的时候我们怎么保证客户端和服务器看到的是同一个密钥。
这不就是鸡生蛋还是蛋生鸡的问题吗？所以纯纯使用对称加密是不行的！
通信之前先得交换密钥，鉴于非对称加密的机制，用公钥和私钥都可以加密，但用公钥加密就要使用私钥解密，使用私钥加密就要使用公钥解密，所以可以尝试如下图操作：
缺点：
现在只能保证从 C->S 的安全性 (暂时的安全)，没有办法解决 S->C 的安全性。 没事我们在提第三种方案。
缺点：
这种方案通过非对称加密进行密钥交换，之后的数据传输使用对称加密，从而兼顾了安全性和效率。具体流程如下：
前半部分采用非对称加密：交换密钥，后半部分采用对称加密：双方不存在了安全问题。既安全，又高效。
但真的没有问题了吗？
方案二、方案三、方案四都存在一个问题，如果最开始，中间人就已经开始攻击了呢？
中间人攻击是指在客户端与服务器通信的过程中，攻击者通过劫持并篡改数据进行窃听或伪造。
在方案 2/3/4 中，客户端获取到公钥 S 之后，客户端形成的对称秘钥 C，然后用服务端给客户端的公钥 S 对 C 进加密，中间人即使窃取到了数据，此时中间人确实无法解出客户端形成的密钥 C，因为只有服务器有私钥 S'。
但是中间人的攻击，如果在最开始握手协商的时候就进行了，那就不一定了，如果 M 在请求公钥后就已经成功成为了中间人
上面的攻击方案，同样适用于方案 2、方案 3
问题本质出在哪里了呢？ 服务器返回公钥的时候，被中间人窃取并替换了&&客户端没有辨别公钥是否合法的能力
下面要围绕**客户端能够具有辨别服务器发过来的公钥的合法性！**来解决问题，避免公钥被替换
为了防止这种攻击，HTTPS 引入了证书认证机制。
为了防止中间人篡改公钥，HTTPS 采用了数字证书认证机制。CA（Certificate Authority）作为权威的第三方机构，为服务器颁发数字证书，保证公钥的真实性。证书的验证流程如下：
证书可以理解成是一个结构化的字符串，里面包含了以下信息：证书发布机构、证书有效期、公钥、证书所有者、签名等等
客户端能够具有辨别服务器发过来的公钥的合法性! 我们说是通过证书来进行甄别的，那证书如何做到的呢？
签名：
验证：
通过验证可以确保：数据和签名的证书不被更改啦
首先说一下，CA 为了签发证书，CA 也有自己的 CA 公钥，CA 私钥。
因为我们使用 CA 的私钥形成数据签名，所以只有 CA 能形成可信任的证书！(CA 私钥只在 CA)
实际验证场景：
⭕中间人有没有可能篡改该证书？
⭕中间人整个掉包证书？
证书掉包：
如果证书中的域名与实际服务不符，客户端同样会拒绝接受该证书。
结论：
为什么摘要内容在网络传输的时候一定要加密形成签名？
由于这些特性，如果两个字符串具有相同的 MD5 值，则可以认为这两个字符串是相同的。这使得 MD5 可以用来验证数据完整性。
理解证书篡改的判定过程：
BC4B2A76B9719D91。BDBD6F9CF51F2FD8。存在的问题：
解决方案：
为什么签名不直接加密，而是要先 hash 形成摘要？
如何成为中间人？
左侧都是客户端做的事情，右侧都是服务器做的事情。
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