1
wwqgtxx 2017-03-01 17:18:10 +08:00 via iPhone
可以试试,自己用 js 实现 tls ,底层用 websockets
|
3
RqPS6rhmP3Nyn3Tm 2017-03-01 17:22:27 +08:00 via iPhone
http 页面不防篡改,中间人也可以给你的服务器 /浏览器返回一个假的证书啊
|
4
wevsty 2017-03-01 17:23:21 +08:00 1
如果不想使用现成的 TLS ,那就只能自己在 socket 上实现一遍 TLS 了。
|
9
chinajik 2017-03-01 17:28:49 +08:00
巧了。。 最近也是在做这个。。目前也是 https +rsa
|
10
enenaaa 2017-03-01 17:31:10 +08:00
每次刷新都用密码登陆
|
12
miao1007 2017-03-01 17:33:02 +08:00 via Android
报文 rsa 加密后 base64
|
14
wevsty 2017-03-01 17:35:23 +08:00 1
@nilai TLS 的实现是很复杂的,自己实现的安全性往往没有使用现成的套件安全,高效。除非特别需要,否则强烈不推荐自己实现这样的过程,不明白这样做的目的是什么?
|
15
paradoxs 2017-03-01 17:36:19 +08:00 1
提出这种要求的人, 能回答一下, 如果 https 被破解了, 就你做的这点加密, 能扛得住别人几分钟的攻击?
|
16
RqPS6rhmP3Nyn3Tm 2017-03-01 17:39:57 +08:00 via iPhone 1
@nilai 都给你了假证书了,监听岂不是再简单不过的事情?
用自己的证书解密再转发给你的服务器不就好了,这就是 MITM 在安全性被妥协的环境下的典型监听方法 |
19
rogerchen 2017-03-01 18:39:39 +08:00 4
@nilai
什么叫浏览器到服务器简单?浏览器会用你的私有协议?还是你要自己写一个浏览器? RSA 是用来传 key 的, payload 也用 RSA 来传?难道你的客户都是四路 E7 配置起跳? 拿到 AES 密文和明文就能猜出 key ? 抗 CPA 是吃翔的? 不是我嘲讽楼主,密码学入门知识都不懂也想撸密码学基础架构,这种一般叫 troll 吧。 |
20
LGA1150 2017-03-01 18:40:27 +08:00 via Android
XMPP+TLS
|
22
snnn 2017-03-01 18:44:06 +08:00 via Android
看来你还不知道啥是消息完整性
|
23
liyvhg 2017-03-01 18:54:29 +08:00 via Android
私有协议,全程 websocket
|
24
hjc4869 2017-03-01 18:56:21 +08:00
客户端可以,浏览器不行。
|
25
RqPS6rhmP3Nyn3Tm 2017-03-01 18:56:42 +08:00 via iPhone
@jybox 我理解的篡改内容是篡改传输的内容,而非握手阶段的信报。如果是这样的话,确实算是篡改了。
不过 aes 那段,真的没啥想说的…… |
26
maplerecall 2017-03-01 19:12:15 +08:00 via Android
简单的说,如果是纯浏览器环境就放弃吧
|
27
mengzhuo 2017-03-01 19:23:05 +08:00
没有
不要自欺欺人 |
28
hst001 2017-03-01 19:29:46 +08:00
简单从信息加密的角度想一下,其实从服务器发给浏览器,无论何种方法,客户端都有有一个解密的 key ,所以问题在于怎么安全的把解密的 key 交到客户端的手里,我的想法是。。。。。当!当!当!亲自上门交到客户手里!不要喷我
|
29
wwqgtxx 2017-03-01 19:33:24 +08:00 via iPhone
@rogerchen payload 就算用 rsa 加密其实也不需要 e7 那么夸张,我用过纯 python 实现的 rsa 加密,在 500k/s 下也就用了 10%的 cpu(cpython3.5+i7 4790)
|
30
momomirage 2017-03-01 19:44:09 +08:00 1
线下交换公钥, 线上 PGP
|
31
jsq2627 2017-03-01 19:45:18 +08:00
讲道理的话,就算 https ,没有进 preload list 也谈不上多安全。
就楼主的需求,简单的对称加密,密钥明文下发都没啥大问题。不定期换换密钥和稍微更新一下加密方式就好。 如果楼主遇到的是强大的对抗力量(比如国家机器)的话,在现在的环境下基本是无解的。 |
32
zjcqoo 2017-03-01 19:46:00 +08:00
------- 楼歪了,我来说个方案 ------
HTTP 下防劫持比较靠谱的方案 —— 给入口页面使用前端缓存,比如 html5 appcache 、 max-age 等等,资源使用加密传输。 这样做的好处是,把风险缩小到首次访问。之后就算遇到不安全的网络,打开的也是缓存里的页面,不会被中间人篡改程序和界面。 这种方案叫做 TOFU ( Trust on First Use ,信任首次使用)。 |
33
KKKKKK 2017-03-01 19:54:51 +08:00 via iPhone
pjax+aes 加密
|
34
majinjing3 2017-03-01 19:58:24 +08:00 via Android
直接用带 tls 的 tcp 就好了,和 http 没有啥必然关系的,
|
35
loading 2017-03-01 19:59:51 +08:00
vpn 拨上,链路不就加密了?
|
36
whimsySun 2017-03-01 20:00:47 +08:00
没有
|
37
xqin 2017-03-01 20:03:18 +08:00
其实楼主的问题, 要解决很简单嘛, 约定一个算法.
比如 QQTEA https://github.com/xqin/qqtea 浏览器随机生成加密 KEY, 然后用 RSA 加密, 发给服务器, 服务器 用同样的算法 (PHP 版的 QQTEA https://github.com/xqin/qqtea.php), 使用相同的 KEY 来进行加密, 加密后的内容返回给浏览器, 这样 key 在传输的过程中是加密的, 且 服务器回来内容的时候只有加密后的内容. 这个 key 只有 浏览器和服务器 俩人知道. 所以就达到了保密的目的. |
38
NUT 2017-03-01 20:05:09 +08:00
把序列化的后的数据(比如 protocol )的二进制数据,加自己的头,做下偏移。或者伪装成 zip 的文件等等。 说白了就是他自己拿到包也用不了。
|
39
bdbai 2017-03-01 20:21:37 +08:00 via Android
@majinjing3 读题 纯 web
|
40
Hardrain 2017-03-01 20:23:18 +08:00
个人认为无法做到
因为在没有预先建立信任体系的前提下无法对抗中间人攻击 预先建立的信任体系 是指: 对于 SSL/TLS 则是 PKI(公钥基础设施) 对于 GPG 则是通信双方都信任的、能与通信双方建立可靠连接的 Key Server 如果你有极可靠的方法(如嵌入软件中或"面对面交换")来完成 SSL/TLS 中密钥交换机制所完成的 那另当别论 |
42
xqin 2017-03-01 20:48:42 +08:00
@Hardrain 看清楼主的假设好吗? 只考虑监听, 不考虑篡改内容.
基于这个假设的条件下, 服务器先下发 RSA 公钥, JS 生成一个用于加密的 KEY, 然后对要进行提交的数据使用生成的 KEY 加密, 使用 RSA 算法对 KEY 进行加密, 将 RSA 的结果和要传递的数据的加密结果一起传给服务器,服务器自己解 RSA 之后,用 KEY 解加密数据, 即可. |
43
nijux 2017-03-01 20:51:04 +08:00
端到端加密
|
44
Hardrain 2017-03-01 20:57:12 +08:00
@xqin 我并不认为我没有看清楚楼主的假设
中间人攻击并不<b>仅仅</b>用于篡改传输内容 你要是用匿名(不签名)的 DH/ECDH 抑或是为签名过的 RSA 公钥进行密钥交换,窃听者完全有可能用中间人攻击的手段获取加密通讯的内容. |
45
likuku 2017-03-01 20:59:12 +08:00
gpg 签名且加密,不走 http ,直接走 smtp + tls 互传,即 gpg 加密和签名后的消息报文。
公私钥安全传递,自己派人用加密 U 盘人肉信使传递吧。(重要的外交文件,依然人肉信使传递) 想想当前航空用的空地文本通讯,还是用加密的电报传输呢。 |
47
thekll 2017-03-01 21:04:16 +08:00 via iPhone
先搞清楚什么样的中间人,如果客户端拥有者同时想扮演中间人,他有很多方法截获通信内容;
如果只是防止真正的第三人, https+浏览器+HPKP 、 HSTS ,或 https+客户端+built-in certificate pinning 就可以。 如果还不放心,直接双向证书认证的 ipsec 够了吧。 |
48
Hardrain 2017-03-01 21:05:58 +08:00
|
50
fzleee 2017-03-01 21:56:09 +08:00
大概三年前我做过一个简单的实验。大致的介绍在这里: https://ifconfiger.com/page/cryptography-on-application-layer 。现在回过头来看,感觉实现的方法还是有点不太成熟的。
简单的流程大概是这样的: 1.服务器和用户共享一对相同的密码。 2. 用户在浏览器输入密码后,浏览器的 JavaScript 对密码进行 hash 获得对称密钥。 3. JavaScript 用对称密钥对 http 请求的数据进行加密,将加密的数据使用 base64 编码发送至服务器。 4. 服务器解密请求,生成响应的消息体,使用密钥加密消息体并传回客户端。 以上流程我能想到的一些缺点: 1. 一个是不能保证数据的完整性==》密钥生成的方式容易收到重放攻击。 2. 再一个是使用了 ECB 模式加密数据==>这个倒是可以使用类似的 DH 算法协商一个 IV 。 3. 前向安全性貌似不能保证。 |
51
xqin 2017-03-01 22:32:02 +08:00 1
@Hardrain 还是用代码来说话吧.
演示地址: https://xqin.net/http/ 源代码: https://github.com/xqin/http_encrypt_demo 查看演示的时候, 可以打开控制台, 看 Network 中的请求及响应, 请以窃听者的身份, 根据请求和响应的内容, 得到服务器返回的原始数据. > PS: 客户端收到的原始数据会在页面中输出, 以便你检测你自己还原出来的和服务器返回的是一样的. >> 再再 PS: 如果觉得演示是放在 HTTPS 的站点上有问题的话, 可以自己 clone 一下源码,然后在你本地部署一份, >>> 然后用 Fiddler 做为 HTTP 代理(窃听者), 根本 Fiddler 里捕获到的数据, 还原输出服务器返回的原始数据. |
52
czc2004211 2017-03-01 22:36:28 +08:00 via iPhone
我倒是好奇坚持不让用 https 的原因
|
53
bianhua 2017-03-01 22:47:25 +08:00
@jybox
能篡改的话,想要监听也是轻而易举的把? TLS 之所以安全是因为通讯双方的身份都是得到过认证的。服务器向客户端发出一把锁,客户端用自己本地的 CA 记录验证服务器发来的锁是否合法,然后将数据用锁锁好发送给服务器。 如果没有服务器和客户端验证的过程,数据加密就跟没有一样。 就楼主需求来说,如果 Web 应用上不了 TLS ,就不要考虑加任何“加密通讯”手段了。因为都是徒劳的,只是给自己的安慰剂而已。别人真想监听,它可以注入一个 JavaScript 绑定所有 Input 的 onChange 事件发出来,这样你拦都拦不住。 |
54
Hardrain 2017-03-01 23:08:32 +08:00
@xqin
https://www.zhihu.com/question/45069626 https://program-think.blogspot.com/2016/09/https-ssl-tls-3.html 学习一个 你这个实现无论如何也要进行密钥协商吧?似乎没有使用 DH/ECDH 服务器---RSA 公钥--->客户端 那么有上一行这个过程吧? 如果中间人有能力篡改连接内容,改了你公钥不就做成了中间人攻击? SSL 中你把 CSR 交给 CA 不就是给公钥签名让中间人改不了,如果改了客户端会发现吗? 照你的神逻辑 自签名证书也有足够的安全性 OpenSSL 随便就能生成一个谁还花钱找 CA 买证书去? 此外,你所说"传输的内容用算法进行加密",如果你用了非对称加密那不用保证『客户端获取的是服务器的公钥而不是中间人的公钥』? 此外此外,我不明白你一直说的原始数据是指什么?我可以理解为密文吗? |
55
xqin 2017-03-01 23:29:12 +08:00
|
56
xqin 2017-03-01 23:33:10 +08:00
楼主在上面 强调了好几次, 只考虑防窃听不考虑篡改, 可还有一堆上人, 在往 篡改数据上面扯.
|
57
RqPS6rhmP3Nyn3Tm 2017-03-01 23:33:12 +08:00
@Hardrain #39 其实 PGP 的信任体系是基于指纹的,密钥服务器不可信,正确的做法是通过传统方式(电话等)核对指纹
|
59
Hardrain 2017-03-01 23:35:50 +08:00
|
61
RqPS6rhmP3Nyn3Tm 2017-03-01 23:45:02 +08:00 via iPhone
@Hardrain 所以有不同等级啊,像 ppa 这种人工核对指纹肯定不现实,所以算了算了你们自己下载吧,反正也有 https 被篡改了也是证书商背锅
你的理解是对的,这个条件就是指纹,至于公钥服务器则是任何人都可以建立的东西 |
63
Hardrain 2017-03-01 23:48:17 +08:00
|
64
xqin 2017-03-01 23:52:10 +08:00
@Hardrain 自己往上看看楼主在 #5 #8 #13 #18 楼回复的内容, 好吗?
楼主强调了四次 <<暂时不考虑中间人篡改内容, 只防中间人监听,解密出内容。>> 好吗? 是谁在 "死搅蛮缠" ? |
65
MFC 2017-03-02 00:15:38 +08:00
不知 Flash 能否实现这个需求?
|
66
pubby 2017-03-02 00:15:43 +08:00 via Android
|
67
xqin 2017-03-02 00:20:04 +08:00
@pubby 没有, 楼主的本意应该只是探讨一下, 在非 HTTPS 以及不考虑 内容被篡改的情况下, 有什么好的方法
防止被其他人监听到传输的原始内容. <<暂时不考虑中间人篡改内容, 只防中间人监听,解密出内容。>> 这是楼主的原话. |
68
fengyie007 2017-03-02 00:32:20 +08:00 via Android
这个要求很奇葩,难道是为了省个证书的钱?
|
69
LeeSeoung 2017-03-02 09:18:48 +08:00
浏览器 ----> 服务端 (这个倒好做, RSA 浏览器公钥加密,
这个不是在你加密之前截获数据就行了么? - -你要是想依靠 js , flash 完成加解密,很容易被破解,控件的话破解难度会加大,但是用户体验不好 |
71
janxin 2017-03-02 09:23:23 +08:00
自己实现一遍 https
|
72
wizardoz 2017-03-02 09:24:37 +08:00
提出这要的要求果然很奇葩。不使用浏览器自带的 https ,反而在 JS 上实现一套不可能健全的 https 。
多出来的开发费用可以买多少年证书了啊。 |
73
nilai OP @xqin 昨晚有事, 一早来看回复了这么多, 大家的回复我都看了, 首先这需求的确奇葩,
首先允许中间人窃听(像什么端口镜像之类等等) (小到公司内网出口,大到运营商出口等,都会分析网络流量) 其次是防止通过窃听流量还原出明文(敲黑板。。。。) (在浏览器本身,比入注入进浏览器内存获取未加密数据不在考虑范围, 通过浏览器本身的一些插件扩散等都不在考虑范围) (什么中间人公钥私钥替换中转也都不在此考虑范围) xqin 应该是明白我的意思, 你的 DEMO 代码我也看了, 我目前大概也是这样做的, 不过没有用 QQTEA 算法, 还是用标准的 AES , 跟你的方案不同的是我用了 localStorageService 把本地解密的 KEY 缓存在浏览器内存中, 另一直也在准备用 ecdh 方案来实现密钥交换 |