钥匙也就是 密钥（key） ，未加密的消息叫做 明文 （plain text/clear text） ，加密后的内容叫做 密文（cipher text） ，通过密钥解密出原文的过程叫做 解密（decrypt） ，而加解密的整个过程就是 加密算法 。
由于 HTTPS、TLS 都运行在计算机上，所以“密钥”就是一长串的数字，但约定俗成的度量单位是“位”（bit），而不是“字节”（byte）。比如，说密钥长度是 128，就是 16 字节的二进制串，密钥长度 1024，就是 128 字节的二进制串。
加密算法通常有两大类：对称加密和非对称加密。
对称加密
加密和解密使用的密钥都是同一个，是 “对称的”。双方只要保证不会有泄露其他人知道这个密钥，通信就具有机密性。
对称加密算法常见的有 RC4、DES、3DES、AES、ChaCha20 等，但前三种算法都被认为是不安全的，通常都禁止使用，目前常用的只有 AES 和 ChaCha20。
AES 的意思是“高级加密标准”（Advanced Encryption Standard），密钥长度可以是 128、192 或 256。它是 DES 算法的替代者，安全强度很高，性能也很好，而且有的硬件还会做特殊优化，所以非常流行，是应用最广泛的对称加密算法。
加密分组模式
对称算法还有一个 “分组模式”的概念，目的是通过算法用固定长度的密钥加密任意长度的明文。
最新的分组模式被称为 AEAD（Authenticated Encryption with Associated Data），在加密的同时增加了认证的功能，常用的是 GCM、CCM 和 Poly1305。
非对称加密
有对称加密，为何还搞出一个非对称加密呢？
对称加密确实解决了机密性，只有相关的人才能读取出信息。但是最大的问题是：如何安全的把密钥传递对方，专业术语 “ 密钥交换 ”。
这个很容易理解，对称加密的密钥在飞鸽传书过程中被打鸟的敌军捕获窃取，那么就能随意加解密收发作战密报数据了，诸葛亮的密报没有机密可言。
所以非对称加密诞生了。
由两个密钥组成，分别是 公钥（public key） 和 “ 私钥（private key） ”，两个密钥是不一样的，这也就是不对称的由来，公钥可以任何人使用，私钥则自己保密。
这里需要注意的是： 公钥和私钥都可以用来加密解密，公钥加密的密文只能用私钥解密，反之亦然。
服务端保存私钥，在互联网上分发公钥，当访问服务器网站的时候使用授予的公钥加密明文即可，服务端则使用对应的私钥来解密。敌军没有 私钥 也就无法破解密文了。
TLS 中常见的加密算法有 DH、RSA、ECC、DSA 等。其中的 RSA 最常用，它的安全性基于“ 整数分解 ”的数学难题，使用两个超大素数的乘积作为生成密钥的材料，想要从公钥推算出私钥是非常困难的。
ECC（Elliptic Curve Cryptography）是非对称加密里的“后起之秀”，它基于“ 椭圆曲线离散对数 ”的数学难题，使用特定的曲线方程和基点生成公钥和私钥，子算法 ECDHE 用于密钥交换，ECDSA 用于数字签名。
比起 RSA，ECC 在安全强度和性能上都有明显的优势。160 位的 ECC 相当于 1024 位的 RSA，而 224 位的 ECC 则相当于 2048 位的 RSA。因为密钥短，所以相应的计算量、消耗的内存和带宽也就少，加密解密的性能就上去了，对于现在的移动互联网非常有吸引力。
现在我们为了机密性从对称加密到非对称加密，而非对称加密还解决了密钥交换不安全的问题。那么是否可以直接使用非对称加密来实现机密性呢？
答案是否定的！
因为非对称加密运算速度比较慢。所以需要两者结合，混合模式实现机密性问题，同时又有很好的性能。
加密流程如下所示：
-
先创建一个随机数的对称加密密钥， 会话密钥（session key） ；
-
使用 会话密钥 加密需要传输的明文消息，因为对称加密性能较好，接着再使用非对称加密的公钥对 会话密钥 加密，因为会话密钥很短，通常只有 16 字节或 32 字节，所以加密也不会太慢。 这里主要就是解决了非对称加密的性能问题，同时实现了会话密钥的机密交换。
-
另一方接收到密文后使用非对称加密的 私钥 解密出上一步加密的 会话密钥 ，接着使用 会话密钥 解密出加密的消息明文。
总结一下就是使用非对称加密算法来加密会话密钥，使用对称加密算法来加密消息明文，接收方则使用非对称加密算法的私钥解密出会话密钥，再利用会话密钥解密消息密文。
这样混合加密就解决了对称加密算法的密钥交换问题，而且安全和性能兼顾，完美地实现了机密性。
后面还有完整性、身份认证、不可否认等特性没有实现，所以现在的通信还不是绝对安全。
摘要算法与完整性
摘要算法的主要目的就是实现完整性，通过常见的 散列函数、哈希函数 实现。
我们可以简单理解成这事一种特殊的压缩算法，将任意长度的明文数据处理成固定长度、又是独一无二的“ 摘要 ”字符串，就是该数据的指纹。
同时摘要算法是单向加密算法，没有密钥，加密后的数据也无法解密，也就是不能从“摘要”推导出明文。
比如我们听过或者用过的 MD5（Message-Digest 5） 、 SHA-1（Secure Hash Algorithm 1） ，它们就是最常用的两个摘要算法，能够生成 16 字节和 20 字节长度的数字摘要。
完整性实现
有了摘要算法生成的数字摘要，那么我们只需要在明文数据附上对应的摘要，就能保证数据的完整性。
但是由于摘要算法不具有机密性，不能明文传输，否则黑客可以修改消息后把摘要也一起改了，网站还是鉴别不出完整性。
所以完整性还是要建立在机密性上，我们结合之前提到的混合加密使用 ”会话密钥“ 加密明文消息 + 摘要，这样的话黑客也就无法得到明文，无法做修改了。这里有个专业术语叫“哈希消息认证码（HMAC）”。
比如诸葛亮使用上面提到的混合加密过程给关二爷发消息：“明天攻城” + “SHA-2 摘要”，关二爷收到后使用密钥将解密出来的会话密钥解密出明文消息，同时对明文消息使用解密出来的摘要算法进行摘要计算，接着比对两份“摘要”字符串是否一致，如果一致就说明消息完整可信，没有被敌军修改过。
消息被修改是很危险的，要以史为鉴，比如赵高与李斯伪造遗诏，直接把扶苏给送西天了，这太可怕了。
总结下就是通过摘要比对防止篡改，同时利用混合加密实现密文与摘要的安全传输。
数字签名和 CA
到这里已经很安全了，但是还是有漏洞，就是通信的两头。黑客可以伪装成网站来窃取信息。而反过来，他也可以伪装成你，向网站发送支付、转账等消息，网站没有办法确认你的身份，钱可能就这么被偷走了。
现在如何实现身份认证呢？
现实生活中，解决身份认证的手段是签名和印章，只要在纸上写下签名或者盖个章，就能够证明这份文件确实是由本人而不是其他人发出的。
非对称加密依然可以解决此问题，只不过跟之前反过来用，使用私钥再加上摘要算法，就能够实现“ 数字签名 ”，同时实现“身份认证”和“不可否认”。
就是把公钥私钥的用法反过来，之前是公钥加密、私钥解密，现在是私钥加密、公钥解密。但又因为非对称加密效率太低，所以私钥只加密原文的摘要，这样运算量就小的多，而且得到的数字签名也很小，方便保管和传输。
重点就是使用非对称加密的“私钥”加密原文的摘要，对方则使用非对称加密的公钥解密出摘要，再比对解密出的原文通过摘要算法计算摘要与解密出的摘要比对是否一致。这样就能像签署文件一样证明消息确实是你发送的。
只要你和网站互相交换公钥，就可以用“签名”和“验签”来确认消息的真实性，因为私钥保密，黑客不能伪造签名，就能够保证通信双方的身份。
CA
到这里似乎已经大功告成，可惜还不是。
综合使用对称加密、非对称加密和摘要算法，我们已经实现了安全的四大特性，是不是已经完美了呢？
不是的，这里还有一个“ 公钥的信任 ”问题。因为谁都可以发布公钥，我们还缺少防止黑客伪造公钥的手段，也就是说，怎么来判断这个公钥就是你或者张三丰的公钥呢？
这个“第三方”就是我们常说的 CA （Certificate Authority，证书认证机构）。它就像网络世界里的公安局、教育部、公证中心，具有极高的可信度，由它来给各个公钥签名，用自身的信誉来保证公钥无法伪造，是可信的。
CA 对公钥的签名认证也是有格式的，不是简单地把公钥绑定在持有者身份上就完事了，还要包含序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“ 数字证书 ”（Certificate）。
OpenSSL
它是一个著名的开源密码学程序库和工具包，几乎支持所有公开的加密算法和协议，已经成为了事实上的标准，许多应用软件都会使用它作为底层库来实现 TLS 功能，包括常用的 Web 服务器 Apache、Nginx 等。
由于 OpenSSL 是开源的，所以它还有一些代码分支，比如 Google 的 BoringSSL、OpenBSD 的 LibreSSL，这些分支在 OpenSSL 的基础上删除了一些老旧代码，也增加了一些新特性，虽然背后有“大金主”，但离取代 OpenSSL 还差得很远。
总结下就是： OpenSSL 是著名的开源密码学工具包，是 SSL/TLS 的具体实现。
迁移 HTTPS 必要性
如果你做移动应用开发的话，那么就一定知道，Apple、Android、某信等开发平台在 2017 年就相继发出通知，要求所有的应用必须使用 HTTPS 连接，禁止不安全的 HTTP。
在台式机上，主流的浏览器 Chrome、Firefox 等也早就开始“强推”HTTPS，把 HTTP 站点打上“不安全”的标签，给用户以“心理压力”。
Google 等搜索巨头还利用自身的“话语权”优势，降低 HTTP 站点的排名，而给 HTTPS 更大的权重，力图让网民只访问到 HTTPS 网站。
这些手段都逐渐“挤压”了纯明文 HTTP 的生存空间，“迁移到 HTTPS”已经不是“要不要做”的问题，而是“要怎么做”的问题了。HTTPS 的大潮无法阻挡，如果还是死守着 HTTP，那么无疑会被冲刷到互联网的角落里。
顾虑
阻碍 HTTPS 实施的因素还有一些这样、那样的顾虑，我总结出了三个比较流行的观点：“慢、贵、难”。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）
文末
我将这三次阿里面试的题目全部分专题整理出来，并附带上详细的答案解析，生成了一份PDF文档
- 第一个要分享给大家的就是算法和数据结构
- 第二个就是数据库的高频知识点与性能优化
- 第三个则是并发编程（72个知识点学习）
- 最后一个是各大JAVA架构专题的面试点+解析+我的一些学习的书籍资料
还有更多的Redis、MySQL、JVM、Kafka、微服务、Spring全家桶等学习笔记这里就不一一列举出来
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
是并发编程（72个知识点学习）**
[外链图片转存中…(img-7s2gx1N8-1712999864387)]
- 最后一个是各大JAVA架构专题的面试点+解析+我的一些学习的书籍资料
[外链图片转存中…(img-Cl59Y3y3-1712999864387)]
还有更多的Redis、MySQL、JVM、Kafka、微服务、Spring全家桶等学习笔记这里就不一一列举出来
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
232
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
