9
10
2016
6

如何取消对 WoSign 根证书的信任

WoSign 最近曝出一大堆问题,而且其处理问题的态度、解决问题的方式十分令人担忧。其官方形象也很糟糕,比如对国内 Let's Encrypt 用户进行 FUD 式威胁,比如只吊销了因 bug 误发的 GitHub 域名的证书,给某大学误发的证书视若无睹。具体问题有兴趣的可以去相关邮件组查看讨论。

这次问题我认为比起 CNNIC 要严重多了(最主要是这态度、这水准,就算它不主动作恶,也很容易被利用的样子),所以我获知情况之后就取消对了 WoSign 的信任。StartCom 签名 WoSign 的证书,所以需要一并吊销(反正也是一家人)。

火狐(桌面版)

依次打开「首选项」->「高级」->「证书」->「查看证书」,找到并选择 StartCom 和 WoSign 下的所有证书(使用 Shift 键可以选择连续的项目),然后点「编辑信任」按钮,取消弹出框中三个选项框的勾选。

Arch Linux

archlinuxcn 源用户直接执行命令:

sudo pacman -Sy revoke-disputable-ca

手动操作的话,是这样子。把需要取消信任的证书复制(不要软链接)到 /etc/ca-certificates/trust-source/blacklist/ 目录下,然后执行 update-ca-trust 命令即可。

我那个包里取消信任的证书是下边这八个:

CA_WoSign_ECC_Root.pem                    CNNIC_ROOT.pem                          StartCom_Certification_Authority_G2.pem  WoSign_China.pem
Certification_Authority_of_WoSign_G2.pem  StartCom_Certification_Authority.1.pem  StartCom_Certification_Authority.pem     WoSign.pem

Android

在「设置」->「安全」->「受信任的凭据」中禁用掉相关证书。这对 Opera Mobile 有效,但是对火狐无效。

目前还没找到火狐 Android 版禁用根证书的方式。

确认方法

访问 https://www.wosign.com/ 即可。

目前 USTC 已经更改证书,禁用这些根证书不影响 USTC 镜像源的使用。现在我因此不能访问的网站主要是 Python 邮件列表

Category: 网络 | Tags: http ssl 安全
12
5
2015
21

博客「被入侵」之谜底

2015年9月13日,我的博客流量突然少了很多:

来自百度的访问量下降

因为博客突然被百度标记为「安全联盟提醒您:该页面可能已被非法篡改!」(后边那个峰的流量来源于知乎,与此事件并无关联。)

然而我一直未发现任何异常。我使用了 Google 站长工具,Google 也没说有任何异常。所以我以为这不过是百度又发了什么神经。毕竟它也说,「有一个网友举报」。「安全联盟」那里可以申请解封,但是需要出卖手机号等隐私。更神奇的是,它要求你修正问题,却连是什么问题都不清楚。「安全联盟」的客服表示,这事他们也不清楚。

然而几天前,又有网友报告我的博客跳转到了奇怪的页面。第一次有人报告时我只当用户系统或者网络的问题,虽然我也疑惑,恶意软件或者 ISP 插广告不至于插 CJB 的广告啊。但是对方并没有能力来调查此事。这次总算是遇到了一个会抓包的读者了。于是让报告者 @xuboying 帮忙抓包,这才真相大白。

简单地说,确实有页面在传输过程中被篡改了。至于是不是非法的,就得问「有关部门」了。

事情是这个样子的:我有一篇文章嵌入了 GitHub Gist。而 GitHub Gist 的域名 gist.github.com 被污染,其中一个污染 IP 为 216.234.179.13。这大概是 CJB 的源服务器地址。

本来呢,嵌入 GitHub Gist 的代码是这样子:

<script src="https://gist.github.com/lilydjwg/0bfa6807b88e6d39a995.js"></script>

