主要观点总结
文章介绍了「芋道快速开发平台」知识星球的加入方式，以及该星球提供的部分资料，如《项目实战（视频）》、《互联网高频面试题》等。同时，还介绍了一个开源项目，提供的功能包括RBAC权限、SaaS多租户、数据权限等，并给出了项目的GitHub地址。接着，文章讨论了对称加密和非对称加密的概念，以及数字签名、HTTPS和CA Gateway网关的过滤器链等。最后，文章展示了如何对自己的路径传输设定数字签名，以及如何实现URL的动态加密。
关键观点总结
关键观点1: 「芋道快速开发平台」知识星球的加入方式
通过扫描二维码加入星球，获取项目实战、面试招聘、源码解析、学习路线等内容。
关键观点2: 开源项目的功能介绍
项目提供的功能包括RBAC权限、SaaS多租户、数据权限、工作流、三方登录、支付、短信、商城等，并给出了GitHub地址。
关键观点3: 对称加密和非对称加密的概念
对称加密是指加密和解密使用相同的密钥，非对称加密则是加密和解密使用不同的密钥。
关键观点4: 数字签名、HTTPS和CA Gateway网关的过滤器链
数字签名用于验证数据的完整性和非否认性，HTTPS和CA Gateway网关的过滤器链则保证了数据传输的安全。
关键观点5: 如何对自己的路径传输设定数字签名
介绍了使用RSA和AES实现数字签名，以及如何实现URL的动态加密。
正文
：接收方使用私钥对加密数据进行解密，得到原始数据。
结合使用：
在实际应用中，对称加密和非对称加密通常会结合使用以达到安全和效率的平衡。例如：
-
-
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
-
项目地址：https://github.com/YunaiV/yudao-cloud
-
视频教程：https://doc.iocoder.cn/video/
再上面我们了解了RSA对称加密，那么当我们进行数据交换的时候，如下：
假设有AB两个人，假设前面他们已经交换完毕了公钥。
那么此时当A使用B的公钥加密原始数据然后发送数据给B的时候，它可以再数据的后面再携带上一个原始数据hash计算之后得到的hash值，然后用自己的私钥进行加密。
A将数据发送到B之后，由于数据使用的是B的公钥加密，B可以用私钥解密之后，得到A发送消息的原本内容，然后，B可以使用A的公钥对额外的数字签名进行校验，因为它假设这个数据是A发送的，那么用A的公钥就应该可以解密成功，所以如果数据解密成功之后与A发送的原始消息经过一样的Hash运算之后相等，那么说明没有被篡改，而如果不一致，那么就说明被篡改了。因为第三方是不知道A的私钥信息的，所以他是用自己的私钥去加密，得到的hash会与A进行hash之后的值不同，从而判断数据被篡改了。
https其实不是一个单独的协议，而是数据传输的时候使用TLS/SSL进行了加密而已。而TLS就是一个非常典型的非对称加密，其兼顾了AES和RSA的安全性和速度。
上面我们已经聊完了一个加密数据的交换过程，那么如果有些人就是伪造了一些域名让你去访问怎么办呢？
HTTPS (HTTP Secure) 是一个安全的 HTTP 通道，它通过 SSL/TLS 协议来保证数据的安全传输。在 HTTPS 请求的过程中，证书颁发机构 (CA, Certificate Authority) 扮演了重要的角色。以下是 CA 在保证 HTTPS 请求过程中数据安全交换的方式：
-
证书颁发
:CA 为服务器颁发一个数字证书。这个证书包含了服务器的公钥和一些识别服务器身份的信息。数字证书是由 CA 签名的，以验证证书的真实性和完整性。
-
建立安全连接
:当客户端第一次连接到服务器时，服务器会发送其数字证书给客户端。客户端会验证数字证书的合法性，比如检查证书是否由一个受信任的 CA 签名，检查证书是否在有效期内等。一旦证书验证通过，客户端就能确认它是与正确的服务器进行通信，而不是被中间人攻击。
-
密钥交换
:客户端和服务器会使用 SSL/TLS 协议中的密钥交换机制来协商一个会话密钥（通常是一个对称密钥）。一种常见的方法是客户端生成一个随机的对称密钥，然后用服务器的公钥加密它，再发送给服务器。服务器用自己的私钥解密得到对称密钥。
-
数据加密和传输
:一旦会话密钥被协商好，客户端和服务器就会用这个密钥来加密和解密传输的数据。这样，即使数据在传输过程中被截获，攻击者也无法解读数据的内容，因为他们没有会话密钥。
-
完整性校验
:SSL/TLS 协议还提供了数据完整性校验。它会为传输的数据生成一个 MAC (Message Authentication Code)，以确保数据在传输过程中没有被篡改。
其实前面的第一和第二随机数都是正常传输，预主密钥的得到就是使用RSA了，此时只有客户端和服务端知道预主密钥，之后，对第一和第二随机数使用预主密钥的加密，就可以得到会话密钥，此时加密交互完成。
并且会话密钥只应用在当前会话，每个会话都会新生成一个，所以安全性大大增加。
只有前面的得到预主密钥的过程用RSA，其他地方都是AES，因为，非对称实在太慢了。
我们知道，我们可以再Gateway网关中自定义过滤器，并且实现Ordered接口来对过滤器的执行顺序进行排序。如下图我实现了三个自定义的全局过滤器。
并且，当你实现全局过滤器接口的时候，你必须实现如下方法
public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain)
其中exchange参数非常重要，他就是你的请求以及对你请求的响应。而chain就是上面的过滤器链条。
而我们的过滤器链的作用，其实就是对request和response这两个重要的类进行操作。
比如我可以使用exchange.mutate方法来对request和response进行修改。
exchange = exchange.mutate().request(build -> {
try {
build.uri(
new URI("http://localhost:8080/v1/product?productId=1"))
.build();
} catch (URISyntaxException e) {
throw new RuntimeException(e);
}
}
).build();
如下是我修改request之前的请求体内容。
如下就是我修改URI之后的request请求体的内容。
在这里我们把这个reqeust给他修改有着重大意义，这意味着只要对加密后的数据进行解密后，去修改这个request中的内容，我们就能再一次成功的将我们的请求路由到我们指定的路径。
而之后，我们最终路由到的请求路径位置，保存在了DefaultServerWebExchange的attributes中。
在这里请求完成了最终的处理，然后进行转发，发送到对应的处理类去处理。
这时候我们看提供远程服务调用的类的调用栈即可。
上面我们已经聊到了，先使用RSA的方式传递对称密钥，然后之后的请求使用AES来进行加密解密。这样子既保证了安全性也保证了请求的速度。
我就按照上面的说法，简单的实现了一个数字签名，大概方式如下：
公钥获取：
客户端首先通过一个特定的接口从服务器获取RSA公钥。
对称密钥加密：
客户端生成一个随机的对称密钥，然后使用服务器的RSA公钥对这个对称密钥进行加密。
发送加密的对称密钥：
客户端将加密后的对称密钥发送到服务器。
对称密钥解密：
服务器使用自己的RSA私钥解密客户端发送的加密对称密钥，从而得到原始的对称密钥。
加密通信：
从现在开始，客户端和服务器都会使用这个对称密钥来加密和解密他们之间的通信。这包括URL的动态加密、请求和响应的加密解密，以及数字签名的验证等。
数字签名：
为了确保数据的完整性和非否认性，客户端和/或服务器可以使用对称密钥来生成和验证数字签名。
这样，双方都可以确信接收到的数据没有被篡改，并且确实来自预期的发送方。
URL动态加密：
使用对称密钥对URL进行动态加密，以保护URL中的敏感信息，并防止未经授权的访问。
这个流程确保了客户端和服务器之间的通信安全，防止数据被截获或篡改，同时也提供了一个有效的机制来验证通信双方的身份。
具体流程如下：
我们首先需要做的第一步是提供一个接口让前端客户端去访问，
并且获得到我们的公开的RSA公钥，
然后前端拿到这个RSA公钥之后加密自己的对称密钥，
然后再一次发送一个请求，
这个请求携带的是通过RSA公钥加密过后的对称密钥，
然后服务端收到这个对称密钥之后，
通过RSA私钥解密可以得到原本的前端发送的对称密钥。
