依云's Blog

YubiKey 支持多种协议，或者说使用方式、模式，ykman 里称作「application」（应用程序）。很多程序支持多种 application。本文按 application 分节，记录一些自己的研究结果，并不全面。要全面的话，还请参考 ArchWiki 的 YubiKey 页面或者 YubiKey 官方文档。

在 Arch Linux 上，YubiKey 插上就可以用了，不需要特别的驱动方面的设置。有可能某些程序需要装个 libfido2 包来使用它。

Yubico OTP

插上之后，它会有一个键盘设备。摸一下，它就发送一长串字符然后回车。这串字符每次都不一样，并且需要与 Yubico 的服务器通信来验证是否有效。这串字符使用 AES 对称加密，也就意味着 Yubico 服务器也有私钥（你也可以自建服务器自己用）。

所以这是个没什么用的功能。并且在拔下设备时很容易误触，插到 Android 设备上之后输入法的屏幕键盘还可能不出来。所以我把它给禁用了：

ykman config mode FIDO+CCID

FIDO2 / U2F

这个 application 在 Android 上第一次使用的时候会提示设置 PIN。我已经设置好了，也不知道在电脑上会如何。需要注意的是，这个 PIN 可以使用字母，并不需要是纯数字。最多可以连续输错八次，但没有 PIN 被锁之后用来解锁的 PUK。

WebAuthn / Passkey

插上就可以在火狐和 Google Chrome 里使用了。可以在 https://webauthn.io/ 测试。作为可以直接登录的 passkey 使用的话，会要求输入 PIN 和触摸。如果仅仅是作为二步验证使用（比如 GitHub），则只需要触摸即可。

Android 上也是差不多的。不过 Android 支持把 passkey 存储在设备里（还会通过 Google 账号同步），使用 YubiKey 时需要从弹窗中选取「使用其它设备」。如果网站已经在设备里存储了 passkey，那么没有使用 YubiKey 的机会。

SSH

OpenSSH 客户端需要安装 libfido2 包才能支持这些 -sk 结尾的 key。服务端不需要这个库。

有多个选项，具体参见 SSH Resident Key Guide。我总结了两种比较好的使用方式：

ssh-keygen -t ed25519-sk -O resident -O verify-required
ssh-keygen -t ed25519-sk -O no-touch-required

可以选择的 key 类型只有ecdsa-sk和ed25519-sk，并不支持 RSA。resident选项是把 key 存储到 YubiKey 上，之后可以通过ssh-keygen -K下载回来。如果不加这个选项的话，那么仅凭 YubiKey 是无法使用的，得同时有生成的文件。verify-required是验证 PIN。默认是需要触摸的，可以用no-touch-required选项关闭，但是需要服务端在 authorized_keys 里设置这个选项。

从安全角度考虑，如果 YubiKey 丢失，那么仅凭该设备不应当能获得任何权限——所以在使用 resident 密钥时必须验证 PIN（我总不能赌偷或者捡到的人猜不中我的用户名或者访问的服务器吧）。这与自动化执行 SSH 命令相冲突。另一种使用方式，不需要 PIN、不需要触摸，倒是很方便自动化，也可以防止私钥被运行的程序偷走或者自己失误泄露，但是需要服务端设置no-touch-required选项，而 GitHub 和 GitLab 并不支持。倒是可以不同场合使用不同的 key，但是管理起来太复杂了。

resident 密钥倒是可以使用 ssh-add 加载到 ssh-agent 里，之后应该就不需要交互即可使用了。但我现在启动系统要输入硬盘密码，登录到桌面并日常使用的话，还要输入用户密码和火狐主密码，已经够多了，不想再加一个 PIN。所以我还是不用了吧。

我倒是想给 termux 里的 ssh 用 YubiKey，毕竟手机上一堆乱七八糟的闭源程序，外加系统已经失去更新，感觉不怎么安全。但是搜了一圈看起来并不支持。

PAM

