用Rust手把手编写一个Proxy(代理), TLS加密通讯

rust,手把手,编写,一个,proxy,代理,tls,加密,通讯 · 浏览次数 : 58

小编点评

# Nginx证书文件pem及keykey文件 **包含以下内容** * n, e, d, p, q (RSA private key) * domain (SSL certificate domain name) * cert (SSL certificate file) * key (SSL private key file) **证书格式** * RSA PRIVATE KEY * PEM * CERTIFICATE **key格式** * PEM * CERTIFICATE **示例** **n, e, d, p, q (RSA private key)** ``` n: 1234567890 e: 1234567890 d: 1234567890 p: 1234567890 q: 1234567890 ``` **SSL证书 domain name** ``` domain: soft.wm-proxy.com ``` **SSL证书文件** ``` cert.pem ``` **SSL私钥文件** ``` key.pem ``` **使用** 在wmproxy中设置代理 ``` --proxy wmproxy --port 8091 --ts --cert cert.pem --key key.pem --domain domain.soft.wm-proxy.com ```

正文

用Rust手把手编写一个Proxy(代理), TLS加密通讯

项目 ++wmproxy++

gite: https://gitee.com/tickbh/wmproxy

github: https://github.com/tickbh/wmproxy

为什么选择TLS

了解TLS

安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。
该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。

TLS版本的历程

版本 发表年份 RFC文件 弃用年份 RFC链接
TLS1.0 1999年 RFC2246 2021年弃用 https://datatracker.ietf.org/doc/rfc2246/
TLS1.1 2006年 RFC4346 2021年弃用 https://datatracker.ietf.org/doc/rfc4346/
TLS1.2 2008年 RFC5246 正在使用 https://datatracker.ietf.org/doc/rfc5246/
TLS1.3 2018年 RFC8446 正在使用 https://datatracker.ietf.org/doc/rfc8446/

TLS协议的优势是与高层的应用层协议(如HTTP、FTP、Telnet等)无耦合。应用层协议能透明地运行在TLS协议之上,由TLS协议进行创建加密通道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密,从而保证通信的私密性。

我们此时正应用他与应用层完全不耦合,又经历20年的发展历程非常的完善和安全,完全可以信任。

sequenceDiagram Client->>Server: TLS协议版本、随机数、支持的加密套件和对应公钥A Server-)Server: 生成随机数B,根据信息生成密钥 Server-->>Client: 选用加密套件,服务端随机数,服务端证书 Server-->>Client: 使用的P、G、公钥B与签名 Server-->>Client: 握手报文的信息(服务端加密) Client-)Client: 验证证书,使用a、B计算出K,得到密钥 Client->>Server: 握手报文的信息(客户端加密) Client->>Server: 应用数据(客户端加密) Server-->>Client: 应用数据(服务端加密)

了解RSA算法

1. 算法原理

算法本身基于一个简单的数论知识:给出两个素数,很容易将它们相乘,然而给出它们的乘积,想得到这两个素数就显得尤为困难。如果能够解决大整数(比如几百位的整数)分解的快速方法,那么 RSA 算法将轻易被破解。

2.公钥私钥的生成
  1. 准备两个非常大的素数p和q(转化成二进制后1024位或者4096或者更大位数,位数越多越难破解);
  2. 计算出两个大素数的乘积n=pq;
  3. 同样的方法计算m=(p-1)(q-1),这里的m为n的欧拉函数
  4. 找到一个数e(1 < e < m),满足(e,m)的最大公约数为1,即互素
  5. 找到数字d,需满足ed mod m = 1,即余数为1
  6. 此时生成完毕,公钥为(n,e),私钥为(n, d)
3. RSA加密
对明文x,用公钥(n, e)对x加密,将x转换成数字,通过公式得出密文y
y = x^e mod n

4. RSA解密

对明文y,用私钥(n, d)对y解密
x = y^d mod n

5. 小数测试

取p=5,q=11,得到n=p*q=55
m=(p-1)(q-1) = 40
取e=3,根据ed mod m = 1,可取d=27
此时公钥(n, e)=(55, 3)
此时私钥(n, d)=(55, 27)
提供明文a = 14,用公钥加密则密文c = a ^ e mod n = 14 ^ 3 mod 55 = 49
解密密文b = 49,用私钥解密则明文d = b ^ d mod n = 49 ^ 27 mod 55 = 14

