走https了,还需要对参数加密以及防止重放攻击吗

一只小桃子 发布于 2016/05/26 23:56
阅读 10K+
收藏 0

我个人觉得,走https之后,传参本来就是加密的,不需要再自己搞一套app端加密、后台解密的东西。这种方式本身就没卵用,别人看到你的app源码之后,他也可以加密,这个并起不到什么保护作用。

另外https,每个socket连接都会验证证书,交换密钥。别人截获我的包,重新发送一遍,因为socket不一样,密钥也不一样,后台解密后应该是一对乱码才对。所以https本身就是防止重放攻击的。除非你能复制socket,或者在我和服务器之间插一脚。只要我验证了业务的唯一性,比如一个订单只能支付一次,那么就没有必要管重放攻击。

不知道我理解的对不对。有个项目,已经决定走https了,同事还要搞一套加密,我觉得是不是没有必要?

加载中
4
巴林的狗尾草
巴林的狗尾草

楼上回复的其实都还不如楼主对于SSL的研究深入,SSL防止的是中间人攻击跟网络监听,如果你的手机上被人安装了木马,那么对于传输通道进行加密就毫无意义,试想人家都跑到你家里面去了,所有的东西在内存跟硬盘里面都有,再进行网络监听毫无意义。

所谓的SSL不安全其实是相对的,因为ssl加密所使用的秘钥虽然是每个链接不同的,但是通过网络监听进行包的分析还是存在破解的可能,只是时间问题而已,关键看你是否值得别人进行这种层面的攻击,如果你是国家主席,或者银行的行长或者是某个巨富,那么还是有可能有人会采用这种攻击的,所以说看你的软件了,如果你是国家安全部门的或者核心金融安全部门的比如中国人民银行这种,建议你使用更加secure的传输方式。但是对于普通人,SSL足够了。

巴林的狗尾草
巴林的狗尾草
漏了一点儿,SSL的秘钥的时效性很短,所以一般别人破解出来的同时,秘钥已经失效了。
0
黑暗圣堂武士
黑暗圣堂武士
你用fiddler抓包,然后重放一次看看呢
调皮的XD
调皮的XD
回复 @黑暗圣堂武士 : 重放本机的没意义啊,要重放别人的才有意思
黑暗圣堂武士
黑暗圣堂武士
回复 @调皮的程序员 : 楼主说的不是防止重放嘛。
调皮的XD
调皮的XD
这只能重放自己机器上面的嘛,能中间人吗?能截取到别人的参数信息吗?求解
0
曾经的十字镐
曾经的十字镐

https 是可以破解的,现在已经不再安全

理工小强
理工小强
过于含糊了 https中使用弱的密码套件的确有这个问题 但是正确使用的套件是无法破解的
0
SunnyGo
SunnyGo
https不安全,可以抓包
调皮的XD
调皮的XD
回复 @zzeric :重放你自己的数据, 这个有意义吗?“攻击者利用网络监听或者其他方式盗取认证凭据,之后再把它重新发给认证服务器”这是百科上面的定义摘录的,前提是你能网络监听或者盗取了认证凭据重放才有意义,https你能网络监听别人的请求??
zzeric
zzeric
回复 @调皮的程序员 : 本机抓了,拿到别的机器上重放不行吗
调皮的XD
调皮的XD
回复 @SunnyGo : app抓包和本机的有什么区别,都是抓自己的,重放攻击要重放别人的才有意义,想你这样说,所有的ssl都得死了
SunnyGo
SunnyGo
回复 @调皮的程序员 : app上的抓包,就可以破译服务器的数据,你说算不算?
调皮的XD
调皮的XD
抓自己本机的不算吧,要中间人抓包才行吧
0
红薯官方
红薯官方
这么一说来,SSL都死 了。
0
调皮的XD
调皮的XD
楼主你理解是对的,https了不能重放他人请求了,最多app破解了知道你请求的参数怎么传的,并不能知道参数的内容是什么,重放自己的请求没意义,如果说都走https了都能被中间人抓包,那所有的https都危险了,除非你应用是金融级别的,才需要严格的加密,而且客户端加密推荐用C加密,否则反编译了就可以看到了
调皮的XD
调皮的XD
回复 @一只小桃子 : 还有种情况也可以,就是你把用户的路由器等设备黑了,dns攻击一下,这样的话的确https可以破解,这种情况和你手机种了木马有什么区别,终端都被攻击了,https也没法
调皮的XD
调皮的XD
回复 @一只小桃子 : 你能伪装成服务端?你能拿到该https的证书?服务器的域名能指向你的机器??如何你能做到这步算我没说
巴林的狗尾草
巴林的狗尾草
回复 @一只小桃子 : 流量的重放是没有意义的,支付流程不是仅仅一条记录直接完成支付即可,都是针对订单进行支付,所有首先你要重放订单请求,但是这个请求必然是防止重入的,然后对同一订单重复支付是没有意义的。
一只小桃子
一只小桃子
可以重放啊,比如你从自己钱包提现。我可以多提一次,悄悄把钱拿走。
Shazi199
Shazi199
回复 @一只小桃子 : 可是你这样只是做个代理而已,不能解密又有什么意义呢
下一页
0
听风呢喃
听风呢喃

