1
sagaxu 160 天前 1
HTTPS 防的是接触不到两端机器的中间人的攻击,防不了本机有人做手脚。
Java 写的项目,如果不做防护,反编译后一目了然,能接触到两端就能破解。 这两个加密方法功能上有点儿重叠,摸不到机器都没辙,摸到机器都很好破解。 |
2
peanut0105 160 天前
问题的关键还是你要防止哪种攻击,另外就是如果你要用 AES 的话你 AES 的密钥要怎么交换呢?
|
3
cJ8SxGOWRH0LSelC 160 天前
同 1 楼, 如果客户端 C 是 java 写的, 那再加密一次意义不大, 反编译随便看代码。
|
4
seers 160 天前 via iPhone
当然要做,每多一道防护都能抵挡掉不少攻击,首先 ssl 证书抓包是一道,然后有 aes 攻击者反编译又是一道,或者逻辑放 native 然后 jni 调用再混淆 so ,这也是目前很多大厂 app 做法
|
5
orangie 160 天前
客户端考虑用 graalvm 编译成机器码试试,大大增加反编译难度
|
6
0xsui 160 天前 via Android
通过 HTTPS 接口,发送签名的数据,服务端校验签名,具体可以参考钉钉机器人的接口调用方式
|
7
alex8 160 天前 via iPhone
典型的前端加密需求,如果中间用 cdn 加速了,又不想让 cdn 看到数据的话就要加密了。用非对称加密
|
9
alex8 160 天前
|
10
lovelylain 160 天前 via Android
是否需要再加密看安全要求,加密了更安全,但是客户端抓包不方便,会给问题定位带来不便。加密方式可以考虑客户端内置 rsa 公钥,随机生成 aes 密钥,rsa 加密 aes 密钥,aes 加密实际内容。
|
12
Goooooos 160 天前
我一般只用 md5 等做个摘要验证参数的完整性
|
13
zscself 160 天前
看你需求了吧。
1. 防中间人: https 就够了。客户端能顺利访问 https 接口获取和发送数据,说明 https 协议的一整套流程客户端和服务端是可以完整走下来的。https 是非对称加密算法加密对称加密算法的密钥,现在的 https 都是 TLS 1.1 往上了吧,大部分都是 TLS 1.2 了。再往深了说,TLS 是在 TCP 之上,HTTP 之下,相当于给 HTTP 套了一层加密的壳,非对称加密只在握手阶段使用,后面传输数据都是对称加密( RC4 ,AES 之类的流式加密)。 2. 防客户拦截查看数据:对 Java 不熟,没有发言权。不过我觉得程序在客户端侧,本身的运行环境就是不可信/不可控环境,防御措施或者说你愿意付出的防御成本和你数据的重要性成正比。往极端点说,数据总归是要解密到内存中的,防是防不住的。 |
14
zscself 160 天前
@zscself “防中间人”就是说,防止服务端和客户端之间的数据交换被别有用心的第三方窃听和篡改。客户自己想要窃听和篡改在这个语境下不算“中间人”,放在( 2.)中讨论
|
15
Chigusa 160 天前
|