forever给代码加上守护,按下回车。badcert.com终于上线了。这个花费了我一个礼拜写的小东西并没有完成我所有的预期,但算是有了一点可以用的样子了。

badcert.com是一个在线的证书生成器,可以生成私钥、公钥,还可以生成自签名证书、证书签名请求(CSR)等。它还附带了证书信息查看与私钥认证等功能,方便开发者,在开发中可以绕过OpenSSL生成证书的步骤。

badcert.com截图

甚至不需要它的域名以及主页巨大的安全性提醒,而仅通过常识即可知道,使用在线生成的证书是一件非常危险的事。每一张通过badcert.com生成的证书,都可能被这个网站记录下来,从而在某个时刻被利用,导致严重的安全性后果。

——然而我们在大多数时候真的需要“那么高”的安全性吗?我时常看到有人因为使用命令行版本的OpenSSL而焦头烂额,而可能他只是想要随便一对密钥和证书去调试他的HTTPS服务器。再比如,我在开发iOS的APNS相关功能,开发者证书只对我正在调试的iOS设备起作用。我看到有人在开发时始终使用同一私钥,放到好多台不相关的服务器里去,还有把私钥和证书通过Email抄送给所有的同事,等等等等……

我是想说,在有的时候,比如开发的时候,你根本不介意私钥与证书的安全性问题。相对的,你却在OpenSSL的使用、证书的生成上花费了太多的时间。这个时候,整个证书安全认证体系就变成了一个非常费时费力的东西,变成了阻碍。那么,为什么不让开发工作进行得轻松一点呢?

badcert.com的建立就是为此。我希望能够节约开发者在证书上浪费的时间,不要将安全性搞得过犹不及,弄得大家都很火大。


badcert.com最初是因为在使用Node.jspem库。因为用的比较深度,所以顺手还修了这个库的一些bug。pem的作者也是很好的人,有几个我觉得都无关紧要得Pull Request,他都顺手merge了——特别是后来我看了一下这个作者维护的项目,还发现是个蛮厉害的人。我觉得对于开源库,及时与耐心最重要了。有的时候一个Issue十几天后作者才回复,让人非常捉急。而这个项目的Pull Request,往往隔天就merge了,然后作者把小版本号+1,让支持者有一种”哦,这个版本是我写的“的自豪感。

这个库本质上底层还是基于openssl命令。因为用得多了,维护得多了,不可避免地去看底层openssl的命令格式,觉得非常头疼,而且说起来我还是科班出生。由此觉得这个库真是那些需要OpenSSL支持的nodejs开发者的福音。

那么,为什么不把这种易用性传播到网络,让更多人能够方便地生成证书呢?不用细想就知道了——还是因为安全性。如果证书是在线生成的,那么安全性本身还有什么意义呢?这种常识当然是正确的,但我并不认为所有的情况都是如此。例如我上面提到的开发的例子。

换一个角度来说,用证书安全体系保护的计算机连接就真的安全了吗?使用者真的在好好按照手册使用证书吗?我觉得有很多滥用的地方。看看一般的网站登录密码的情况就知道了。这个世界上的网站有那么多,大多数用户都在用有限的几个甚至是同一个密码去登陆不同的网站。有的地方会做得绝一点,比如有的公司会把Windows密码规则设定为每隔两周必须重新设定,且不能和之前的重复——然后用户怕记不住新密码,就把新密码写下来贴在办公桌底下了。

这种过度的安全性保护根本就没有意义,只是安全性专家把安全责任交给了更没有安全意识的公司文员。安全性完全符合木桶原理,在其他木板不够长的情况下,费时费力地增加某一块板的长度根本没有意义。

我认为badcert.com的目标用户本来就有能力知道使用它的潜在危险,从而可以正确地使用它


scaret
548 声望14 粉丝