当解析到 216.234.179.13 之后,最奇妙的事情发生了:

  1. CJB 使用了自签名、过期、弱密钥的证书。火狐会嫌它太弱而不可覆盖地拒绝,其它主流浏览器也会因为证书问题而报错。小米浏览器会询问用户是否接受有问题的证书(普通用户哪里懂这个啊,估计大都会选择接受吧)。一旦接受,则进入下一步。
  2. 该服务器在访问时会返回一句复合了 HTML 和 JavaScript 的脚本,修改window.location到 CJB 的主页。而引入 GitHub Gist 的方式恰好是 JavaScript 脚本,于是它得到执行,跳转到 CJB 主页去了……(不过现在只会返回空白页了。)

后来百度取消了那个「被非法篡改」的提示,不过权重依然很低,不注意看根本找不到我博客唉。

知道是 GitHub gist 的原因之后就可以很快找到遇到同样问题的人了,比如:

Category: 网络 | Tags: 网络 博客 安全 中国特色
4
28
2015
2

为什么你不应该安装12306的证书

中华人民共和国铁道部铁路客户服务中心在其首页上说:

为保障您顺畅购票,请下载安装根证书。

真的是这样吗?

安装该根证书意味着什么?

当然意味着你在12306网站上买票时不会遇到证书错误了。但是除此之外呢?

安装之后,你的计算机系统(或者浏览器)会信任该「CA 机构」所签名的所有证书。根据安装说明,该证书不仅能签名用于标识网站的身份的证书,还能签名应用程序,即 .exe 和 .dll 文件。

这意味着,如果铁道部没有按照规范正确管理该根证书对应的私钥的话,一旦被滥用,或者被攻击盗用,那么:

  1. 攻击者可以实施中间人攻击,伪装成支付宝、网上银行、微信、网页邮箱等网站,获取你的登录和隐私信息,篡改网页内容,以你的身份提交转账和订单、与你的亲友同事聊天等。

  2. 攻击者可以为病毒和木马签名。拥有一个受系统信任的签名,恶意软件更容易在用户不知不觉间潜入。

  3. 这是一个 SHA1 签名的证书。因为其安全性比较低,各大浏览器厂商将逐渐淘汰该类证书

  4. 当然还有一些其它的用法,毕竟这个证书的权限非常大

而铁道部能按照规范正确管理该根证书对应的私钥吗?很多人连工信部(CNNIC)的根证书都不信任呢。而工信部,即使出现过下级机构违规使用证书以至于 Google 和 Mozilla 都不再信任之,至少工信部曾经得到过各操作系统和浏览器厂商的信任,不管做没做到,人家至少知道应该怎么做。而铁道部呢?根本不是干这行的,也从未在这方面做过多少努力,连正规的 HTTPS 都不知道用,你觉得如何呢?

那要怎么用12306呢?

火狐有个功能,叫「添加证书例外」。在遇到不被信任的网站证书的时候,如果你确知你没有被骗,你可以为该网站添加例外,如图所示:

为 12306 添加证书例外

添加例外之后,火狐将这个证书这个网站关联起来。也就是说,如果12306突然换证书了,你会得到错误消息;如果别的网站也使用铁道部签名的证书,你也会得到错误消息。而这些错误消息,绝大部分是在告诉你有人正在进行中间人攻击。

HTTPS 保证了端到端的数据安全性(私密性、完整性),使得你即使在公共场合上网,或者本地网络有不可信的人时也可以安心上网。请不要随意破坏这份安全。

其它链接

12
19
2014
5

SSL 中间证书配置,兼谈昨支付宝证书错误

昨天有朋友说支付宝官网 https://www.alipay.com/ 访问时浏览器报证书错误了。我试了一下,访问正常啊,不过 Certificate Patrol 告诉我支付宝更换 HTTPS 证书了,因为旧的证书要过期了。同时,证书的颁发者也换了,新证书是賽门铁克颁发的。后来我又使用 wget 访问了一下,竟然真的报错了!随即我更换了 Google Chrome 和另一个火狐配置,前者没有报错,后者却也报错了,报错信息是「该证书因为未提供证书颁发链而不被信任」(代码:sec_error_unknown_issuer):

支付宝证书报错截图

后来又使用 Android 上的 Opera Mobile 和火狐访问,也是报错。

很奇怪,大体上是经常使用的浏览器不会报错,而那些很少使用的浏览器、不记录访问数据的工具都报错了。

