不用 https 自己实现对 http请求的内容的 rsa 加密，这样足够安全吗？ 第1页

非常津津有味且认真地读了这个问题下面很多朋友的回答与讨论，感觉基本上算是把https重新造了遍轮子，接近于拼凑成https诞生史了。

不过，值得庆幸的是，提问者并没有想从加密算法这个层次上来新造轮子(ε=ε=ε=┏(゜ロ゜;)┛

“不用 https 自己实现对 http请求的内容的 rsa 加密，这样足够安全吗？”

单从安全性上来讲，这个也并不是足够安全的。

首先，你需要再造一个类似于浏览器的独立应用程序和http server。因为JavaScript即使是经过混淆，其安全性也是脆弱不堪的，如果你用JS本身来执行加解密算法，而非浏览器原生支持的https的话，那么安全性自然下降很多。因此，你最好重造一个独立的浏览器，来预防可能会遭遇到的各类注入攻击和恶意修改行为，以及同步进行数据的加解密。

其次的话，你在题目中只提到了一个RSA算法，但RSA无论是加密还是解密^[1]，一般都是要比同长度的AES慢很多的，还会遇到的一个问题在于，你用什么方式来传递通信双方RSA的公钥呢？

为了解决性能问题，你可能会想到选取对称加密算法，诸如AES，DES等，但你还是没有解决一个问题，那就是密钥该怎么传输？

首先应该否决掉的，就是密钥通过明文方式来传输。那么接下来，就很容易再造SSL/TLS轮子了，即先用RSA来加密对称算法的密钥，然后通信双方再通过对称算法密钥来进行大量的信息传输工作。

完成上述步骤之后，事情开始有所好转，对称加密算法的密钥安全问题得到了解决，通信双方的数据安全问题也得到了解决，甚至性能问题同样得到了解决。

但还有一个棘手的问题紧接着就来了，你如何保证数据传输通道的安全性？如何避免中间人截取数据来进行攻击？

如果在沟通建立之初的三次握手阶段遭遇到了中间人攻击，那么攻击者将截获服务器的公钥以及通信双方用于加密数据的对称密钥，到了这一步，之后双方的所有明文通信数据在攻击者面前都将一览无余。

到这里，你可能就需要再造一次CA证书轮子了，通过内置于操作系统当中的根证书以及由层层信任关系组成的CA证书体系，来防范中间人攻击的发生。同样的，这里也要依赖于你的浏览器系统，否则利用javascript会导致前功尽弃的。

前面我在谈整个流程的时候，一直说的都是“对称加密算法的密钥”和“非对称密钥”，但这两者究竟是什么呢？

对称算法可以是DES、AES和RC5等，非对称密钥也可以是RSA、Elgamal和ECC等。再扩展开来讲，数据的完整性校验可以使用MD5，SHA-1等，你重新造的SSL/TLS轮子和CA证书体系，也都需要使用者的协商和认可，保证兼容性问题和共识问题，否则便只能自己和自己玩了。

以上谈到了一些安全问题和共识问题，可能还有更多的问题，当我们把这些问题都想清楚的时候，那么https协议的高明之处也就显现出来了，同样也就可以被各位重新造轮子出来了。

参考

1. ^ https://security.stackexchange.com/questions/57205/why-is-rsa-decryption-slow

密码学课的教授第一节课就强调了这一点

在已经有广泛应用的加密算法的实现的时候，千万不要自己尝试实现加密算法，因为自己的实现一定是有安全漏洞的。

具体来说，有https, OpenSSL这些现有的加密技术的时候，自己实现的加密算法至多和现有的技术一样安全。原因是，广泛使用且公开的加密算法及其实现，是经历过全世界用户、黑客千锤百炼过的。能被发现的安全漏洞都已经被发现并修复了。剩下的是那种非常隐蔽的，同时也不太容易被利用的安全漏洞。而自己的实现没有经过这些测试，无法保证安全性。