时间：2021-07-01 10:21:17 帮助过：9人阅读
一直知道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，再做一次加密对于破解复杂度来说没有提升，反而损失了性能
低成本的方法肯定是使用 3，https
如果你的 api 真的对安全要求很多，也可以使用 https + 自己实现加解密
我指的是 不要过度优化，真的有必要的时候，这个看你们业务场景了
说明一点 https 本身就牵涉到加解密的过程，牵涉到非对称加密，对称加密，整个过程会耗时
所以相同的接口使用 https 肯定比 http 慢，慢几到几十到几百毫秒，这个你可以自己测试。
HTTPS解决的问题不只是加密，更重要的是认证，证明服务器真的是你要的服务器，自己加密没多大用。
如果假定网络是不安全的，你无论怎么加密都没用，反正从一开始秘钥就被看光了。
非对称加密可能还有点用，交换秘钥完毕就安全了，但是HTTPS已经实现了，还更好，自己还折腾个啥？
有什么办法避免网页被嗅探密码（中间人攻击）？
以上各位从加密方面谈了安全程度评测，我将以cracker角度发表下看法：
直接肉眼分析
分析客户端解密函数
伪造证书实现代理转发
3+2
https只是保证了传输过程的相对安全，但远远谈不谈安全。
只要你的代码运行在客户端，就有被逆向的可能。
你所能做的，就是就是尽量复杂化客户端的加密。。。