6. 性能分析

因为RSA用到了指数级的计算,位数又是至少1024位起的,所以计算量非常的庞大,所以RSA的算法效率并不高,所以TLS除一开始密文交换的时候用到RSA,后续均用得到的密文做对称加密以减少计算量,TLS1.3所用如下TLS_AES_128_GCM_SHA256TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_CCM_SHA256TLS_AES_128_CCM_8_SHA256等对称加密算法。

7. Nginx证书文件pem及key

key文件,即包含-----BEGIN RSA PRIVATE KEY-----的文件,这里面包含的信息有n, e, d, p, q等完整的RSA信息,也是保证安全最重要的信息,格式类似如下

RSAPrivateKey ::= SEQUENCE {
  version           Version,
  modulus           INTEGER,  -- n
  publicExponent    INTEGER,  -- e
  privateExponent   INTEGER,  -- d
  prime1            INTEGER,  -- p
  prime2            INTEGER,  -- q
  exponent1         INTEGER,  -- d mod (p-1)
  exponent2         INTEGER,  -- d mod (q-1)
  coefficient       INTEGER,  -- (inverse of q) mod p
  otherPrimeInfos   OtherPrimeInfos OPTIONAL
}

pem文件,包含了公钥信息(n, d)及证书链信息,可以知道谁签发的。

加密节点实现

角色说明,在wmproxy中存在两种角色,

  1. 末端的处理服务器
  2. 中间方只进行流量转发

关于TLS的参数有以下参数

pub struct Proxy {
    /// 连接服务端是否启用tls
    ts: bool,
    /// 接收客户端是否启用tls
    tc: bool,
    /// tls证书所用的域名
    domain: Option<String>,
    /// 公开的证书公钥文件
    cert: Option<String>,
    /// 隐私的证书私钥文件
    key: Option<String>,
}

因为加密存在可能的性能损耗,若在私有网络里不存在传输安全理论上可以不用开启加密传输。如果存在多个节点,前面节点已启用过加密,理论上后面节点也无需多次加密。

直接用https传输可能暴露什么?

因为客户端发起Client Hello的时候必须带上访问的domain,也就是网络的嗅探方虽然无法知道你访问的具体内容,但是可以知道你访问的网站列表。如:

启动二级代理
  1. 在本地启动代理
wmproxy -b 127.0.0.1 -p 8090 -S 127.0.0.1:8091 --ts

因为纯转发,所以在当前节点设置账号密码没有意义-S表示连接到的二级代理地址,有该参数则表示是中转代理,否则是末端代理。--ts表示连接父级代理的时候需要用加密的方式链接

  1. 在远程启动代理
wmproxy --user proxy --pass proxy -b 0.0.0.0 -p 8091 --tc

--tc表示接收子级代理的时候需要用加密的方式链接,可以--cert指定证书的公钥,--key指定证书的私钥,--domain指定证书的域名,如果不指定,则默认用自带的证书参数

至此通过代理访问的,我们已经没有办法得到真正的请求地址,只能得到代理发起的请求

源码说明

关于TLS依赖,选择的是rustlstokio-rustls
那么关于客户端的连接,那就有两种情况,一种是TcpStream,另一种是TlsStream<TcpStream>,我们的处理函数不确定传入的是哪种类型,所以此前的入参TcpStream全部改成泛型T,类似

async fn deal_stream<T>(&mut self, inbound: T) -> ProxyResult<()>
where T: AsyncRead + AsyncWrite + Unpin {
}

这样子只要可以异步读和写都可以成为入参的流。

如果存在tc参数,那么会将客户端转成TlsStream以便继续处理

if let Some(a) = accept.clone() {
    let inbound = a.accept(inbound).await;
    if let Ok(inbound) = inbound {
        // 获取的流跟正常内容一样读写, 在内部实现了自动加解密
        let _ = self.deal_stream(inbound).await;
    } else {
        println!("accept error = {:?}", inbound.err());
    }
} else {
    let _ = self.deal_stream(inbound).await;
};

客户端连接

let connector = TlsConnector::from(tls_client.unwrap());
let stream = TcpStream::connect(&server).await?;
// 这里的域名只为认证设置
let domain = rustls::ServerName::try_from(&*domain.unwrap_or("soft.wm-proxy.com".to_string()))
    .map_err(|_| io::Error::new(io::ErrorKind::InvalidInput, "invalid dnsname"))?;

