一把锁的传奇——从 OpenSSL 到 MesaLink

原创
2018/05/28 17:04
阅读数 255

【文章来自浅黑科技,百度安全实验室授权转载】


一把锁的传奇——从 OpenSSL 到 MesaLink


文 | 史中


一、神奇小镇,手信和锁 


从前有一座神奇的小镇。


小镇上的居民天生都不会说话,但是他们每人都能写一手好字。依靠“传纸条”,他们每天都能快乐地交流。



于是,邮差们成了小镇上最忙碌的人。他们不断地从一些居民手上收信,然后把它们送到另一些居民手上,从早到晚不停歇,在小镇上跑过的路线就像蜘蛛网一样。


渐渐地,出现了一点儿小状况:


虽然只是负责送信,但是八卦的邮差们总忍不住偷看小纸条上的内容。谁家的小秘密,用不了几天所有人就都知道了。


一位叫钢蛋的姑娘恋爱了,她觉得如果自己给心上人说的情话,让邮差就这样明晃晃地拿去,肯定传得满城风雨,实在是太害羞了。


于是,钢蛋想到了一个好主意,她去村头锁匠“老O”那里买了几把锁。把自己的信封锁起来交给邮差,而邮差把带锁的信送给情人之后,对方再用准备好的相同的钥匙把锁打开。


其他人看到了,纷纷惊呼“还有这种骚操作?”于是都去“老O”那里买锁,把自己的信“加密”,这回邮差就别想偷看信里的内容啦。小镇居民于是又像从前一样过上了没羞没臊的生活。


这座神奇的小镇,名字就叫“互联网”。


而给信件加锁的套路,就是你每天都在用的 SSL 加密传输协议。(使用 SSL 协议传输的时候,在网址的最左边会出现“HTTPs”字样,有的浏览器还会显示一把小锁,你一定见过。)



而小镇中的那个锁匠老O,对应在现实世界的互联网中,就是著名的“OpenSSL”加密传输组件。



简单来说,加密传输的技术是酱紫的:


在你访问网站的时候,你和网站共同商量出一个“秘钥”,你们之间传递的信息,都用这个秘钥加密。那么在整个传输的过程中,无论是什么人都没办法窥探传输内容。


正如神奇小镇上的锁匠“老O”三辈祖传做锁,所以镇上大多数人都在用他家的锁一样,由于OpenSSL 从1995年就开始维护这套加密传输技术,所以目前大多数网站都选择他家的“老字号”加密传输组件。


好,中哥今天的故事讲完了。


再见。


。。。

。。。

。。。


等等,浅友们你们坐下。这个世界上从来就没有 Happy Ending。接下来就是今天的 ONE MORE THING。。。


2014年,这个小镇上新来了一位奇怪的邮差。。。


姑娘钢蛋发现,这个邮差贼眉鼠眼,于是决定跟踪着他。


高潮紧接着来了。这个邮差拿到信之后,拐进了一个黑漆漆的胡同,然后从兜里掏出一把“万能钥匙”,把所有的锁都打开了,津津有味地读着别人的隐私。。。


钢蛋顿时如五雷轰顶,手扶胸口,一口老血喷出来,嗷一声昏死过去。。。


镇上的捕头闻讯赶来,当场发现了邮差“私自开锁”的勾当。


原来,这位邮差原本是一个“开锁爱好者”,他发现了一个惊天秘密——所有老O家生产的锁,都有一个缺陷,只要自制一把万能钥匙就能打开,这才动了心思要来假扮邮差盗取人们的隐私。


此事一出,老O颜面扫地,专门挨家挨户赔礼道歉,并且把家家户户的锁都修复成了“最新版”。


小镇上为了纪念这次安全事件,专门在广场上立了一个石碑,上面画着钢蛋手扶胸口喷血的样子,以警示世人。于是这个锁的漏洞,也被命名为“心脏滴血”。。。


钢蛋姑娘和心脏滴血漏洞


我说的可不是神话故事,而是发生在我们身边的真实历史。


