TLS
今天在家里的票务系统上修改某个票的状态（该操作会出发点一封邮件）时，
我正好另一个窗口开着邮件服务器的日志，观察到一些奇怪的现象：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
gmail-smtp-in.l.google.com[2607:f8b0:4023:1c03::1a]:25: self-signed certificate
Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
to gmail-smtp-in.l.google.com[2607:f8b0:4023:1c03::1a]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
(2048 bits) server-digest SHA256
Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
gmail-smtp-in.l.google.com[142.250.142.26]:25: self-signed certificate
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
to gmail-smtp-in.l.google.com[142.250.142.26]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
(256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
alt1.gmail-smtp-in.l.google.com[142.250.115.27]:25: self-signed certificate
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
to alt1.gmail-smtp-in.l.google.com[142.250.115.27]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
(2048 bits) server-digest SHA256
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
alt1.gmail-smtp-in.l.google.com[2607:f8b0:4023:1004::1b]:25: self-signed certificate
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established to
alt1.gmail-smtp-in.l.google.com[2607:f8b0:4023:1004::1b]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
(2048 bits) server-digest SHA256
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: Verified TLS connection established to
alt2.gmail-smtp-in.l.google.com[2607:f8b0:4003:c15::1b]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA
(prime256v1) server-digest SHA256
Mar 19 20:17:15 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: to=<XXXXXXX@gmail.com>,
relay=alt2.gmail-smtp-in.l.google.com[2607:f8b0:4003:c15::1b]:25, delay=2.8,
delays=0.06/0.1/2/0.66, dsn=2.0.0, status=sent (250 2.0.0 OK XXXXXXXXXX
XXXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.XX - gsmtp)
|
昨天，FreeBSD 13.2 正式发布了。
kTLS 是在 FreeBSD 13.0 中由 Netflix 赞助的新功能，
过去，TLS/SSL 应用程序对于通讯内容的加解密通常是在用户态进行的，这样一来，
系统在读取出数据和发出数据之前需要进行额外的上下文切换，并在内核和用户地址空间之间来回复制缓冲区来满足加解密的需要。
有了 kTLS 之后，内核可以在 sendfile(2)
时直接在内核上下文中完成加密和填充到网络协议栈的操作，从而减少了上下文切换和不必要的复制操作。
阅读全文…(
本文约 832 字，阅读大致需要 2 分钟
)Let’s Encrypt 是我目前使用的证书发证机构。早上 yegle
提到了某个bug，于是研究了一下，这里记一笔，算是留个历史见证吧。
发生了什么
在 PKI 证书体系中，信任是通过逐级签名以及对这些签名的验证来实现的。
对大部分客户端系统来说，这些系统中会存在一个或多个受信的根证书发证机构的证书，
其公钥是通过这些系统本身的更新机制派发的。
根证书发证机构的证书通常是自签名的，更新相对来说比较麻烦（它通常依赖于操作系统的在线或离线更新机制），
因此这些证书的私钥事关重大，因此人们通常不希望经常更新它们，因而证书发证机构在绝大多数时候并不会使用这些私钥来签署证书。
取而代之的是，他们会创建一些称为中级发证机构的证书用来签署日常的证书，这样根证书的私钥可以采用更为严密的方法来保护，
例如可以把它们从网络上彻底断开，而中级发证机构的证书则可以以较高的频率进行密钥轮换，借此来避免其私钥暴露导致的风险。
一个新的发证机构进入市场时，其自签名的根证书往往不会被已经在市场上的客户端系统认可，
因此这样一来新的发证机构想要获得用户就必须想办法解决能被用户承认这个问题。
一旦获得了一定的知名度并证明了自己的可靠性，
这些发证机构便可以遵循一定的流程获得主流浏览器或操作系统的认可，
并将自己的根证书也加入到它们的受信根证书列表中了。
所以，在起步阶段，新的发证机构往往会要求一些已经存在的根证书去对其根证书进行交叉签署，
在客户端验证证书有效性时，由于这些根证书在他们看来是一个经过了受信根证书签名的中级证书而不是一个普通的不受信自签名根证书，
因此也就不会给出无法验证证书是否有效的提示，而是能够正确地对其有效性进行验证了。
Let’s Encrypt 在起步阶段正是采用了这种做法。通俗地说，它的中级发证机构的证书被两家根证书机构同时签名，
其一是它自己的 ISRG Root，另一个是另一家根证书机构 IdenTrust 的 DST Root X3。初期，由于 DST Root X3
已经被许多操作系统和浏览器认证过，因此为其普及起到了非常重要的作用。
UTC 时间 2021年9月29日 19:21:40，DST Root X3 的根证书过期了。这样一来，这一边的信任链便不再成立。
阅读全文…(
本文约 1605 字，阅读大致需要 4 分钟
)在 Apache 文档中提到，不能在单个 IP 上同时有多个按名字识别的虚拟主机(“named virtual host”)。不完全是这样。
HTTPS协议的过程是：服务器首先与客户机之间进行服务器身份验证并协商安全会话，然后，客户端向服务器发送 HTTP 请求。这样一来，在客户端开始发送请求之前，服务器就已经把证书发给了客户端（客户端根据本地的根证书去验证证书链，等等）。而最重要的是，为了表明身份，这个证书的周知名称（“Common Name”）填写的应该是域名，否则浏览器会给出警告。
阅读全文…(
本文约 800 字，阅读大致需要 2 分钟
)