这是一个创建于 2753 天前的主题，其中的信息可能已经有所发展或是发生改变。
MesaLink 是百度安全实验室开发的一个内存安全并兼容 OpenSSL 的传输层安全(Transport Layer Security, TLS)协议栈。近年来 TLS 漏洞频发，以 2014 年的 OpenSSL"心血"为代表的内存安全漏洞对业界造成了巨大损失。MesaLink 的主要目标是用 Rust 这样一个保证内存安全的语言，根除 TLS 协议栈中威胁通信安全性和完整性的内存安全漏洞，减小攻击面且保证攻击面收敛可审计。此外，MesaLink 支持跨平台，提供兼容 OpenSSL 的 C API，更可在安卓和 libcurl 中无缝替换 OpenSSL。这极大地降低了开发成本，方便智能设备厂商快速获取安全通信的能力，从而实质性提升智能设备生态的安全性。MesaLink 已经在 Github 上以 BSD 协议开源。两天内已经获得了 400 多个 Star，并登上 Github Trending Project 榜单，在 Rust 语言分榜排行第一。
第 1 条附言 2018-04-07 23:30:14 +08:00
完整版文章，包含性能评测数据，已发布在百度安全实验室公众号和知乎，请 V2EX 各位大神移步：
知乎： https://zhuanlan.zhihu.com/p/35371177
公众号： https://mp.weixin.qq.com/s/_AHeStAzWx0xftYISTlk6g
知乎： https://zhuanlan.zhihu.com/p/35371177
公众号： https://mp.weixin.qq.com/s/_AHeStAzWx0xftYISTlk6g
 | 1 Mitt 2018-04-06 05:46:42 +08:00  1 拿 Rust 保证漏洞安全，怕不是下次出现致命漏洞的是 Rust 哦 |
 | 4 Servo 2018-04-06 07:29:19 +08:00 持续关注，看 README 感觉不错。 |
 | 5 boywhp 2018-04-06 07:36:00 +08:00 看了一下感觉挺好, 我准备实际测试一下 |
| &bsp; 6 boywhp 2018-04-06 07:56:57 +08:00 gcc -oclient client.c -Os -I ./include/ -L ./ -lmesalink -lpthread -ldl ubuntu x64 实际编译了一下 example 里面的 client 输出 3226577 字节的 binary 感觉体积有点重啊, 比 openssl 要大, 是我哪里没搞对? |
 | 7 bincat OP @boywhp 试下加上 -ffunction-sections -fdata-sections -Wl,--gc-sections |
| 8 boywhp 2018-04-06 08:04:19 +08:00 @bincat gcc -oclient client.c -ffunction-sections -fdata-sections -Wl,--gc-sections -Os -s -I ./include/ -L ./ -lmesalink -lpthread -ldl 编译输出 1146104 可执行文件, 终于可以接受了 |
 | 9 metorm 2018-04-06 08:36:58 +08:00 via Android 百度出品…… |
 | 10 omph 2018-04-06 08:52:21 +08:00 中国出品基础设施，可贺 |
| 13 metorm 2018-04-06 09:20:18 +08:00 via Android @boywhp 就是感慨一下，没有特别的指向。不过话说回来，百度有没有技术实力去在开源软件中预留后门呢？类似随机数发生器中的逻辑漏洞一类的。 |
 | 14 hehe12dyo 2018-04-06 09:23:45 +08:00 楼上至少有两个大黑客。 |
 | 15 qiumaoyuan 2018-04-06 09:26:51 +08:00 @boywhp 请问具体到谁？强在哪？ |
 | 16 u5f20u98de 2018-04-06 10:23:36 +08:00 没有什么语言能保证不出逻辑方面的漏洞吧 :) |
| 17 u5f20u98de 2018-04-06 10:27:18 +08:00 openssl 也曾经出了好几个逻辑方面的漏洞，不过影响没有当初 heartbleed 那么厉害 |
 | 18 exch4nge 2018-04-06 10:27:36 +08:00 原来 LZ 就是原作者啊 |
 | 19 orangeade 2018-04-06 10:34:46 +08:00 via Android 厉害了，支持开源基础设施 |
 | 20 chanssl 2018-04-06 10:40:41 +08:00 支持 |