2014年,著名的 OpenSSL 组件爆发了心脏滴血漏洞:黑客通过简单的方法进行攻击,就可以不费吹灰之力拿到用户和网站的隐私。这就像一枚核弹爆炸,让全球大多数网站的密文传输系统瞬间崩塌。各大网站纷纷火速修补,然而直到 2018 年,仍然有很多网站在使用带有漏洞的安全协议。


你可能已经明白我想说什么了——“心脏滴血”绝不是 ONE MORE THING,而是一部恐怖续集的第一幕。


“心脏滴血”一周年时,全球仍受影响的国家。可以看出来,越是信息技术发达的国家,影响越持续。(数据来自 ZoomEye)



二、老锁匠 OpenSSL,小锁匠 MesaLink 


让我们再回到那个小镇。


“心脏滴血”以后,锁匠老O压力贼大,之后每年都推出一个新版的锁改进安全性。但是人们逐渐发现,他家的锁还是时不时出问题。好心人帮助老O追根溯源,问题可能出在了祖传的制锁工艺“C++”上。。。


好,现在我们来到真实的互联网世界。


SSL 加密传输组件早在1998年就被 OpenSSL 项目组推出,它的一大特点也就是使用了“祖传工艺”:C/C++ 语言。


使用C语言好处很明显,那就是和其他程序适配起来像德芙一样丝滑,像老坛酸菜面一样酸爽,这也是 OpenSSL 在各个服务中使用率居高不下并且一直稳如狗的原因。


但是,C语言的弊端同样很明显。那就是,这种源于1970年代的语言,多多少少有点古老了。人间一天,赛博世界一年。如果这么看的话,C语言相当于计算机界的“古文”,看上去有点“郑伯克段于鄢”的感觉。


于是,问题来了。


这种古老的语言,有些逻辑机制天生就存在缺陷和含混,即便 SSL(Secure Sockets Layer 安全套接层协议) 后来升级成为了 TLS(Transport Layer Security 安全传输层协议),也做了修补升级,但还是会有新的漏洞不断爆出。这就像一个用了30年的木桶,经常莫名从某个缝隙漏出水来,很烦。


这个问题“老锁匠” OpenSSL 眼看就要无解,于是村里的“小锁匠”们挺身而出了。


全世界很多公司、团队、个人,都尝试根据 TLS 协议的国际标准,开发了自己加密传输协议,试着拯救千疮百孔的互联网隐私。


这其中,有谷歌开发的 BoringSSL,有苹果开发的 LibreSSL。当然也有一群中国人在为之努力,这就是:百度安全实验室硅谷团队的研究员和他们的 MesaLink。



看这图标,像不像“黑拱门”?Bincat ,就是百度安全“黑拱门计划”的负责人。


他用一句话概括了 MesaLink 和 TLS(就是SSL的升级版)的最大区别,那就是 :


MesaLink 放弃了 C++ 语言,而是用了 Rust 语言写成的。


在 Bincat 看来,MesaLink 就像“加密传输界的特斯拉”。虽然看上去和传统汽车差不多,但是因为使用了 Rust 语言编写,它从内部结构,到安全性能,都是颠覆式的。

那么,问题来了。


1、Rust 究竟是一种神马语言呢?


2、为什么这个名不见经传的语言最近那么火?


3、为什么百度安全的小哥们要用命来奶这种语言?


接下来就会涉及一些比较难的内容,前方高能,铁汁们扶稳坐好。



三、Rust:“处女座”专属语言


Rust 这两年挺火,它是由火狐浏览器的公司 Mozilla 开发的编程语言。 



说到 Rust,用一个关键词形容,就是“处女座”。实际上,Rust 已经强迫症到“古板”和“残酷”的地步。


Bincat 给我举了两个例子:


1)处女座的“所有权机制”


在现实生活中,你一定遇到过处女座的妹子,她用的水杯一定要放在桌子左上角的圆圈里;她用过的文件一定归档收好,电脑桌面空空如也。她借给你一本书,你必须在三天之后下午四点十六分送还给她。


Rust 在内存管理上,就是这样的处女座。


如果这段内存属于A进程,那么它就一直属于A进程,如果B进程来借这段内存,那么它就必须按时归还。如果不归还,整个程序都会卡在原地,无法继续。