安装 pam_u2f 包，然后使用 pamu2fcfg 生成个文件。最后去改 PAM 配置就好啦，比如在 /etc/pam.d/sudo 开头加上

auth            sufficient      pam_u2f.so cue userpresence=1

这样会用触摸 YubiKey 来认证用户。如果把 YubiKey 拔了，pam_u2f 会被跳过。但是 YubiKey 正常的情况下，没有办法跳过 pam_u2f，所以通过 ssh 登录的时候会很难受……好吧，用 pam_exec 还是有办法跳过的，但是它似乎读不到环境变量，只能放个文件来控制，所以还是很麻烦。最好的办法是我在 pam_u2f 运行的时候按一下 Ctrl-C，它就放弃掉就好了，但这个 issue 已经等了快要六年了。

LUKS

cryptsetup 并不直接支持 FIDO2。要使用 systemd-cryptenroll 来添加 keyslot：

sudo systemd-cryptenroll --fido2-device=auto /dev/disk/by-partlabel/XXX

可以用sudo cryptsetup luksDump /dev/disk/by-partlabel/XXX命令看到 systemd 不光添加了一个 keyslot，还同时添加了一个 token 用于存储一些配置信息。

解密：

sudo systemd-cryptsetup attach XXX /dev/disk/by-partlabel/XXX '' fido2-device=auto

或者用 cryptsetup open 也行。但因为添加的 slot 是需要 PIN 的，cryptsetup open 不加 token 相关的选项时会跳过该 slot，直接问你密码。

sudo cryptsetup open --token-only /dev/disk/by-partlabel/XXX XXX

配置好之后，解密 LUKS 设备就不需要输入又长又复杂的密码啦。不过最好还是时不时验证一下自己还记得密码，要是需要用的时候才发现密码因为长期不用而遗忘了就不妙了。我的系统硬盘本来解密的次数就少，就不用它了，只给备份硬盘用了。

OpenPGP

ykman 要管理 OpenPGP 智能卡应用，需要启用 pcscd 服务，但是 GnuPG 可以不用它。

sudo systemctl enable --now pcscd.socket

要让 ykman 和 GnuPG 能同时访问 YubiKey，可能还需要以下设置：

pcsc-driver /usr/lib/libpcsclite.so
card-timeout 5
disable-ccid
pcsc-shared

YubiKey 所有不同 application 的 PIN 是分开的。OpenPGP application 有 PIN 和管理 PIN，默认各能试三次。使用 key 的时候会用到 PIN，导入 key 的时候会用到管理 PIN。初次使用的时候记得用ykman openpgp access命令把默认的 123456 和 12345678 都给改了（不知道为什么我没找到在gpg --card-edit里更改管理 PIN 的方法）。导入的教程可以参考官方文档的 Importing keys。我的型号是 YubiKey 5C Nano，是支持 ed25519 / cv25519 算法的。

把 key 导入到 YubiKey 之后，可以再用ykman openpgp keys set-touch设置一下哪些操作需要触摸。默认是都不需要的。然后正常使用就可以了。

要注意的是，YubiKey 只存储了私钥，所以本地要有公钥才可以正常使用。所以要换个系统使用的话，一种办法是把公钥上传到 OpenPGP 服务器上然后导入，另一种办法是自己导出成文件再导入。

SSH 也可以用 OpenPGP 密钥，所以也能用 YubiKey 上的 OpenPGP 密钥。甚至还能把现有的 ed25519 SSH key 导入进去用（不过我没有尝试）。

PIV

这个 PIV 涉及 PKCS#11，有点复杂。暂时不想研究。

去年我做了个索引 Telegram 群组的软件——落絮，终于可以搜索到群里的中文消息了。然而后来发现，好多消息群友都是通过截图发送的，落絮就索引不到了。也不能不让人截图嘛，毕竟很多人描述能力有限，甚至让复制粘贴都能粘出错，截图就相对客观真实可靠多了。

