為什麼V2EX不使用HTTPS？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 4336 天前的主题，其中的信息可能已经有所发展或是发生改变。

幾個問題：
1、涉及登錄密碼仍然用HTTP，是否不夠安全？
2、如果手動輸入HTTPS網址，Chrome會出現安全警告，是否是沒有購買證書所致？

HTTPS

輸入

購買

18 条回复 • 1970-01-01 08:00:00 +08:00

qinix

2013-02-04 23:36:57 +08:00 via Android

没必要吧

qq286735628

2013-02-05 00:03:24 +08:00

传送过程被侦听了也没啥事，又不是什么敏感信息....
网络安全中的攻防都是建立在成本上的...
没价值的东西，黑客不会花成本去窃取...
没价值的东西，客户也没必要去花费额外的成本去保护...

ihacku

2013-02-05 00:18:02 +08:00

2是因为证书是这个子站点的 https://workspace.v2ex.com/
1请参见/t/59436

atsivsucks

2013-02-05 00:24:47 +08:00

@qq286735628 你的V2EX登陆密码是不是敏感信息？

Livid

MOD

2013-02-05 00:27:08 +08:00

我们会尽快加上的。谢谢提醒。

qq286735628

2013-02-05 00:34:01 +08:00

@atsivsucks 我的意思是
如果你觉的帐号值得使用ssl来保护，如果@livid 觉得V2EX上面的用户密码有被监听的风险、且带来的危害很大，那就很有必要采取ssl等保护措施，提高攻击者的攻击成本，让攻击者先掂量掂量再作决定。
其实你觉得V2EX的登录密码是敏感信息的，完全可以采用另外一套密码，别和自己的金融帐号密码重复就好呀。
有很多更省的方式的，并且ssl也不是万能，如果你的密码真值那么多钱，攻击者有其他方式的。

Livid

MOD

2013-02-05 00:37:35 +08:00

@qq286735628 对，最安全的做法，就是为每个网站使用一个独特的密码。对自己的邮箱使用最高级别的，不和任何其他地方重复的密码。

atsivsucks

2013-02-05 15:02:15 +08:00

@qq286735628 SSL确实不万能，不过除了中国内地的网站，要密码却不用SSL的网站我还没有见过，不知道你能不能给我找出两个看看？先谢了

“有很多更省的方式的”，网站制作者“省”，用户麻烦，什么逻辑？之前CSDN明文密码泻露，那责任是不是在用户不应该注册这种不靠谱的网站？而不是CSDN应该保障用户的安全？

chrisyipw

2013-02-05 15:16:53 +08:00

@atsivsucks CSDN 「明文密码」泄漏和 HTTPS 并没有关系，前者泄漏是网站自身的，1）密码没混淆，2）服务器安全措施没做好；而 HTTPS 只是在用户的机器到服务器之间建立相对安全的通道，并没有解决前两个问题（一样会密码泄漏）。

在做好密码混淆、服务器防黑的情况下，用户在 HTTP 登录的时候密码被截获，这属于用户的问题，比如你在公共咖啡厅上网，任何一个网络服务都没有办法也不可能去为用户的上网环境负责，能做的只是像提供 SSL、安全令牌等「辅助服务」，但并不是「义务」。

BTW，CSDN 的不靠谱不是密码泄漏、不是没用 HTTPS，是明文储存，如果一个网站能把你的密码混淆到即使获得了，也不会影响到你别的帐号，就足够靠谱了，是不是 HTTPS 没关系。毕竟程序是人写、机器是人搭，漏洞难免。

PS：要密码却不用 SSL 的，比如 Google Reader 就不是强制 SSL 访问。

keakon

2013-02-05 15:30:23 +08:00

@chrisyipw 登录时需要输入密码，这个时候是强制 HTTPS 的。登录完可以不用安全连接，此时 cookie 是存在泄露风险的，但影响不大。

wwqgtxx

2013-02-05 17:43:05 +08:00 via Android

@Livid 还是建议尽快增加全站https支持，防止gfw监听

qq286735628

2013-02-05 23:03:31 +08:00

@atsivsucks 你没明白我的意思，当我没说吧~
我赞同你说的，给网站部署ssl，加强安全性，这也是SPDY草案里面的一条，未来HTTP协议发展的趋势。

luikore

2013-02-06 00:26:42 +08:00

还有个问题: cookie 没设置成 http only ...

如果 session 打劫链接能全部 escape 掉的话应该问题不大, 试试:

<a href="javascript:document.location='http://v2ex.com?'+document.cookie">steal your cookie</a>

no2x

2013-02-06 03:49:27 +08:00

探讨一下。

如果没有 SSL 而换一个简单的做法，在前端直接用 javascript 去 md5/sha1 加密密码（还可以加入令牌效果的会话验证），然后传输到后端配对。是否会相对安全呢？至少，减少了泄露明文。

@Livid @qq286735628 @chrisyipw

chrisyipw

2013-02-06 05:24:24 +08:00

@no2x 客户端 hash 与否不影响客户端泄密的成功率，因为加密密码常见手法是 hash + salt，salt 相关的算法不被泄漏，即使拿到完整数据库也无从得知真实密码。而客户端不管是什么，都可能被截获，什甚至看源码就知道你是 md5 还是 sha1，现在 GPU 计算那么强大，算出对应的字符串成本还算低的。

我想过一个客户端加密方案，就是随机布局的虚拟键盘，而且键值也是随机的，比如点击 a 时不是返回 "a"，而是一个值的 key，服务器收到后，再转换成对应字符，这样的话要获取明文密码就只能获取点击时的字符（如截图）或算法。这样似乎不需要 SSL 也行（没真正部署过

no2x

2013-02-06 15:08:46 +08:00

@chrisyipw 你这个做法跟我的类似，更复杂一点而已，但也仅仅是避免直接泄露明文。SSL 的主要作用在于数据流的加密传输，保证不会被截取窃听及伪造。

atsivsucks

2013-02-08 12:12:46 +08:00

@chrisyipw Google的登錄頁面從來都是HTTPS啊，不知道Google Reader有何特別？

xinhugo

2013-03-03 02:12:39 +08:00

@chrisyipw

CSDN部分的看法，基本认同。机器是人搭，漏洞难免，但已知漏洞却不尽快修复，则是责任的缺失。

Google账户是强制SSL访问的，使用accounts.google.com域名。Google Reader没有强制SSL访问，并不影响Google账户密码的安全性。