如果A进程不想要这段内存了,它就要决定把它过户给B进程,或者直接把它释放掉。所以,这段内存要么属于A,要么属于B,要么被系统回收。这样严密的逻辑,会有模棱两可的情况出现?不存在的。


而在C语言中,情况就乱得多,各种借调和归还都没有明确的制度保证。也正是基于这种机制问题,十几年来黑客们研究出了很多类型的漏洞。


记得上幼儿园的那时候,一本小(xiao)人(huang)书(shu)在全班传着看,一个小朋友给另一个小朋友,根本不打借条。。。到最后,究竟是谁的书大家都忘了,这也就造成没人对它负责。到最后这本书很容易被老师发现,顺杆爆炸。


这就是所有权机制不严谨的锅。


2)处女座的“生命周期机制”


你记不记得,在我们身边有一种奇葩的送礼 Style:中秋节送的月饼,A送给B,B送给C,C送给D,等到D准备吃的时候,发现上面已经覆盖了一层调皮的白毛。。。


这就展现了一个经典的 Bug,你对月饼的使用周期已经超过了月饼的生命周期。


在赛博世界底层的内存空间里,存在着同样的问题。


一个内存指针本身是有生命周期的,它的生命周期由编译器指定。这个时候,如果有人获取了同为这段内存上的另一个指针,那么 Rust 就会自动规定这个指针的生命周期要小于之前的那个。


这种情况下,就保证了一套完整的内存生命流程。


就好像一本书,最开始在小A家的书架上,后来小A借给了小B,小B又借给了小C,但是在归还的时候,会有警察叔叔专门监督着小C先还给小B,再由小B还给小A,最后由小A放回自家的书架。这里的“警察叔叔”,就是 Rust 系统的逻辑机制。


你可能会问,这本书本来就是小A的,如果让小C直接还给小A,不是更简单吗?对不起,我只能说你还是不够了解处女座。


在 Rust 的世界里,规矩就是规矩。


Rust 世界的每个公民,每天出门要迈哪只脚,吃饭要吃多少口,说话要用什么词汇,交流要用什么语法,借别人东西要怎么还,都已经被规定得死死的。如果有人想要在 Rust 的世界里闲聊鬼扯,放浪形骸,对不起,出门左转,C++。


Rust 语言的“生命周期机制”,其实杜绝了C语言中一个重要的基因缺陷,那就是 Double Free。在C语言中,由于没有严格的管理,会发生一个内存被两次释放的“神操作”。每当这时,系统就会因为这个“非定义行为”而进入神经错乱状态,难免发生“打架斗殴”“社会不安定”等等的悲剧。


当然,在 Rust 上类似的逻辑机制还有很多。总之这种语言是非常处女座,非常讲规矩的语言,用它编写出来的程序,各个都是“强迫症”。


在生活中,你身边的“强迫症”也许很烦,但他说到做到,从来不会让你失望。说到底,强迫症们都是很可靠的朋友。你仔细品品。


其实,随着2017年 Rust 语言走向成熟,有很多软件都在使用 Rust 编写,这已经形成了一个非常有影响力的技术圈子。MesaLink 就是神秘的安全研究员们利用 Rust 的一个经典案例。



四、MesaLink 的理想国 


说到这里,我得总结一下。


1)MesaLink 是什么?

简单来说,MesaLink 其实就是用 Rust 语言编写的 TLS 协议。是百度安全的小伙伴为了让互联网传输更安全而发明的一把与众不同的精巧的锁。


2)MesaLink 的目标是什么?

当然就是更多网站和服务提供商可以使用这种更安全的传输协议, 让普通用户的隐私不会被泄露,从而构建社会主义和谐社会。


这里顺便说一下,无论是 OpenSSL 还是 MesaLink,都是开源的项目,百度安全的童鞋是不会从这里面赚钱的。作为安全研究员,他们的目标很简单:让这个世界更安全。


而且,不仅不赚钱,这绝对是一个菜钱粉心的工作。


因为“做锁”这件事非常特殊。


你想想看,如果你买了一把锁,用起来不方便你会骂人,用起来不安全你更要骂人。而实际上,方便性和安全性本来生来就是一个跷跷板的两端,一边升高几乎必然会造成另一边降低。