所以落絮想要 OCR。我知道百度有 OCR 服务，但是我显然不会在落絮上使用。我平常使用的 OCR 工具是 tesseract，不少开源软件也用的它。它对英文的识别能力还可以，尤其是可自定义字符集所以识别 IP 地址的效果非常好，但是对中文的识别能力不怎么样，图片稍有不清晰（比如被 Telegram JPEG 压缩）、变形（比如拍照），它就乱得一塌糊涂，就不说它给汉字之间加空格是啥奇怪行为了。

后来听群友说 PaddleOCR 的中文识别效果非常好。我实际测试了一下，确实相当不错，而且完全离线工作还开源。但是，开源是开源了，我又没能力审查它所有的代码，用户量太小也不能指望「有足够多的眼睛」。作为基于机器学习的软件，它也继承了该领域十分复杂难解的构建过程，甚至依赖了个叫「opencv-contrib-python」的自带了 ffmpeg、Qt5、OpenSSL、XCB 各种库的、不知道干什么的组件，试图编译某个旧版 numpy 结果由于太旧不支持 Python 3.10 而失败。所以我决定在 Debian chroot 里安装，那边有 Python 3.9 可以直接使用预编译包。所以问题来了：这么一大堆来源不明的二进制库，用起来真的安全吗？

我不知道。但是我知道，如果它联不上网的话，那还是相对安全的。毕竟我最关心的就是隐私安全——一定不能把群友发的图片泄漏给未知的第三方。而且联不上网的话，不管你是要 DDoS 别人、还是想挖矿，收不到指令、传不出数据，都行不通了嘛。我只要它能从外界读取图片，然后把识别的结果返回给我就好了。

于是一个简单的办法是，拿 bwrap 给它个只能访问自己的独立网络空间它不就访问不了互联网了吗？不过说起来简单，做起来还真不容易。首先，debootstrap 需要使用 root 执行，执行完之后再 chown。为了进一步限制权限，我使用了 subuid，但这也使得事情复杂了起来——我自己都难以访问到它了。几经摸索，我找到了让我进入这个 chroot 环境的方法：

#!/bin/bash -e

user="$(id -un)"
group="$(id -gn)"

# Create a new user namespace in the background with a dummy process just to
# keep it alive.
unshare -U sh -c "sleep 30" &
child_pid=$!

# Set {uid,gid}_map in new user namespace to max allowed range.
# Need to have appropriate entries for user in /etc/subuid and /etc/subgid.
# shellcheck disable=SC2046
newuidmap $child_pid 0 $(grep "^${user}:" /etc/subuid | cut -d : -f 2- | tr : ' ')
# shellcheck disable=SC2046
newgidmap $child_pid 0 $(grep "^${group}:" /etc/subgid | cut -d : -f 2- | tr : ' ')

# Tell Bubblewrap to use our user namespace through fd 5.
5< /proc/$child_pid/ns/user bwrap \
  --userns 5 \
  --cap-add ALL \
  --uid 0 \
  --gid 0 \
  --unshare-ipc --unshare-pid --unshare-uts --unshare-cgroup --share-net \
  --die-with-parent --bind ~/rootfs-debian / --tmpfs /sys --tmpfs /tmp --tmpfs /run --proc /proc --dev /dev \
  -- \
  /bin/bash -l

这里给了联网权限，是因为我需要安装 PaddleOCR。没有在创建好 chroot 之后、chown 之前安装，是因为我觉得拿着虽然在 chroot 里但依旧真实的 root 权限装不信任的软件实在是风险太大了。装好之后，再随便找个图，每种语言都识别一遍，让它下载好各种语言的模型，接下来它就再也上不了网啦（为避免恶意代码储存数据在有网的时候再发送）：

#!/bin/bash -e

dir="$(dirname $2)"
file="$(basename $2)"

user="$(id -un)"
group="$(id -gn)"

# Create a new user namespace in the background with a dummy process just to
# keep it alive.
unshare -U sh -c "sleep 30" &
child_pid=$!

# Set {uid,gid}_map in new user namespace to max allowed range.
# Need to have appropriate entries for user in /etc/subuid and /etc/subgid.
# shellcheck disable=SC2046
newuidmap $child_pid 0 $(grep "^${user}:" /etc/subuid | cut -d : -f 2- | tr : ' ')
# shellcheck disable=SC2046
newgidmap $child_pid 0 $(grep "^${group}:" /etc/subgid | cut -d : -f 2- | tr : ' ')

# Tell Bubblewrap to use our user namespace through fd 5.
5< /proc/$child_pid/ns/user bwrap \
  --userns 5 \
  --uid 1000 \
  --gid 1000 \
  --unshare-ipc --unshare-pid --unshare-uts --unshare-cgroup --unshare-net \
  --die-with-parent --bind ~/rootfs-debian / --tmpfs /sys --tmpfs /tmp --tmpfs /run --proc /proc --dev /dev \
  --ro-bind "$dir" /workspace --chdir /workspace \
  --setenv PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
  --setenv HOME /home/worker \
  -- \
  /home/worker/paddleocr/ocr.py "$1" "$file"

kill $child_pid

这个脚本会把指定文件所在的目录挂载到 chroot 内部，然后对着这个文件调用 PaddleOCR 来识别并通过返回结果。这个调用 PaddleOCR 的 ocr.py 脚本位于我的 paddleocr-web 项目。

不过这也太复杂了。后来我又使用 systemd 做了个服务，简单多了：

[Unit]
Description=PaddleOCR HTTP service

[Service]
Type=exec
RootDirectory=/var/lib/machines/lxc-debian/
ExecStart=/home/lilydjwg/PaddleOCR/paddleocr-http --loglevel=warn -j 2
Restart=on-failure
RestartSec=5s

User=1000
NoNewPrivileges=true
PrivateTmp=true
CapabilityBoundingSet=
IPAddressAllow=localhost
IPAddressDeny=any
SocketBindAllow=tcp:端口号
SocketBindDeny=any
SystemCallArchitectures=native
SystemCallFilter=~connect

[Install]
WantedBy=multi-user.target

这里的「paddleocr-http」脚本就是 paddleocr-web 里那个「server.py」。

但它的防护力也差了一些。首先这里只限制了它只能访问本地网络，TCP 方面只允许它绑定指定的端口、不允许调用 connect 系统调用，但是它依旧能向本地发送 UDP 包。其次运行这个进程的用户就是我自己的用户，虽然被 chroot 到了容器里应该出不来。嗯，我大概应该给它换个用户，比如 uid 1500，应该能起到跟 subuid 差不多的效果。

顺便提一句，这个 PaddleOCR 说的是支持那么多种语言，但实际上只有简体中文等少数语言支持得好（繁体都不怎么样），别的语言甚至连语言名和缩写都弄错，越南语识别出来附加符号几乎全军覆没。

bwrap 是命令的名字。这个项目的名字叫 bubblewrap。它是一个使用 Linux 命名空间的非特权沙盒（有用户命名空间支持的话）。

我之前使用过 Gentoo 的 sandbox 工具。它是 Gentoo 用于打包的工具，使用的是 LD_PRELOAD 机制，所以并不可靠。主要用途也就是避免打包软件的时候不小心污染到用户家目录。

使用 bwrap 的话，限制是强制的，没那么容易绕过（至于像 Go 这种因为不使用 libc 而意外绕过就更难得了）。不过 bwrap 不会在触发限制的时候报错。

bwrap 的原理是，把 / 放到一个 tmpfs 上，然后需要允许访问的目录通过 bind mount 弄进来。所以没弄进来的部分就是不存在，写数据的话就存在内存里，用完就扔掉了。这一点和 systemd 也不一样——systemd 会把不允许的地方挂载一个没权限访问的目录过去。

bwrap 的挂载分为只读和可写挂载。默认是 nodev 的，所以在里边是不能挂载硬盘设备啥的。它也提供最简 /proc 和 /dev，需要手动指定。整个 / 都是通过命令行来一点点填充内容的，所以很容易漏掉部分内容（比如需要联网的时候忘记挂载 resolv.conf 或者 TLS 证书），而不会不小心允许不应当允许访问的地方（当然前提是不偷懒直接把外面的 / 挂载过去啦）。

至于别的命名空间，有 --unshare-all 选项，不用写一堆了。如果需要网络，就加个 --share-net（这个选项文档里没写）。没有别的网络方案，因为没特权，不能对网络接口进行各种操作。--die-with-parent 可以保证不会有残留进程一直跑着。

我目前的打包命令长这样：

alias makepkg='bwrap --unshare-all --share-net --die-with-parent \
  --ro-bind /usr /usr --ro-bind /etc /etc --proc /proc --dev /dev \
  --symlink usr/bin /bin --symlink usr/bin /sbin --symlink usr/lib /lib --symlink usr/lib /lib64 \
  --bind $PWD /build/${PWD:t} --ro-bind /var/lib/pacman /var/lib/pacman --ro-bind ~/.ccache ~/.ccache \
  --bind ~/.cache/ccache ~/.cache/ccache --chdir /build/${PWD:t} /usr/bin/makepkg'

以后应该随着问题的出现还会修改的。

其实我学 bwrap 主要不是自己打包啦（毕竟基本上都交给 lilac 了），而是给 lilac 加固。Arch 的打包脚本是 shell 脚本，所以很多时候不执行脚本就没办法获取一些信息、进行某些操作。唉，这些发行版都喜欢糙快猛的风格，然后在上边打各种补丁。deb 和 rpm 的打包也都是基于 shell 脚本的。而 lilac 经常通过脚本编辑打包脚本，或者从 AUR 取，万一出点事情，把不该删的东西给删掉了，或者把私钥给上传了，就不好了。所以前些天我给 lilac 执行 PKGBUILD 的地方全部加上了 bwrap。期间还发现 makepkg --printsrcinfo 不就是读取 PKGBUILD 然后打印点信息嘛，竟然不断要求读取 install 脚本，还要对打包目录可写……

另一个用法是，跑不那么干净的软件。有些软件不得不用，又害怕它在自己家里拉屎，就可以让它在沙盒里放肆了。比如使用反斜杠作为文件路径分隔符写一堆奇怪文件名的 WPS Office。再比如不确定软件会不会到处拉屎，所以事先确认一下。我以前使用的是基于 systemd-nspawn 和 overlayfs 的方案（改进自基于 aufs 和 lxc 的方案所以名字没改），不过显然 bwrap 更轻量一些。跑 GUI 的话，我用的命令长这样：

bwrap --unshare-all --die-with-parent --ro-bind / / \
  --tmpfs /sys --tmpfs /home --tmpfs /tmp --tmpfs /run --proc /proc --dev /dev \
  --ro-bind ~/.fonts ~/.fonts --ro-bind ~/.config/fontconfig ~/.config/fontconfig \
  --bind ~/.cache/fontconfig ~/.cache/fontconfig --ro-bind ~/.Xauthority ~/.Xauthority \
  --ro-bind /tmp/.X11-unix /tmp/.X11-unix --ro-bind /run/user/$UID/bus /run/user/$UID/bus \
  --chdir ~ /bin/bash

其实还可以用来给别的发行版编译东西，取代我之前使用 systemd-nspawn 的方案。bwrap 在命令行上指定如何挂载，倒是十分方便灵活，很适合这种需要共享工作目录的情况呢。以后有需要的时候我再试试看。（好像一般人都是使用 docker / podman 的，但是我喜欢使用自己建立和维护的 rootfs，便于开发和调试，也更安全。）

和 bwrap 类似的工具还有 SELinux 和 AppArmor。它们是作用于整个系统的，Arch Linux 安装会很麻烦，对于我的需求也过于复杂。Firejail 是面向应用程序的，但是配置起来也挺不容易。bwrap 更偏重于提供底层功能而不是完整的解决方案，具体用法可以让用户自由发挥。

最近学 wzyboy 搭了一套 collectd + Graphite + Grafana 监控。collectd 和 Grafana 都比较好搞，Arch 官方源里有。但是 Graphite 就没有了。

我没有使用 Python 2 版、带 Web 前端的 Graphite 包，而是使用 graphite-api 提供 Web API，python2-carbon 存储数据。它们在 AUR 上有，其中 python2-carbon 是相当危险的（现在已经改了）。

为什么危险呢？

首先，最明显的，carbon 服务以 root 用户运行。它本身没有任何使用 root 权限的必要，所以专门创建一个 carbon 用户更好。

其次，它运行起来之后，我发现是监听 0.0.0.0 的。这个也无必要：我的 collectd 就在本地呢。

最后，也是最吓人的：它默认开启了接收 pickle 数据的端口。Python pickle 模块的文档一打开，就能看到红色的警告，告诉人们不能接收不信任来源的 pickle 数据。而我曾经工作过的公司也发生过通过 pickle 注入代码的事情：攻击者发现了一个对外网开放的 Redis 服务，刚好那个 Redis 是给 Celery 用的。攻击者于是往里边写了条自己构造的 pickle，在解析时调用 curl 命令向其服务器报告IP、端口和当前UNIX用户的信息。

这接口，开在外网，就是远程代码招行；开在本地，就是本地提权。很危险的。

为了防止各种漏洞被利用，一个未雨绸缪的办法就是：权限最小化。本来这是件比较麻烦的事情，好在 systemd 提供了许多现成的配置项，使得给 carbon 这种服务加固简单易行。

首先创建用户，写一个 sysusers 文件就可以了：

u carbon - "carbon service" /var/lib/carbon

然后，它需要使用文件系统的某些部分。那么别的就用不着访问了，比如 /home。而 /dev、/tmp 这些，自己用自己的就好。连 / 也不让写，也不允许获取任何新特权了。其实使用 carbon 用户它本来就写不了 / 也没有任何特权了，但以防万一嘛，要是哪里来个本地提权漏洞呢？

[Unit]
Description=Graphite/Carbon
After=network.target

[Service]
Type=forking
ExecStart=/usr/bin/carbon-cache.py --config=/etc/carbon/carbon.conf start
User=carbon

PrivateTmp=true
PrivateDevices=true
ProtectSystem=full
ProtectHome=true
NoNewPrivileges=true
CapabilityBoundingSet=

ReadOnlyPaths=/
ReadWritePaths=/run
ReadWritePaths=/var/log/carbon
ReadWritePaths=/var/lib/carbon

[Install]
WantedBy=multi-user.target

限制文件系统的访问，systemd 配置起来很方便，我打包的时候喜欢尽量加上。

完整的 python2-carbon 服务配置和打包脚本在这里。

以及，这里是 Arch Linux 中文社区的编译机的 Grafana。

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 邮件列表。

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 的原因之后就可以很快找到遇到同样问题的人了，比如：

• 【吐槽】gist.github.com疑遭中间人攻击 - ahdung - 博客园
• 部分网站跳转CJB问题求教.................._firefox吧_百度贴吧
• 为什么访问 XDA 总被跳转至 cjb.net？ - V2EX

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

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

真的是这样吗？

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

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

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

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

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

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

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

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

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

那要怎么用12306呢？

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

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

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

其它链接

• 12306的证书问题 - JayXon

昨天有朋友说支付宝官网 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 传统，文本的每一行以换行符结束。而微软的做法是，换行符仅仅作为两个行中间的分隔符，最后一行并不以换行符结束，所以在连接多个文件时会因为缺少换行符而出错。

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

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

再去 Google 搜索一下，果然也被标记上了：

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

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

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

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

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

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

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

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

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

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

启动 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 给我带来了一堆麻烦，却没能解决我遇到的任何问题！