加了 https,敏感信息还要加密吗?

2017-05-05 12:15:24 +08:00
 WhyAreYouSoSad

比如传输账号密码

19930 次点击
所在节点    SSL
87 条回复
lovedebug
2017-05-05 15:22:26 +08:00
@ryd994 其实你理解的不对。 国内银行的 U 盾实现的双向证书认证,可以有效的避免被攻击。因为客户用自己的私钥加密的数据,并将公钥通过服务器的公钥加密后交还给了服务器,由于公钥不是众所周知的,相对安全不少。
ryd994
2017-05-05 15:22:44 +08:00
@BXIA 如果我信任 1password 的客户端加密的话,用 http 我都无所谓。可惜我不相信任何闭源密码管理器。
lovedebug
2017-05-05 15:25:35 +08:00
@ryd994 HTTPS 赖以为生的是 CA 的可信性,可惜现在大厂也会出错,verisign 之类的也发生过。 如果不相信对方的证书有效性,可以自己发起 OCSP 验证。
lovedebug
2017-05-05 15:27:03 +08:00
@ryd994 chrome 浏览器更强大,谷歌强制要求所有证书被谷歌的服务验证,so,可以通过 google api 验证证书,保证证书的唯一性和有效性
ryd994
2017-05-05 15:37:04 +08:00
@lovedebug U 盾和浏览器插件是两回事。U 盾是硬件密钥,由可信硬件来处理加密过程。私钥在任何情况下都不在硬件外存在。而浏览器加密,不就是纯软件 TPM 么?纯软件 TPM 除了 debug 用途外,没有实际安全意义。
“并将公钥通过服务器的公钥加密后交还给了服务器”你的理解是错的。双向 TLS 是 TLS 协议的一部分。客户端证书和服务端证书一样,由 CA 保证。要是由客户端发公钥,服务端不检查证书链的话,等于单向 TLS,因为只要破了服务端 TLS 就能中间人客户端证书。
至于 U 盾,虽然不一定是双向 TLS,但一样会检查客户端证书。
要是哪个银行是客户端发什么公钥服务端就用什么的话,大概是安全审计脑子被驴踢了。

“由于公钥不是众所周知的,相对安全不少” 黑人问号???公钥当然是扩散的越广越安全啊。藏着掖着你就等着被中间人吧
我的公钥就在 https://github.com/renyidong.keys 任何人都可以随意获取

我一直以来就两个观点:
1. 能上 TLS 的都上 TLS
2. TLS 不够的,上硬件密钥
tony1016
2017-05-05 15:42:01 +08:00
@ryd994 不要把国外的银行拿出来套中国的国情,也不要简单觉得 HTTPS 那么安全。TSL 核心是安全的没错,但是 TSL 到 HTTPS 的过程涉及很多问题,所以即使没有 CA 的问题,也会被降级攻击,普通用户根本意识不到。你可以研究研究 bettercap 的做法,我亲自试过,gmail 密码随便取。不想学工具,就看看视频

