V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  thisismr2  ›  全部回复第 1 页 / 共 18 页
回复总数  349
1  2  3  4  5  6  7  8  9  10 ... 18  
104 天前
回复了 thisismr2 创建的主题 cURL curl 稳定版终于支持 HTTP3 了
@deorth 应该希望不大了,一来很多没实现,二来实现了的有很多不标准,三来 socks5 的 UDP 协议标准本身就有点绕

https://www.txthinking.com/talks/articles/socks5-and-http-proxy.article
104 天前
回复了 thisismr2 创建的主题 cURL curl 稳定版终于支持 HTTP3 了
@jim9606 嗯,是的
104 天前
回复了 thisismr2 创建的主题 cURL curl 稳定版终于支持 HTTP3 了
#4 下载的 curl 也是单个独立文件
104 天前
回复了 thisismr2 创建的主题 cURL curl 稳定版终于支持 HTTP3 了
@weeei brew 是不是也有类 port 的此类参数
104 天前
回复了 thisismr2 创建的主题 cURL curl 稳定版终于支持 HTTP3 了
@Masoud2023 没优势,就一个二进制文件
@thisismr2 #18

结贴了: https://signal.org/blog/safety-number-updates/

结论:也就是大家在使用 WhatsApp 或 Signal 时,是无法保证如他们宣传般的安全的,除非你和你的朋友再通过其他方式去验证 指纹(也就是上面的这个文章),其他方式必须是 WhatsApp 或 Signal 之外的方式(裁判和运动员不能是同一角色),比如线下或发邮件。

---

声明: [以上结论仅是笔者研究两天的结果,仅供参考,并不代表权威] 。如果你是密码学或相关领域专家,可以阅读 https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdfhttps://signal.org/blog/safety-number-updates/ 以及其他相关 paper ,以得出更权威的结论。

-- END
@gscsnm 是的,存在消息被 S 丢弃的可能,但因主观原因被丢弃的可能不大,因为 S 无法解密进而审查。客观原因倒是有,比如负载过高,像某些 IM 那样投递后删了,没有 ACK 机制,等
@mightybruce “你的电脑和手机在出厂的时候就已经植入受信的安全证书。” 也算是依赖可信第三方,新增角色了。( CNNIC)
@mightybruce #22 是的核心问题就是 基于身份的密码学。涉及到贴文的内容就是 基于一个不可信的第三方来交换密钥。所以才质疑 WhatsApp/Signal 作为不可信第三方的,又没有提供其他渠道(比如线下)来确认。

IBE 好像也是需要依赖一个可信第三方 PKS 。

Boneh Franklin 我搜了一下,好像仍存"可疑",可能如你所说的是 性能问题
@geelaw #11 嗯,对安全性没有定义明确

- A 和 B 之外的第三者(方)可以得到 A 和 B 之间的明文消息
- 或有第三者(方)冒充 A/B 身份 向 B/A 发送消息(当然 S 的认证机制可以保证,因为假设了 cookie 不会泄漏)

@geelaw #11 @wy315700 #14 @leonshaw #17

嗯,这个问题是其实是一个比较简单的加密场景。看来漏洞就是 C 通过多人转告或 [C 公开了 K] ,比如 push 到 github 上。这样 S 就能解密 A 和 B 的密文了

@geelaw 感谢赐教

背景是,在看 WhatsApp 的白皮书 https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf
开始的阶段需要交换公钥,无论是 Diffie–Hellman ,还是 PGP ,在通过中间人交换公钥的时候,都有可能被中间方替换,而这个中间方就是 WhatsApp 的服务端自己。

但才疏学浅,没看十分明白,即 A 和 B 通过 WhatsApp 交换公钥的时候,怎么让 A 和 B 相信自己得到的公钥就是来自 A 和 B ,而不是 WhatsApp 的。[1]

比如 TLS 本身是依赖一个公共的 CA 列表,大家都相信。PGP ,有时依赖一个 https://keys.openpgp.org ,这个有个简单的身份信息认证机制,有时依赖一个慢慢建立起来的信任网络。

基于[1];同时,WhatsApp 的协议的复杂度也难于让用户(比如抓包)自己审计传输了什么。就在想有没有可能设计一个最简单的 minimal 的 end-end 加密的方案,用户随时可自行审查的,比如用户随时自己抓包就可以验证整个交互内容和逻辑。

谢谢
@GeruzoniAnsasu 感谢回复。
> K 可由 C 泄露,
是的 C 可以继续泄漏 K 。但文中有一个描述:“C 和 S 没有关系,也就是说他们之间不会(直接或间接的)共享自己知道的东西“。
> 消息可从 S 截获
TLS
> 毕竟你只预设 A 和 B 的终端是可信的,S 和 C 没有包含在内
抱歉。没有描述很清楚。我 append 一条 S 的终端也是安全的。
C 终端自己是自由的,当然注意文中已经描述 任何客户端和 S 都有认证机制 cookie (注册)
@ryuutanyou 感谢回复。但您指的“不安全”仍是主观的,因为 C 只有 K 没有密文。参考 #5
/ping @geelaw
290 天前
回复了 thisismr2 创建的主题 程序员 jb - 用轻松的方式写脚本
@julyclyde nami 比较简单,只会在保存独立命令文件在 ~/.nami/bin ,不会写很多文件库到其他目录
291 天前
回复了 thisismr2 创建的主题 程序员 jb - 用轻松的方式写脚本
@julyclyde

一个方便安装命令的工具,比如

```
bash <(curl https://bash.ooo/nami.sh)
```
```
nami install joker
```

安装运行 brook

nami install brook
joker brook wsserver -l :20000 -p world

安装运行 shadowsocks

nami install shadowsocks
joker ssserver -m aes-256-gcm -k hello -s 10.138.1.6:30000 -U --udp-timeout 60 --tcp-no-delay

查看

joker list
291 天前
回复了 thisismr2 创建的主题 程序员 jb - 用轻松的方式写脚本
@Al0rid4l

之前一直在用 zx ,jb 是 zx 的 port 。
好处是不用安装 node 栈,jb 就是一个独立的二进制文件,放到 path 里就可以了
还有就是 zx 需要 await $`ls -l`, jb 不需要 await ,直接 $`ls -l`
302 天前
回复了 thisismr2 创建的主题 macOS Brook 上架 Mac App Store 了
@kingsley777 感谢建议,这个问题的确讨论过,从这里开始 https://t.me/brookgroup/50793 还有这里 https://t.me/brookgroup/51890https://t.me/brookgroup/51899 。当然可以走 web $1 ,全端 mac / ios / android / windows / linux ,可用于 5 台设备。
1  2  3  4  5  6  7  8  9  10 ... 18  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1421 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 22ms · UTC 23:47 · PVG 07:47 · LAX 16:47 · JFK 19:47
Developed with CodeLauncher
♥ Do have faith in what you're doing.