但用户可不管这么多,他们只管用脚投票。


所以,MesaLink 虽然是免费的,但是要想不断发展,至少要符合以下两点:


1、比传统的 TLS 更加安全;

2、和传统的 TLS 一样易用。


刚才说了半天,实际上都在说第一点: MesaLink 比 TLS 更加安全。但是,真正的挑战在于第二点,怎么把 MesaLink 做得和 TLS 一样性格随和、兼容万物。


实际上,在2017年开始这个项目之前,百度首席安全科学家、百度安全实验室的老大韦韬就已经发下了“宏愿”:


要想 MesaLink 和当年的 OpenSSL 一样辉煌,它就必须让更多人方便使用;要想方便使用,就必须要兼容 C 语言。这事儿没商量。


也就是说,即使网站原来正使用流行的 TLS,也可以不用改动代码,直接零成本切换到 MesaLink。


用户没成本了,成本就都压在 Bincat 头上了。


为了兼容 C语言,他必须把 MesaLink 做成一个“黑匣子”。


顾名思义,外面的信息传进来,不用管黑匣子里面程序如何惨绝人寰生不如死地运行,总之最后吐出一个完美的答案就可以了。


这就涉及到一个本质的问题:黑匣子内外如何进行数据交换?


这时,就要抬出韦韬大神制定的“混合代码内存安全架构三原则”。


话不多说,上干货:


1、隔离代码隔离并模块化由非内存安全代码编写的组件,并最小化其代码量)


软件的核心部分都用 Rust 来写, 只有涉及到和外界沟通的接口(C-API)不得已时才使用C语言编写。然后重点来了,MesaLink 要把Rust语言的部分和C语言的部分仔细隔离开,对他们分别管理。


这就好像火箭中的液氢仓和液氧仓,他们同时存在在火箭里,但是绝对不能相互泄露,只有在发动机中那一个点,才允许他们“牛郎织女鹊桥震”。


2、外部数据不能影响安全模块的安全性由非内存安全代码编写的组件不应减弱安全模块的安全性,尤其是公共 API 和公共数据结构


你想想,一段代码来自凶险的火星(C),乍一来到地球(Rust)上,当然要先进行免疫隔离,消毒水洗衣液敌敌畏DDT先喷一遍再说。


按照这个原则,外来的代码一定不能接触核心的数据结构。


这个具体怎么实现呢?


我曾经看过一部讲外星生物的电影《异星觉醒》,这里面有一个“隔离操作箱”。它的作用就是,既能把有危险的东西和隔离开,又能对它进行一些操作。




当然,你懂的,隔着一层塑胶套,总有些隔靴搔痒的感觉。在内存空间里,这种强制隔离就表现为性能损失。但是 Bincat 说,这个性能损失并不大,而且是必要的。毕竟,安全第一。


3、清晰可辨由非内存安全代码编写的组件需清晰可辨识并且易于更新。


由于 MesaLink 是开源软件,理论上所有程序猿都可以对它进行改编。这个时候就要注意,由于设置了 Rust 语言和 C语言的强隔离,所以很多“机关”很多“梗”都只有最初的开发团队才能理解。


为了让其他程序猿都能看懂并且不会成为“猪队友”。这些代码的位置和作用,Bincat 都要详细归类写清,还恨不得在旁边写上一个1500字的说明文做注释。这就叫做“清晰可辨”。


你可能会说,这些标准听上去很简单啊。Bincat 可不这么认为,为了研发 Mesalink,作为核心开发者的他可谓翻过三座大山。


“首先,Rust 这种处女座的语言比C语言更难;其次,TLS 协议非常复杂,单是指导手册就有100多页;再次,Rust 语言编出的程序,因为逻辑感太强,所以稍有不慎就跑不通,如果还要和C语言互通,就更要反复地调试直至精疲力竭而跪倒;最后,还要遵循刚才说的‘安全架构三原则’。。。”


这事有多复杂,也许只有老司机才能体会。


