mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 08:05:49 -06:00
[GH-ISSUE #1455] 希望能加入ChaCha20加密方式 #1148
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#1148
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @qiang-yu on GitHub (Oct 7, 2019).
Original GitHub issue: https://github.com/fatedier/frp/issues/1455
我现在是用 openwrt 路由器跑 frp，功能都正常，但是现在加密方式对于路由器来说太重了， 希望
加入 ChaCha20 这样比较轻量的加密方式，对于低端设备会更好
希望发布 release 的时候增加 softfloat 版本 （go编译的时候可以选择），很多低端设备都不具备FPU，加密运算需要浮点计算，编译使用 softfloat 版本对低端设备效率更高 （尤其是 mips , mipsel 这种）
@fatedier commented on GitHub (Oct 7, 2019):
@qiang-yu commented on GitHub (Oct 7, 2019):
我 mips 上测试过 v2ray 的加密， v2ray 支持 aes-128-gcm 和 chacha20-poly1305， 用 chacha20-poly1305加密的话，看 youtube 速度比 aes-128-gcm 能快一倍以上，主要原因还是 mips 的处理器做加密解密 aes 太慢了
frp 一般不是用于 gfw ，只是为了防止 DPI 探测， 弄个 XOR 或者 RC4-MD5 其实也行，或者 Base64编码 也挺好，就是整数运算，怎么简单怎么来，这样效率就高很多
另外，如果用 aes ，尽量用 gcm ，别用 cfb ， cfb 不安全
加密方式，最好是 client 选择加密方式， server 自适应， 这样同一个server 能处理 不同的 client 选择不同的加密方式，电脑、路由器 用不同的加密连接同一个 server
@fatedier commented on GitHub (Oct 7, 2019):
加密对于这个项目来说不是强需求，所以并不打算提供多种加密算法客户端来选择的方式。更多的是防止通过抓包来直接看到明文内容，所以直接用一个性能消耗低，比较通用，易于实现的加密方法就可以了。
针对你说的性能问题，可以考虑另外提供一个参数来启用一个其他的加密算法，但是不继续往这个方向扩展，不支持设置指定算法。
还有一个趋势是，后面可能会全都走 TLS 连接，整个 frpc 和 frps 的通信就全都加密了。
@qiang-yu commented on GitHub (Oct 8, 2019):
TLS 作为可选，不要默认吧
^_^ 默认加密用个简单的就好，整数运算不需要FPU的， TLS 和 AES 留给有需要的人自己配置就好
@deadlineOvO commented on GitHub (Oct 9, 2019):
那么也就是说这个项目经过的流量不具有足够的安全？
@deadlineOvO commented on GitHub (Oct 9, 2019):
说句闲话，个人希望加密方法也可以使用插件的方式来机型扩展，这样就可以根据需求选择满足需求的加密方式了
@fatedier commented on GitHub (Oct 9, 2019):
@funnypro 目的是加密，而不是通过加密来去除流量特征，安全是相对的，没有绝对的安全，只是看给破解增加的成本有多大。所以不会在加密上做太多文章，个人倾向于使用 TLS。
@deadlineOvO commented on GitHub (Oct 10, 2019):
那么在使用frp的stcp走明文流量的话，能够保证足够的安全吗？
@tomxiang1 commented on GitHub (Oct 21, 2019):
TLS中最好是加入加密方法的配置，用户可以简单选择使用AES还是Chacha20等。
我在D2550 CPU上测试过目前的TLS，由于D2550 CPU不支持硬件AES加速，所以最高只能跑到70Mbps左右。
@oO0oO0oO0o0o00 commented on GitHub (Jan 10, 2020):
QAQ 你的这个tls，双方事先并没有任何对方的凭据，无论密钥是写死的还是现生成，理论上都没法保证安全吧，了解一下机理就能中间人了。还有那个token的对称加密，既然没有人提到日期时间错误导致问题，那应该也不防重放吧（不过这不是大问题）。主要是tls的问题，至少一方要有另一方的公钥才起作用。现在这个repo挺多关注了，主要也是内网在背着公司用，潜在风险应该不小。谢谢喵
@deadlineOvO commented on GitHub (Feb 18, 2020):
要不把包抓出来给各位看看？
@fatedier commented on GitHub (Feb 19, 2020):
@oO0oO0oO0o0o00 @funnypro 之前说了，目前 tls 的作用是加密，还没有包含身份认证，之后会支持配置自己的证书。
@deadlineOvO commented on GitHub (Feb 19, 2020):
那未来会允许配置 tls 使用的是什么加密方法吗？
@fatedier commented on GitHub (Feb 19, 2020):
@funnypro 这个我还没有仔细看，如果目前 golang 的实现本身可以支持多种加密算法的话，可以考虑开放这个配置。
@deadlineOvO commented on GitHub (Feb 19, 2020):
好的
感觉使用 tls 的话可能还是要面对一些问题，例如说 kcp 是否可用 tls 加密？
@fatedier commented on GitHub (Feb 20, 2020):
@funnypro 可以的，tls 是在四层之上的协议。
@deadlineOvO commented on GitHub (Feb 20, 2020):
好的
我个人还有一个问题：既然用到了 tls 的话，为了正常使用加密是否必须申请一个域名？
还是说用自己的 CA 证书之类的？
@fatedier commented on GitHub (Feb 21, 2020):
@funnypro 目前不需要，证书都是自动生成的，并且没有校验有效性。之后如果提供配置自己的证书，那么就可以支持这个校验，双向认证。
@deadlineOvO commented on GitHub (Feb 21, 2020):
那么未来自动生成用于加密的证书会双向验证吗？
@oO0oO0oO0o0o00 commented on GitHub (Mar 2, 2020):
自动生成的没有验证的意义。要认证或者加密，无论如何都需要【事先&&用安全的途径】共享一些什么，可以是密码，可以是证书的公钥，也可以是上级签发者的公钥。