松哥最近在和小伙伴们连载 gRPC，如何确保 gRPC 通信的安全性？这就波及到 TSL 了，然而思考到可能有小伙伴对加密连贯这一整套计划比拟生疏，因而咱们明天先用一篇文章跟大家捋分明这些概念，概念搞明确了，再来看 TSL+gRPC 就很容易了。
1. HTTP 的问题
HTTP 协定是超文本传输协定（Hyper Text Transfer Protocol）的缩写，它是从 WEB 服务器传输超文本标记语言 HTML 到本地浏览器的传送协定。HTTP 设计之初是为了提供一种公布和接管 HTML 页面的办法，时至今日，它的作用曾经不仅仅于此了。
对于咱们 Java 工程师而言，HTTP 应该算是再相熟不过的货色了，目前 HTTP 有多个版本，应用较多的是 HTTP/1.1 版本。
然而 HTTP 协定有一个缺点那就是它是通过明文传输数据的，用户通过 HTTP 协定传输的内容很容易被歹意拦挡，并且黑客能够伪装成服务端，向用户传送谬误的信息，并且能轻易获取用户的隐衷信息，而这些操作用户是齐全无感知的。
因为存在这样的安全隐患，当初小伙伴们见到的大部分网站都在逐渐转为 HTTPS，HTTP 网站会越来越少了。
2. HTTPS
HTTPS（HyperText Transfer Protocol Secure）中文译作超文本传输平安协定，这是一种通过计算机网络进行平安通信的传输协定。
HTTPS 实质上还是由 HTTP 进行通信，只是在 HTTP 协定和 TCP 层之间减少了一个 SSL 的平安传输协定。整个传输的加密过程都在新的平安层 SSL/TLS 中实现，而原来的 HTTP 层的传输流程放弃不变，这样就很好地兼容了旧的 HTTP 协定，也因循了 TCP/IP 协定族的分层思维。
通过 HTTPS，客户端能够确认服务端的身份，保证数据在传输过程中不被篡改，当咱们在本人的浏览器上与某一个网站建设 HTTPS 连贯的时候，满足如下状况能够示意这个服务端能够被信赖：
- 首先咱们的操作系统中装置了正确且受信赖的证书。咱们在 cmd 命令行中执行
certmgr.msc命令，能够查看操作系统曾经装置的证书列表。
- 浏览器自身正确实现了 HTTPS。
- 被拜访的网站提供了一个证书，这个证书是由一个操作系统所信赖的证书颁发机构签发的，操作系统所信赖的证书颁发机构个别都预装在操作系统中，通过第一步的形式能够查看。
- 被拜访的网站所提供的证书被胜利认证。
这里边波及到一些证书和协定的概念，接下来松哥和大家把整个过程捋一捋。
3. TLS/SSL
后面咱们提到，HTTPS 就是在 HTTP 的根底之上减少了 TLS/SSL，那么这两个货色该如何了解呢？
SSL/TLS 是一种明码通信计划，算是目前应用最宽泛的明码通信计划了。SSL 全称是 Secure Socket Layer，中文译作安全套接层，是 1994 年由 Netscape 公司设计的一套协定，并与 1995 年公布了 3.0 版本；TLS 全称是 Transport Layer Security，中文译作传输层平安，则是 IETF 在 SSL3.0 根底上设计的协定，实际上相当于 SSL 的后续版本，目前 TLS 先后迭代了 TLS 1.0、TLS 1.1、TLS 1.2 和 TLS 1.3，目前被宽泛应用的是 TLS 1.2 版本。
SSL/TLS 波及到了密码学中的对称加密、非对称加密、数字签名等等，算是密码学畛域里的集大成者了。
3.1 TLS
接下来咱们就来看看 TLS 如何确保 HTTP 平安。
为了确保客户端和服务端之间的数据安全，咱们很容易想到一种计划就是对传输的数据进行加密，没错，这是一个方法，事实上也是这么做的。
加密又分为两种：
- 对称加密
- 非对称加密
那么该应用哪一种呢？
对称加密，也就是加密密钥和解密密钥是同一个，当浏览器和服务端须要进行通信的时候，约定好一个密钥，而后应用这个密钥对发送的音讯进行加密，对方收到音讯之后再应用雷同的密钥对音讯进行解密。然而，在 B/S 架构的我的项目中，这种计划显然不适合，一个网站把本人的密钥通知全世界所有的浏览器，那加密和不加密还有区别吗？
有小伙伴可能又想到了不对称加密，不对称加密倒是个方法，因为不对称加密是有一个密钥对公钥和私钥，公钥能够公布出来通知所有人，私钥只有本人晓得。通信的时候，客户端首先应用公钥对音讯进行加密，服务端收到之后，再通过私钥对音讯进行解密，这看起来仿佛挺完满的。然而！！！非对称加密存在一个问题，就是非对称加密和解密相当耗时，通过这种形式解决加解密效率太低。
那怎么办？咱们能够将两者联合起来。
具体来说，就是这样：首先服务端会生成一个非对称加密的密钥对，私钥本人保留，公钥发送给客户端，客户端拿到这个公钥之后，再生成一个对称加密的密钥，而后把对称加密的密钥通过公钥进行加密，加密之后发送给服务端，服务端通过私钥进行解密，这样客户端和服务端就能够通过对称加密进行通信了。
事实上，TLS 大抵上的思路就是这样的。
不过下面这个计划还是有一个破绽，那就是服务端要通过明文传输的形式把公钥发送给客户端，这个过程还是不平安的，可能被人歹意截胡，那么这个问题该如何解决呢？
这就波及到另外一个概念叫做数字证书了。
3.2 CA
数字证书是一个 蕴含了指标网站各种信息如网站域名、证书有效期、签发机构、用于生成对称密钥的公钥、下级证书签发的签名等 的文件，通过数字证书咱们能够确认一个用户或者服务站点的身份。
理论场景中的数字证书是一系列的，造成了一个信赖链，信赖链的最顶端是 CA。
CA 是 Certificate Authority 的简写，它是一个负责发放和治理数字的证书的第三方权威机构。CA 的工作流程是这样的：
- CA 本人给本人颁发的用本人的私钥签名的证书称为根证书，根证书的私钥安全性至关重要，根证书的私钥都是被保留在离线计算机中，有严格的操作规章，每次须要应用时，会有专人将数据通过 USB 拷贝过来，操作完了当前，再将数据带进去（这个专指 CA 根证书的私钥）。
- 一个用户想要获取一个证书，首先本人得有一个密钥对，私钥本人留着，公钥以及其余信息发送给 CA，向 CA 提出申请，CA 判明用户的身份之后，会将这个公钥和用户的身份信息绑定，并且为绑定后的信息进行签名（签名是通过 CA 根证书的私钥进行的），最初将签名后的证书发给申请者。
- 一个用户想要鉴定一个证书的真伪，就通过 CA 的公钥对证书上的数字签名进行验证，验证通过，就认为这个这个证书是无效的。
下面这个流程中有一个重要前提，那就是 CA 受到大家所有人的信赖。
然而在实际操作中，咱们并不能间接去跟 CA 申请一个数字证书，因为全世界要认证的内容太多了，CA 搞不过去，而且频繁的找 CA 申请，还有可能导致私钥透露，这可就是一个大的劫难了。
那怎么办呢？实际操作中，咱们能够基于 CA 来构建一个信赖链。具体来说，步骤是这样：
- 首先咱们的手机、笔记本等操作系统中都预装了 CA 颁发的根证书，他们是所有信赖构建的基石，后面松哥曾经截图给大家看了 Windows 中预装的根证书了。
- 假如 CA 签发了一个证书 A，在这个过程中 CA 称为 Issuer，A 称为 Subject，假如 A 是一个受信赖的两头证书，曾经预装在咱们的操作系统中了。当初由 A 利用它本人的私钥给某一个网站签发了一个证书 B。
- 当初当咱们的电脑须要拜访该网站的时候，该网站就会给咱们发来一个证书 B，因为咱们的浏览器并不知道 B 证书是否非法，然而咱们的电脑上曾经预装了 A 证书，咱们能够从 A 证书中提取出 A 的公钥，而后利用 A 的公钥对 B 证书的签名进行验证（因为 B 证书的签名是 A 的私钥签的），如果验证通过了，就阐明 B 是非法的。
- 雷同的情理，B 也能够持续签发 C 证书，C 持续签发 D 证书，这样就造成了一个信赖链。
- 如果服务端的签名是 D 证书，那么一般来说，服务器返回给浏览器的就会蕴含 B、C、D 三个证书（因为 A 证书曾经在咱们的电脑上了），即便只返回 D 证书，浏览器也能够依据 D 书中的信息，主动下载到 B、C 两个证书而后进行验证。
松哥记得以前上大学的时候，在 12306 网站上买火车票，第一次拜访的时候必须要本人先手动装置一个根证书到零碎中，而后能力拜访。这就是因为过后 12306 所应用的证书的签发机构不被浏览器认可，相似于下面的第 3 步，12306 给我发了一个数字证书 B 回来，然而浏览器上没有适合的公钥对这个 B 证书进行验证，当我往本人的零碎上装置了 12306 给的证书之后，相当于我的电脑上有了一个证书 A，当初就能够对 B 证书进行验证了。
总结一下：
- CA 是一个权威的机构，是一个发证机关，CA 收回来的证书能够证实一个人或者组织的身份。
- 任何人都能够失去 CA 的证书（含公钥），用以验证 CA 所签发的证书。
- 每一个数字证书都是由下级证书的私钥来签发的，处于最顶层的就是 CA 签发的根证书了，这个根证书没有下级证书了，所以这个根证书实际上是由 CA 本人的私钥来签发的，这也叫做自签名，即 Self-Signed。
当咱们有了数字签名之后，就能够解决 3.1 大节最初提出的问题了。服务端将数字签名发给浏览器，浏览器利用零碎曾经内置的公钥验签，确认签名没问题，而后就提取进去数字签名中的公钥，开始协商对称加密的私钥了～
好啦，有了这些常识储备之后，下篇文章松哥来和大家聊一聊 TLS+gRPC 怎么玩！