昨晚一直没想明白,今天早上却突然想到了:是不是支付宝配置证书时没加入中间证书、或者加错了啊?(疲劳工作什么的果然会严重效率啊喵)

支付宝现在已经能够正常访问了,而我昨天也没有进行抓包,所以没有办法证明(或者证伪)这个猜测是否正确了。不过我却可以实验一下这样的配置会导致客户端如何反应。

准备工作

域名一枚。SSL 私钥一枚、证书一枚、中间证书一枚,如果你的 SSL 证书直接由浏览器信任的根证书机构颁发的就没办法实验这个了哦。浏览器若干。哦当然还要 nginx 一枚,至少要支持 SSL。

为了便于各位重现,这里使用了两个子域名,使用不同的配置。如果你访问的时候浏览器说找不到服务器的话,那是 DNS 那边还没更新啦,今天晚些时候再试试看 :-)

第一幕:不提供中间证书

用户使用firefox -no-remote -P命令创建了一个全新的火狐配置实例。

用户:浏览器,我要访问 https://brokenchain.lilydjwg.me/

浏览器:Hi,服务器,我要以 SSL 协议访问 brokenchain.lilydjwg.me

服务器:浏览器你好,这是我的 SSL 证书。

浏览器:看看。由 AlphaSSL 颁发的证书?AlphaSSL 是谁呀??

没有中间证书

浏览器:(对用户)啊咧,服务器给出了一个咱不认识的 SSL 证书,咱不能确认其真实性。有可能是服务器配置有问题,也有可能是你被中间人攻击啦,要小心了哦!(与昨支付宝的证书错误如出一辙。)

第二幕:使用正确配置的证书

运维人员把相应的 AlphaSSL 证书附加到了网站证书文件的后面,并且重新加载了配置。

用户:浏览器,我要访问 https://goodchain.lilydjwg.me/

浏览器:Hi,服务器,我要以 SSL 协议访问 goodchain.lilydjwg.me。

服务器:浏览器你好,这是我的 SSL 证书。

浏览器:看看。是由 AlphaSSL 颁发的证书,不知道它是谁。不过对方给出了 AlphaSSL 的证书,它又是由 GlobalSign 颁发的。这货我认识,是我信任的机构。开始检查签名……签名无误。GlobalSign 确实信任 AlphaSSL,而我信任 GlobalSign。所以我信任这个证书。

有中间证书

浏览器:(对用户)一切正常!以安全的方式收到了你要访问的内容了喵~

第三幕:不提供中间证书,但浏览器拥有中间证书

用户再次访问配置有问题的服务器。

用户:浏览器,我要访问 https://brokenchain.lilydjwg.me/

浏览器:Hi,服务器,我要以 SSL 协议访问 brokenchain.lilydjwg.me

服务器:浏览器你好,这是我的 SSL 证书。

浏览器:看看。由 AlphaSSL 颁发的证书?AlphaSSL 我以前遇到过,找找看……找到了!AlphaSSL 的证书,它是由 GlobalSign 颁发的。这货我认识,是我信任的机构。开始检查签名……签名无误。GlobalSign 信任 AlphaSSL,而我又信任 AlphaSSL。所以我信任这个证书。

浏览器:(对用户)一切正常!以安全的方式收到了你要访问的内容了喵~

附录

用于实验的 nginx 配置:https://goodchain.lilydjwg.me/nginx.conf

结束语

我这里,新建的火狐实例如预期的在没有获取过中间证书时报错,在获取过之后就不再报错了。而 Google Chrome 一开始就不报错,可能是它内置了该证书,也可能是它从网上的其它某个地方取得了这个证书。wget、curl 等命令行工具总是会报错,因为它们并不存储访问过的证书。

另外注意一下,使用 cat 命令连接网站证书和中间证书时,先确保证书文件最后有换行符,不然会出错的。UNIX 传统,文本的每一行以换行符结束。而微软的做法是,换行符仅仅作为两个行中间的分隔符,最后一行并不以换行符结束,所以在连接多个文件时会因为缺少换行符而出错。

Category: 网络 | Tags: 安全 ssl Https
10
25
2013
14

php.net 被攻破,Google Chrome 浏览器竟浑然不知

人们都说 Google Chrome 浏览器安全,可是——