if let Ok(mut outbound) = connector.connect(domain, stream).await {
    // connect 之后的流跟正常内容一样读写, 在内部实现了自动加解密
    let _ = tokio::io::copy_bidirectional(&mut inbound, &mut outbound).await?;
}

这里利用的是TLS与上层解藕,只要他参与握手完之后,完全按我们的通讯来定。

后续改进

现在每个请求都和代理服务端进行一次请求握手,当开启断开非常多的时候会比较耗性能,可以考虑共用一条socket然后内部做协议解析,会减少握手时间,只是在流量非常大的时候会出现某条请求耗光了所有的带宽。

与用Rust手把手编写一个Proxy(代理), TLS加密通讯相似的内容:

用Rust手把手编写一个Proxy(代理), TLS加密通讯

用Rust手把手编写一个Proxy(代理), TLS加密通讯 项目 ++wmproxy++ gite: https://gitee.com/tickbh/wmproxy github: https://github.com/tickbh/wmproxy 为什么选择TLS 了解TLS 安全传输层协议(

用Rust手把手编写一个Proxy(代理), 准备篇, 动手造轮子

用Rust手把手编写一个Proxy(代理), 准备篇, 动手造轮子 wmproxy 将实现http/https代理, socks5代理, 后续将实现websocket代理, 内外网穿透等, 会将实现过程分享出来, 希望感兴趣的可以一起参与参与 项目 ++wmproxy++ gite: https:/

用Rust手把手编写一个Proxy(代理), 动工

用Rust手把手编写一个Proxy(代理), 动工 项目 ++wmproxy++ gitee 传送门 github 传送门 设计流程图 flowchart LR A[客户端] -->|Http| B[代理端] --> C[代理服务端] --> D[服务端] B -->|直达| D A -->|Htt

用Rust手把手编写一个Proxy(代理), UDP绑定篇

用Rust手把手编写一个Proxy(代理), UDP绑定篇 项目 ++wmproxy++ gite: https://gitee.com/tickbh/wmproxy github: https://github.com/tickbh/wmproxy 了解UDP 特点 UDP是基于IP的简单协议,不

5. 用Rust手把手编写一个Proxy(代理), 通讯协议建立, 为内网穿透做准备

wmproxy, 通讯协议的定义, 粘包拆包的解决方案, 代理的网络的拓扑图, 协议的分类, 消息的包头, 消息类型的定义

10. 用Rust手把手编写一个wmproxy(代理,内网穿透等), HTTP内网穿透支持修改头信息

用Rust手把手编写一个wmproxy(代理,内网穿透等), HTTP内网穿透支持修改头信息项目 涉及HTTP1.1 chunked, http2, keep-alive

8. 用Rust手把手编写一个wmproxy(代理,内网穿透等), HTTP改造篇之HPACK原理

用Rust手把手编写一个wmproxy(代理,内网穿透等), HTTP改造篇之HPACK原理 项目 ++wmproxy++ gite: https://gitee.com/tickbh/wmproxy github: https://github.com/tickbh/wmproxy HTTP/2的

7. 用Rust手把手编写一个wmproxy(代理,内网穿透等), HTTP及TCP内网穿透原理及运行篇

用Rust手把手编写一个wmproxy(代理,内网穿透等), HTTP及TCP内网穿透原理及运行篇 项目 ++wmproxy++ gite: https://gitee.com/tickbh/wmproxy github: https://github.com/tickbh/wmproxy 内网、公

6. 用Rust手把手编写一个wmproxy(代理,内网穿透等), 通讯协议源码解读篇

用Rust手把手编写一个wmproxy(代理,内网穿透等), 通讯协议源码解读篇 项目 ++wmproxy++ gite: https://gitee.com/tickbh/wmproxy github: https://github.com/tickbh/wmproxy 事件模型的选取 OS线程,

12. 用Rust手把手编写一个wmproxy(代理,内网穿透等), TLS的双向认证信息及token验证

TLS双向认证的基本原理及示意流程图,帮助更好的理解TLS的加密功能,及安全能力,此外还给出了部分源码的实现及Token实现在的方案及能力