不过,好在 Bincat 一个人坐在墙角狂躁地砸键盘的日子已经过去了。最近 MesaLink 0.6 版本已经上线了。根据业内的标准,一个软件到 1.0.0 版本,才算完成十月怀胎一朝分娩。“不过要到1.0.0 还有很长的路要走。”他说。



五、中国其实更需要 Mesalink 


前面提到,虽然很多巨头公司都在做 TLS 的替代品,但是 MesaLink 还挺特别的:


1、它是中国巨头 BAT 里,唯一一个做纯开源的加密传输软件;


2、它是世界上,唯一一个用 Rust 写的与 OpenSSL 兼容的纯开源加密传输软件。


这两个特别之处,其实让 MesaLink 可以解决一些有中国特色的问题。Bincat 举了一个小例子:


国内有很多智能电视,其实都在用 Android 4.4.4 版本。但是这个版本已经不兼容 TLS 最新的1.3版,而这些硬件厂商又没有很强的开发能力,所以只能继续使用已经被证明不安全的 TLS 旧版本。


他说。


其实,不仅是智能电视,还有很多智能音箱,只要用到嵌入式 Android 操作系统的地方,中国最成熟最便宜的解决方案都是 Android 4.X 或者 5.X 的。就这一点,就足以让这些硬件和安全无缘。。。而在未来,人们肯定会通过智能电视、智能音箱进行支付活动,如果到那时底层的传输协议还像今天这样千疮百孔,那么你的钱八成会成为黑客的囊中之物。


而这,就是我们身边大多数智能硬件的现状。


如果你能像鸟儿一样,飞越华强北一带,那些林立的厂区代表着中国工业强大的生命力,但是在这些我们引以为傲的硬件背后,却有这么多难言的伤痛。



之前我曾经写过百度安全的另一个开源项目 OASP(想看的童鞋可以点击《百度安全的 OSAP 究竟是什么?》),以及未来可能要写一些的 KARMA 热修复技术,包括刚才说的 MesaLink,他们同属百度安全的 OASES 联盟,一直在试着疗愈这种“中国特色硬件生态”。


虽然普通人还没听过 MesaLink,不过在技术圈,这个独特的软件还是小有名气的。

在某同性交友网站 GitHub 上,MesaLink 一上线,就立刻遭到了围观。程序员看这种纯用 Rust 写的安全传输协议栈,就像车迷在大街上看到一部纯碳纤维外壳的跑车一样。


截止2018年5月,MesaLink 在 GitHub 上已经获得了600多颗星星,稳居 Rust 榜前列。而相比之下,谷歌的 BoringSSL

 才只有三百多颗星。从这里,也足见我们中国的程序员绝不比外国差。


可能你会问,MesaLink 完全开源免费不赚钱,为什么百度安全的童鞋会花这么大力气,动用硅谷研究院来搞这个东西呢?


其实,韦韬和 Bincat 从最一开始,就根本没有想过用 MesaLink 变现。他们研发MesaLink是因为TLS安全传输协议库是AI时代云管端安全的重要基石,如果它不安全,那么智能家居可能成为监视你隐私的窃听器,智能车可能成为“速8”里的马路杀手。要让AI技术真正造福人类,那么必须把地基打牢固,而不能是在沙滩上造城堡。


正如 OpenSSL 一样,他们也并未从 SSL 协议栈中盈利,但最终他们成为受人尊敬的团队。究其原因,也许是因为他们承担了未来世界的责任。


“从你手中缔造的生命一旦形成生态,它的价值自然会体现。正如上帝造人一般。”


这也许正是我们说的极客精神。


虽然 MesaLink 在百度内部被戏称为“黑拱门”,不过 Bincat 皱皱眉,说他觉得这 Logo 看上去更像自行车链条。


我们每天都在用它提醒自己,希望自己别掉链子。


他笑。



P.S. 

1、第一张小镇的图片来自《雷顿教授和不可思议的小镇》,中哥吐血推荐这款游戏。

2、MesaLink在GitHub 上的链接为 https://github.com/mesalock-linux/mesalink ,感兴趣的童鞋可以点击阅读原文走波关注

本文分享自微信公众号 - 百度安全实验室(BaiduX_lab)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中

作者的其它热门文章

打赏
0
1 收藏
分享
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部
返回顶部
顶部