<amp-youtube data-videoid="BfvoONHXuQA" layout="responsive" width="480" height="270"></amp-youtube>
ryd994
2017-05-05 15:43:08 +08:00
@lovedebug OCSP 不是用来解决那个问题的。OCSP 是保证私钥泄露时可以 revoke。
你说的问题,是由 Certificate Transparency 审计保护的。各大 CA 都在签发系统内加入了 CT,任何证书都有连续 id,且会向 CT 备案。wosign 的事情就是查 CT 查出来的。敢绕过 CT 的 CA,恐怕比 wosign 死的还惨。
google 那是另一套系统,和 PKI 系统并行而已,然而这和要不要自己加密有什么关系?
paradoxs
2017-05-05 15:44:46 +08:00
不加密的话, 用 Mitm 不就能看到你 POST 数据包的结构了?????????
我惊讶了. 难道这个不是问题?
wangxiyu191
2017-05-05 15:46:19 +08:00
@zealot0630 前端 hash 可以一定程度上保证就算服务器被攻陷,用户的密码明文不会泄露。这个意义在于,如果用户在其他网站使用了同样的密码,不至于被撞库。
lovedebug
2017-05-05 15:54:35 +08:00
@ryd994 没有讨论加密,只是陈述下目前证书存在的问题和解决方案。OCSP 除了 revoke 也是在证书过期时发布,可惜浏览器不是时刻都查 OCSP 的,存在缓存或者使用 CRL,中间有一个空档期。
各大 CA 在自己家加的是 Audit Log, 谷歌强推的是 CT log,虽然还是在 beta 中。
lovedebug
2017-05-05 15:57:22 +08:00
@ryd994 双向认证客户端证书签发者不一定是公开的 CA,只要服务器端将客户端的签发证书置于自己的 truststore 中就能完成部署。
taozhijiangscu
2017-05-05 15:58:17 +08:00
通常 HTTPS 就不用了,不过很多重要数据会做签名。
ryd994
2017-05-05 15:58:18 +08:00
@tony1016 你的视频给的不是 gmail
我找了 gmail 视频,用的 IE6 吧那是?
facebook HSTS bypass 那部分我也找了,这不就是 includeSubdomains 的作用么?
而且,这和不要自己加密有什么矛盾么? HTTPS 不能解决的问题,凭什么自制的宇宙无敌加密协议能解决?
能破 HTTPS 就能破各种自己的加密:挂个 javascript,把密码框复制一份就好了,随你怎么加密。
lovedebug
2017-05-05 15:59:00 +08:00
@ryd994 U 盾可能我理解的不对。 硬件 token 有证书版和 RSA 版的。
ryd994
2017-05-05 16:03:23 +08:00
@lovedebug 我说的是服务器一定会检查客户端证书,这和你说的 truststore 不矛盾,truststore 本质上是预分发的证书 pinning
我不同意的是 “公钥通过服务器的公钥加密后交还给了服务器”和“由于公钥不是众所周知的,相对安全不少”
公钥不需要用服务器公钥加密也是一样,在长度和算法一样的前提下,安全性没有本质上的区别
公钥是不是众所周知也和安全性无关,要是知道公钥会降低安全性的话,应该先质询一下用的非对称算法
ryd994
2017-05-05 16:06:40 +08:00
@lovedebug 证书或是单纯 RSA,本质上都是一样的,就是可信硬件。
我还见过自带键盘的智能卡读卡器,同样的,也有(好像是工行吧) U 盾自带按键和显示屏,显示屏显示单号金额,确认按键。这都是可信硬件。和浏览器加密完全不是一个范畴。
该上该硬件的上硬件,不要用浏览器加密自欺欺人
lovedebug
2017-05-05 16:09:50 +08:00
@ryd994 同意你的看法。 公钥众所众知是对单向的访问意义更大。双向访问客户端的证书被众所周知就意义不大了。前一句 “公钥通过服务器的公钥加密后交还给了服务器” 是完成证书交换时做的,描述的不合适。应该是服务器讲自己的证书给客户端并要求客户端提供证书以用于验证。公钥的安全性看是 SHA1 还是 SHA2 了,SHA1 已经不安全了
lovedebug
2017-05-05 16:12:52 +08:00
@ryd994 浏览器加密本身就是伪命题,TLS 协议安全就安全,除非能互相协商出加密的算法,oracle 还是 IBM 好像有加密的软件,带来的问题是这个加密的密钥怎么传递
Quaintjade
2017-05-05 16:26:13 +08:00
@ryd994
现在国内银行的网银插件也开始转变了吧,主要只是安装 U 盾的驱动和添加国产根证书。

至于为什么要用 U 盾而不是直接依赖系统证书,我想一方面是用户系统可能被安装其他根证书,另一方面可能是所谓“国家金融安全”的考虑。
毕竟事实上现在客户端上的证书体系是由 Google,Mozilla,MS,Apple 等国外机构主导的,算法也是国际组织提出和审核的,而且出现过试图加塞带后门曲线的事情。所以国内做的事情是使用国产算法(虽然原理上和 ECC 之类类似),但协议设计仍参照公开的行业标准(例如 X.509 )。至于有没有意义就另说了。
ryd994
2017-05-05 16:41:49 +08:00
@lovedebug TLS 其实是整个流程的抽象化,任何一个环节都可以替换。比如加密算法,比如证书验证。协议上 psk 也是可以的,虽然没人用罢了。自己发明一套无非再造轮子。很多人没这个能力。

@Quaintjade
U 盾参见我上面说的可信硬件。硬件和浏览器加密完全是两回事。U 盾密钥不存在与内存,除非硬件设计失误,否则密钥根本不可能泄露。如果是配合硬件的浏览器加密,我放心。
国产算法不是指的国密吧?双证书体已经成为笑话了。内裤上交国家,一百个放心呢。
加后门的是 openssl 的实现,算法是可靠的,实现出了问题。国产加密,用户量不够,时间太短,问题只会更严重。
算法和协议谁发明的不重要,都是公开发过论文的,有问题的迟早要被捅出来的。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/359310

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX