@Lenciel

开启 OCSP Stapling

之前有人抱怨这个小破站打开慢。

我想我这种 lighthouse 打满分的同学,怎么可能…结果发现,是因为 Let’s Enrypt 用来做 OCSP 验证的域名被众所周知的力量污染了(目前是 ocsp.int-x3.letsencrypt.org 的 CName 域名 a771.dscq.akamai.net 受到了干扰),所以 iOS 客户端的同学都会卡几秒钟做校验。

网上有很多通过打开 OCSP Stapling 来解决问题的帖子。但实际上,如果你的服务器在国内,是拿不到 OCSP Response 的。

当时我乐观地觉得,这种让所有 Let’s Encrypt 证书网站都不要玩儿的污染持续不了多久,先不管它吧。

然后三个月过去了。

所以在国内服务器上,如果你和我一样使用 nginx,只是正常开启 OCSP Stapling 的话:

# OSCP
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/lenciel.com/chain.pem;

重启 nginx 之后你用 openssl 的命令检查 OSCP Stapling 是否开启(可以用 SSL Labs 但是比较慢)会看到下面的输出,表明开启失败:

$ openssl s_client -connect lenciel.com:443 -servername lenciel.com -status -tlsextdebug < /dev/null 2>&1 | grep -i "OCSP response"

OCSP response: no response sent

我看网上很多同学在苦苦追问为啥失败。其实不是你的配置失败,而是你的服务器的户口所在地比较失败,如果去 Nginx 的日志里面检查就会看到大量因为收不到 responder 的报错:

2020/09/28 11:27:39 [error] 22565#0: OCSP responder timed out (110: Connection timed out) while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, peer: 108.160.167.30:80, certificate: "/etc/letsencrypt/live/lenciel.com-0001/fullchain.pem"
2020/09/28 11:35:29 [error] 22564#0: OCSP responder timed out (110: Connection timed out) while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, peer: 108.160.167.30:80, certificate: "/etc/letsencrypt/live/lenciel.com-0001/fullchain.pem"

解决起来有各种办法,说白了就是要让你这台服务器正常访问到 ocsp.int-x3.letsencrypt.org。我选择了 doh-proxy

再检查就可以看到访问成功了:

$ openssl s_client -connect lenciel.com:443 -servername lenciel.com -status -tlsextdebug < /dev/null 2>&1 | grep -i "OCSP response"
OCSP response:
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response

需要注意的是,和所有缓存一样,它设置成功之后需要几次访问才会刷新,以及,它会过期…通过一些简单的脚本可以把这部分也自动化了。

The Quick Chat Protocol

之前说过,远程办公不容易。今天偶然看到 Thomas A. Limoncelli 总结的疫情期间 Stack Overflow 在远程情况下保持效率的几个技巧

  • If Anyone is Remote, We’re All Remote
  • Accurate Chat Status
  • The Quick Chat Protocol
  • Idling in a Videoconference Room
  • Let’s Stop Apologizing for Normality

感觉也不是所有的我都赞成,比如第四条,让大家远程的时候都加到一个会议里把视频开着上班,这得让在意自己形象的同事负担多大啊:收拾屋子打扮自己保持仪态,都挺耗精力的。

但第三条是我特别赞成的,并且我觉得跟远程不远程没有关系,所以拿出来讲一下。

The Quick Chat Protocol

快速沟通协议,就是大家约定好在线上的沟通使用类似于线下的说话方式,快速进入主题。

现实生活里,你走到 fab 旁边问:「在忙吗,聊聊基友立的股四头肌?」,如果他有空,你们就可以开始了。

但是一旦到了企业微信这类线上的沟通环境里,人们会不由自主地觉得这是会留下记录的偏「正式」的沟通。于是,出于礼貌等各种方面的考虑,对话会变得极其复杂:

「在吗?」

「在。」

「有空吗?」

「有。」

「我有一个关于基友立的问题。」

「好的。」

「如果你方便的话我们聊聊?」

「是基友立的哪方面?」

「是他的股四头肌。」

「WOW,我们是视频还是语音还是文字?」

「…」

当我们像这样对时间、地点、方式、内容挨个商量的时候,往往会失去进行下去的动力。

如果沟通的双方或者多方达成一致,使用下面这种压缩的,类似于线下走到对方座位上时使用的沟通方式,那么大家都可以从中获益:

「聊聊基友立的股四头肌有时间吗?」

「我在忙,下午四点到六点 zoom 一下?」

「好,四点半吧。我的 zoom 会议连接:…」

除非对面是特别不熟悉的人,绝大多数的线上沟通都应该采用这样的形式。这虽然看起来是一个小改动,但每天进行的讨论如果大部分都以这样的方式进行,节约的不仅仅是大量的时间,还有大量的情绪成本。