引用来自“巴林的狗尾草”的评论

楼上回复的其实都还不如楼主对于SSL的研究深入,SSL防止的是中间人攻击跟网络监听,如果你的手机上被人安装了木马,那么对于传输通道进行加密就毫无意义,试想人家都跑到你家里面去了,所有的东西在内存跟硬盘里面都有,再进行网络监听毫无意义。

所谓的SSL不安全其实是相对的,因为ssl加密所使用的秘钥虽然是每个链接不同的,但是通过网络监听进行包的分析还是存在破解的可能,只是时间问题而已,关键看你是否值得别人进行这种层面的攻击,如果你是国家主席,或者银行的行长或者是某个巨富,那么还是有可能有人会采用这种攻击的,所以说看你的软件了,如果你是国家安全部门的或者核心金融安全部门的比如中国人民银行这种,建议你使用更加secure的传输方式。但是对于普通人,SSL足够了。

这是正解~~! 
0
你要爪子
你要爪子

引用来自“巴林的狗尾草”的评论

楼上回复的其实都还不如楼主对于SSL的研究深入,SSL防止的是中间人攻击跟网络监听,如果你的手机上被人安装了木马,那么对于传输通道进行加密就毫无意义,试想人家都跑到你家里面去了,所有的东西在内存跟硬盘里面都有,再进行网络监听毫无意义。

所谓的SSL不安全其实是相对的,因为ssl加密所使用的秘钥虽然是每个链接不同的,但是通过网络监听进行包的分析还是存在破解的可能,只是时间问题而已,关键看你是否值得别人进行这种层面的攻击,如果你是国家主席,或者银行的行长或者是某个巨富,那么还是有可能有人会采用这种攻击的,所以说看你的软件了,如果你是国家安全部门的或者核心金融安全部门的比如中国人民银行这种,建议你使用更加secure的传输方式。但是对于普通人,SSL足够了。

第一句话说得特别对
0
莫扎特的代码
莫扎特的代码
ssl本身就是来防止中间人攻击的,针对ssl的中间人攻击首先就要伪造可信任的证书,除非根证书机构抽风了,要不然中间人在https中很难实施,而针对一次一密的会话进行解密就只存在数学上的概率了。。。
0
阿采
阿采

能理解楼主同事的想法,就像即使有一条绝对安全的公共货运线,但是如果你要运送的东西很机密不想让别人看到,还是希望能有一套自己的保险机制,只有自己能打开盒子。因为所谓绝对安全的公共管道是不存在的,很难排除过程中被人劫持下来偷窥的可能性。

知乎上有人问过这个问题,楼主可以参考一下 http://www.zhihu.com/question/22779469


我记得以前遇到过很执拗的安全测试,要求用户的客户端内存里不能出现任何敏感信息明文,楼主感受一下。

Shazi199
Shazi199
回复 @一只小桃子 : url是报文的一部分,是被加密的,怎么会被路由器记录呢,除非路由器也被黑了
调皮的XD
调皮的XD
回复 @一只小桃子 : app可以用C加密,就看不到了,以前我们的app就是这样做的
阿采
阿采
回复 @一只小桃子 : 服务端加密客户端解密?这是个什么需求。。。不过如果只是针对你同事坚持要客户端加密传输,我觉得是可以理解的,因为这样做除了增加一些工作量不会有任何弊端。而不这样做会带来可能的安全隐患以及对这样的不够专业做法的质疑。
一只小桃子
一只小桃子
走https之后,记得不要url后跟参数,因为会被浏览器,路由器记到历史记录里。不要用cookie存明文。其他的应该无所谓了。关键是app这边加密并没有用啊,因为别人可以看到你源码的。app加密,服务器解密,这样可以防止信息泄漏。服务器加密,app解密,这个没用,你源码都在别人手里了
返回顶部
顶部