昨日,有网友告诉我 php.net 被挂马了。于是我在火狐浏览器中访问,果然得到了警告:

php.net blocked by Firefox

再去 Google 搜索一下,果然也被标记上了:

php.net blocked by Google Search

直接点击搜索结果会得到 Google 的警告:

php.net blocked by Google

但是,Google Chrome 浏览器访问竟然没有任何提示

今天,这个警告已经移除了。php.net 官方发布了一些消息,证实它确实被攻破了。为了以防万一,他们吊销了 php.net 所使用的 SSL 证书。我于是尝试使用火狐访问使用了 SSL 的子站,比如这个 https://wiki.php.net/,火狐很明确地告诉我,它的证书已经被废弃了:

php.net SSL certificate revoked error

但是,Google Chrome 浏览器访问依然没有任何提示,表示安全的小绿锁依然鲜亮。

难道是 Google 认为 Google Chrome 浏览器本身已经足够安全,不仅能抵御任何它能检测出来的恶意网页,而且能在证书已被吊销的情况下判断出网页是否被篡改?

php.net with revoked certificate accepted by Google Chrome

注:以上均为浏览器默认安全配置,我没有手动修改任何安全相关的选项。

更新:在 Google Chrome 的「设置」中,点击「显示高级设置…」,往后滚,找到「HTTPS/SSL」,把「检查服务器证书吊销状态」前边的框勾上,Google Chrome 就也会报告证书不可信了。

再次更新:通过 GoAgent 访问,没有收到任何关于服务器证书已经失效的提示。证实了我之前关于通过 GoAgent 访问 HTTPS 站点会降低安全性的猜测。


感谢 Eleven.i386 提供了部分截图。

11
10
2012
22

dnscrypt + dnsmasq

安装过程没什么特别的就不说了。

启动 dnscrypt-proxy。由于 systemd 实在太复杂,一时半会搞不明白,所以我直接手动启动了:

sudo dnscrypt-proxy --local-address=0.0.0.0:35535 --user=nobody --logfile=/var/log/dnscrypt.log --daemonize

然后测试下:

>>> dig -p 35535 twitter.com @localhost

; <<>> DiG 9.9.2 <<>> -p 35535 twitter.com @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65004
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;twitter.com.                   IN      A

;; ANSWER SECTION:
twitter.com.            16      IN      A       199.59.148.82
twitter.com.            16      IN      A       199.59.149.230
twitter.com.            16      IN      A       199.59.150.39

;; Query time: 267 msec
;; SERVER: 127.0.0.1#35535(127.0.0.1)
;; WHEN: Sat Nov 10 15:07:01 2012
;; MSG SIZE  rcvd: 88

It works!

然后配置 dnsmasq。

server=127.0.0.1#35535
bogus-nxdomain=67.215.65.132

bogus-nxdomain那行是为 OpenDNS 加的,类似于国内 ISP 的「114 页面」。dnscrypt 默认使用 OpenDNS 的服务器,暂时不知道其它提供加密 DNS 的服务器地址,所以只好这样了。

然后重启 dnsmasq 就 OK 了。

说点题外话。其实很多服务进程启动起来很简单,比如 sshd,改好配置文件后直接运行就可以了。再比如 mongod 和 privoxy,手动启动还方便指定配置文件什么的。我的个人电脑不是服务器,不需要复杂的各种管理。虽然说不是服务器,但重启次数还是不需要和 Windows 比的。所以,systemd 给我带来了一堆麻烦,却没能解决我遇到的任何问题

Category: 网络 | Tags: DNS dnsmasq dnscrypt 安全
10
25
2012
19

使用 TLS/SSL 加密你的 HTTP 代理

HTTP 代理是明文的,这导致实际访问的 URL 可以被他人监测到。即使使用 HTTPS 协议,经过 HTTP 代理时会发送CONNECT请求,告诉代理要连续到远程主机的指定端口。于是,访问的目标域名暴露了。