| 21 bincat OP 4 @u5f20u98de 我们使用 Rust 语言减少越界访问、迷途指针等内存安全问题。逻辑漏洞我们靠形式化分析解决，目前正在和一些高校和有分析能力的创业公司合作推进这个方向。 |
 | 24 secondwtq 2018-04-06 20:05:39 +08:00 |
 | 26 msg7086 2018-04-06 22:36:20 +08:00 连 CPU 都能出致命漏洞，某个语言或者运行时出漏洞很奇怪吗？ |
 | 27 Kilerd 2018-04-06 23:39:46 +08:00 基础化设施，支持一波。 Rust 写的，支持一波。 |
 | 28 waruqi 2018-04-07 00:04:42 +08:00 via Android 看着像基于 rustsl 做的 openssl 接口 wrap ？ |
 | 30 congeec 2018-04-07 13:28:33 +08:00 via iPhone @abscon 语言可以规范和实现分开来做。比如 C 艹一套标准有多种编译器+标准库的实现。标准库的代码瑕疵可能导致安全漏洞，但是语言规范设计漏洞导致不得 bug 我还没听说过。 Python 么，大家都默认指 CPython。你说 python 爆漏洞，应该指后者吧。 rust 跟 C 艹类似，可以 bare metal, 也可以用标准库。 我觉得一楼指的是语言设计方面的缺陷导致安全隐患。所以问了下 |
 | 31 gnaggnoyil 2018-04-07 14:27:02 +08:00 @congeec C++语言规范经常有因为考虑不周到而导致的漏洞.CWG 和 LWG 的 issue 里一抓一大把.但是 C++语言规范的漏洞顶多是导致各个实现的行为不一致,和所谓安全性漏洞几乎没有关系.OpenSSL 相当多的漏洞主要原因就是 C 的限制导致的代码质量不行,所以我还是很看好用 Rust 重写的 SSL 实现的 |
 | 32 linusyang 2018-04-07 15:40:16 +08:00 2 @waruqi 我也感觉是这样，本质是一个兼容封装库。找了半天实际的加密算法代码，mesalink -> rustls -> ring，最后发现实际加密算法还是用 C 写的，而且是 BoringSSL(OpenSSL)复制过来的 [1]。有点又绕回来的感觉，这么一层一层封装至少性能上不会比 OpenSSL 更好，也会依赖 OpenSSL 具体实现的安全。 想起来 Hacker News/Reddit 上的老笑话，万事万物都可以用 Rust 重写。用 Rust 写是很好，但不是万金油，我认为只能解决一部分问题，比如内存上的问题。最终还是得做形式化分析，证明完导出代码，比如用 F* 写的一个 TLS 库 [2]，用的加密算法也是验证过的 [3]，虽然形式化分析是条不归路。 [1] https://github.com/briansmith/ring/tree/master/crypto [2] https://github.com/mitls/mitls-fstar [3] https://github.com/mitls/hacl-star |
 | 33 zhicheng 2018-04-07 16:02:08 +08:00 原 po 就是觉得用 C 容易出问题，所以用 rust。那别人评论质疑一下 rust 可能出问题又被粉丝喷，rust 粉丝你们棒棒的。 加密库是个深坑，用 C 写都容易出问题，更别说其它语言了，你们还是回去写 runtime 吧。 |
| 34 bincat OP @linusyang 使用 ring 来自 BoringSSL 的加密算法原语的原因我们和 ring 的作者 Brian Smith 讨论过，主要的理由是 BoringSSL 的原语的正确性和性能更有保证，尤其是 constant time crypto。性能上其实不差，可以参考完整版的文章 https://zhuanlan.zhihu.com/p/35371177 和 https://gist.github.com/kevinis/ca7fa432af076a5f3330c7e39daf27fc |
 | 35 linusyang 2018-04-08 06:24:50 +08:00 3 @bincat 我看了一下你们的 benchmark，测试 OpenSSL 的时候并不公平，在测试的每次 iteration 内部有很多 OpenSSL EVP context 初始化和释放的额外开销，导致测试时间多了将近一倍。这个可以用 Instruments.app 或者 valgrind/callgrind 作 profile，很容易就可以查到。 具体来说，OpenSSL 测试的部分用的是 rust-openssl 库，调用的是 symm.rs 里面高层 api，具体的函数是 encrypt_aead [1]。注意到 encrypt_aead 在每次做加密的时候都会新建一个 Crypter 对象，加密完离开作用域会自动调用 drop trait 里定义的 drop()释放。而 Crypter 封装的也是 OpenSSL 的高层 EVP api，初始化的时候会调用一次 EVP_CIPHER_CTX_new 和两次 EVP_CipherInit_ex，释放的时候会调用一次 EVP_CIPHER_CTX_free。这些函数在 test::Bencher 测试的时候，每次循环都会调用，产生的开销还是挺大的。 事实上在加密的时候并不是每次都要新的 Crypter/EVP 对象，因为加密的 IV、Key 和算法都是固定的，理论上只要一个就行了，所以说这部分开销是额外的。但是注意这里不能简单地只建一个 symm::Crypter 复用，因为 EVP api 的限制，每次都要重建，所以用 openssl speed -evp 命令跑出来的也不够快。这里如果不考虑测试函数的正确性，只测 AES-GCM 加密的时间，我们可以只把 Crypter::update 放在 b.iter 的循环里，这样测出来的时间就跟 Ring 的差不多了 [2]。可以参见 https://gist.github.com/linusyang/102325bf5c03928e1ae85c51082cad63。 Ring 的测试里面用的是 aead::seal_in_place 函数 [3]，实际封装的是 C 语言写的 AES-GCM 加密函数 [4]，不需要新建和释放 EVP 对象，也就没有了这部分的开销。所以最后测出来 Ring 看起来跑得更快，虽然具体加密算法用的就是 OpenSSL 的代码 [5]。 如果要写一个更公平的测试，最好直接调用更底层的 OpenSSL 函数，可以用 rust-openssl 里的 openssl-sys 库封装的 FFI 来写，就可以去掉 EVP 对象这部分的开销。 [1] https://github.com/sfackler/rust-openssl/blob/c1e5a5c/openssl/src/symm.rs#L664 [2] https://gist.github.com/linusyang/102325bf5c03928e1ae85c51082cad63/revisions [3] https://github.com/briansmith/ring/blob/1caad72/src/aead/mod.rs#L200 [4] https://github.com/briansmith/ring/blob/1caad72/crypto/cipher/e_aes.c#L301 [5] https://github.com/briansmith/ring/blob/1caad72/crypto/fipsmodule/aes/asm/aesni-x86_64.pl#L566 |
| 36 bincat OP @linusyang 多谢回复。我们理解您希望公平地对 openssl 和 ring 的 aead 加密原语性能做对比，我们也清楚其实 ring 的加密原语和 boringssl 一样都来自 openssl。但一个加密算法毕竟是需要通过 API 去访问的，正如您所说，openssl 的加密原语没有错，是 EVP 对象的新建和析构扯了后腿，而 ring 没有这个问题所以性能更好。我们以 openssl 官方 benchmark，即 openssl speed -evp 作为基准来比较，也是想突出这一点。我们会参考您的建议，使用 openssl-sys 再做一次实验。 |
Select Language