api接口使用https协议是否安全性很高了?

一直知道https比http安全,传输的数据是加密balalabala。。。
那我的api接口使用https协议是不是就不用再在程序中对消息进行加解密了?
安全性满分一百分的话,下面几种分数会打几分
1,直接使用http
2,使用http,但是自己使用加解密函数对数据进行加解密
3,使用https
4,使用https,又自己使用加解密函数对数据进行加解密

1 = 50分,没有安全性可言,API内容会被明文传输,而且容易被劫持
2 = 60分,加解密函数要考虑的问题会比较多,如果只是对称加密,其实并不比方案1安全多少
3 = 90分,其实应该把这个方法叫做TLS,它已经足够安全,具体的安全机制可以参考这篇文章
4 = 80分,既然已经实现了TLS,再做一次加密对于破解复杂度来说没有提升,反而损失了性能

HTTPS解决的问题不只是加密,更重要的是认证,证明服务器真的是你要的服务器,自己加密没多大用。
如果假定网络是不安全的,你无论怎么加密都没用,反正从一开始秘钥就被看光了。
非对称加密可能还有点用,交换秘钥完毕就安全了,但是HTTPS已经实现了,还更好,自己还折腾个啥?

有什么办法避免网页被嗅探密码(中间人攻击)?

低成本的方法肯定是使用 3,https
如果你的 api 真的对安全要求很多,也可以使用 https + 自己实现加解密
我指的是 不要过度优化,真的有必要的时候,这个看你们业务场景了

说明一点 https 本身就牵涉到加解密的过程,牵涉到非对称加密,对称加密,整个过程会耗时
所以相同的接口使用 https 肯定比 http 慢,慢几到几十到几百毫秒,这个你可以自己测试。

以上各位从加密方面谈了安全程度评测,我将以cracker角度发表下看法:


  1. 直接肉眼分析

  2. 分析客户端解密函数

  3. 伪造证书实现代理转发

  4. 3+2


https只是保证了传输过程的相对安全,但远远谈不谈安全。
只要你的代码运行在客户端,就有被逆向的可能。
你所能做的,就是就是尽量复杂化客户端的加密。。。

发表评论

电子邮件地址不会被公开。 必填项已用*标注