有没有办法将传输内容加密呢?比如像 HTTPS 那样,使用 TLS 协议连接到代理服务器,然后再进行 HTTP 请求。很遗憾的是,我在 ziproxy 的配置里没有发现这样的选项。在 shlug 邮件列表里询问后,Shell Xu 提到了 stunnel 这个工具。以前我试过用它把 HTTP 的网站转成 HTTPS 的,但是网站后端程序无法知晓用户实际上使用的是 HTTPS,有些郁闷,就没管它了。

这次再次请出 stunnel,在代理服务器上执行如下命令:

sudo stunnel -d 0.0.0.0:8081 -r localhost:8080 -p /etc/stunnel/stunnel.pem

这样,所有到服务器的 8081 端口的请求,都会经过 TLS 解密后传递给 8080 端口。同时响应的数据也会被加密后再返回请求方。

接下来的问题是,浏览器无法直接使用这种代理。实际上除了拿 openssl 命令手动连接外,我不知道任何程序能够使用这种代理。那好,本地弄个反过来加密/解密的服务好了。还是使用 stunnel。不过出了点意外:Arch Linux 的 stunnel 是第四版,不再用命令行参数,转而使用配置文件了。于是参考这篇 Upgrading to stunnel 4,写了份 stunnel4 的配置文件:

compression = zlib
foreground = yes
output = /dev/stdout
client = yes
pid = /tmp/stunnel.pid
# or will output to syslog :-(
output = /tmp/stunnel.log

[name]
accept = 8082
connect = server.com:8081

这样在本地 8082 端口监听,把所有请求加密后转发到 server.com 的 8081 端口。同时响应的数据会被解密后再返回。

现在,所有与代理服务器传输的数据都被加密了,不怕被偷窥啦。

后记:

后来,我发现其实代理服务器和我本机都装了两个版本的 stunnel,只是名字中不带版本号的一个是第三版而另一个是第四版而已……

再后来,我猛然想起神器 socat——这家伙是支持 OpenSSL 的!比如客户端这边像下边这样子就可以了:

$ socat tcp-listen:8082,fork openssl:server.com:8081,verify=0

socat 真是神器啊,cat、netcat、rinetd、stunnel 的功能都覆盖了!

这样使用的时候,每次来新请求时,socat 会 fork 一个新进程来处理。有点浪费资源。不过略微查看了下,stunnel 似乎也一样。

1
28
2012
5

使用 eCryptfs 加密主目录

本文根据回忆记述在 Arch Linux 上为某一新用户建立使用 eCryptfs 加密的 $HOME 目录并使之在登录时自动解密挂载的过程。大量参考了 Unknown and partly hidden 的 eCryptfs and $HOME 一文。

依赖的软件包:ecryptfs-utils。

加密目录

# mkdir -p /home/.ecryptfs/user/private
# chmod 755 /home/.ecryptfs
# chmod -R 700 /home/.ecryptfs/user
# chown -R user:user /home/.ecryptfs/user
# ln -s /home/.ecryptfs/user/private /home/user/.private
# chmod 700 /home/user

注意:最后一步原文使用的是500权限,这里改成了700

第一次挂载加密目录:

# mount -t ecryptfs /home/user/.private /home/user

eCryptfs 会询问一些加密的选项,其中 Cypher(加密方法)和 Key byte 可自行选择:

Key type: passphrase
Passphrase: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Cypher: twofish
Key byte: 32
Plaintext passtrough: yes
Filename encryption: yes
Add signature to cache: yes

一定要记住密码,虽然可能并不怎么会用到。

mount命令的输出中找到这次挂载使用的参数,经过一些变更,把类似于以下的设置添加到/etc/fstab中:

/home/user/.private /home/user ecryptfs rw,user,noauto,exec,ecryptfs_sig=XYZ,ecryptfs_cipher=twofish,ecryptfs_key_bytes=32,ecryptfs_passthrough,ecryptfs_fnek_sig=XYZ,ecryptfs_unlink_sigs 0 0

注意:在登录挂载时,noexecnosuidnodev将会是默认选项。这里加上exec选项来覆盖掉noexec,这样加密的 $HOME 中才支持执行可执行文件。

挂载时生成了/root/.ecryptfs目录。我们先在里边保存些文件:

# touch /root/.ecryptfs/auto-mount
# ecryptfs-wrap-passphrase /root/.ecryptfs/wrapped-passphrase
Passphrase to wrap: [输入加密口令]
Wrapping passphrase: [输入用户的登录口令]

现在,使用用户的登录口令可以从文件/root/.ecryptfs/wrapped-passphrase中得到 eCryptfs 的加密口令。即使加密口令很强,如果登录口令弱的话,文件信息还是会泄漏的。所以,得选个强的登录口令,不然就不要玩登录时自动挂载加密 $HOME 了。

或者,你也可以玩点有趣的,把这个wrapped-passphrase文件放在 U 盘里,只留下一个指向 U 盘里的此文件的软链接。然后配置好 U 盘自动挂载,就做成了个简单的「U 盾」!

好了,现在卸载 $HOME:

# umount /home/user

自动挂载

先把 eCryptfs 的那个在/root下的目录弄回来:

# mv /root/.ecryptfs /home/.ecryptfs/user
# chown -R user:user /home/.ecryptfs/user/.ecryptfs
# ln -s /home/.ecryptfs/user/.ecryptfs /home/user/.ecryptfs

接下来,创建一个挂载用的脚本,暂时叫它/home/profile.sh吧。它将被写到用户登录时的自动执行脚本中,如~/.profile,或者~/.zprofile,如果你用 Zsh 的话。

if [ -r "$HOME/.ecryptfs/auto-mount" ]; then
  grep -qs "$HOME ecryptfs" /proc/mounts
  if [ $? -ne 0 ]; then
    mv $HOME/.Xauthority /tmp 2>/dev/null
    mount -i "$HOME"
    cd "$HOME"
    mv /tmp/.Xauthority $HOME 2>/dev/null
    (
      systemctl --user daemon-reload
      systemctl --user default
    ) &
  fi
fi

注意到这里加入了对~/.Xauthority文件的处理,不然从图形界面登录时,执行挂载命令后,会因授权文件不见了而失败。之前把 $HOME 的权限设置成700也是为了这个。单纯地允许写~/.Xauthority不行,因为 xauth 需要创建临时文件以防止此文件同时被多个进程修改。

现在,我们需要在用户登录时自动 unwrap 之前创建的那个wrapped-passphrase文件。在/etc/pam.d/login中添加几行(注意顺序):

#%PAM-1.0
#...
auth                required        pam_unix.so nullok
auth                required        pam_ecryptfs.so unwrap
#...
password            required        pam_ecryptfs.so
#password           required        pam_unix.so sha512 shadow use_authtok
#...

好了,我们先手动试试:

# su user
$ ecryptfs-insert-wrapped-passphrase-into-keyring /home/user/.ecryptfs/wrapped-passphrase
Passphrase: [输入用户密码]
$ mount -i /home/user

如果正确挂载的话,接下来就可以开始建设你的新 $HOME 了,比如把你以前的各种文件复制过去,等等。注意不要在加密的目录内进行 BT 下载哦。你可以建立个/home/.ecryptfs/user/public目录然后软链接到 $HOME 内来使用。

我同时还修改了/etc/pam.d/slim,似乎这样才能在使用 slim 登录时也有效。

呃,还没有结束呢。得把之前的/home/profile.sh文件弄进来。这里演示时只是创建了一个新的.profile文件。如果你已经有了此文件的话,一定不要将其加密,而要将其与此挂载脚本合并。它只能不加密,否则挂载后会出现两个.profile(一个加密了的,一个未加密、passthrough 来的),从而导致一些问题。

# umount /home/user
# chmod 600 /home/profile.sh
# chown user:user /home/profile.sh
# mv /home/profile.sh /home/.ecryptfs/user/private/.profile
# ln -s /home/.ecryptfs/user/private/.profile /home/user/.profile

好了,到此一切结束。

Category: Linux | Tags: linux 安全
11
21
2010
0

Your Google Account

Gmail 钓鱼邮件

今收到的一个失败的钓鱼邮件。

PS:为什么Gmail没有提示此邮件可能存在欺诈什么的呢?

Category: 网络 | Tags: 安全 google

部分静态文件存储由又拍云存储提供。 | Theme: Aeros 2.0 by TheBuckmaker.com