postfix 的 SNI 支持与 gmail 的兼容问题
今天在家里的票务系统上修改某个票的状态（该操作会出发点一封邮件）时， 我正好另一个窗口开着邮件服务器的日志，观察到一些奇怪的现象：
| |
TLS
FreeBSD 上的 nginx kTLS 支持
昨天，FreeBSD 13.2 正式发布了。 kTLS 是在 FreeBSD 13.0 中由 Netflix 赞助的新功能， 过去，TLS/SSL 应用程序对于通讯内容的加解密通常是在用户态进行的，这样一来， 系统在读取出数据和发出数据之前需要进行额外的上下文切换，并在内核和用户地址空间之间来回复制缓冲区来满足加解密的需要。 有了 kTLS 之后，内核可以在 sendfile(2) 时直接在内核上下文中完成加密和填充到网络协议栈的操作，从而减少了上下文切换和不必要的复制操作。
India NIC签发未经授权的 Google SSL证书事件
详情参见 Google Online Security Blog。
说两个我认为比较有意思的事情：
第一个是 Google 并没有公布作为证据的证书。由于证书是以 CA 的私钥签署，因此这类未经授权的证书本身就可以作为证据。但是，Google这样做（不公布证书）意味着签发者不得不销毁全部签发的证书，而不仅仅是被公布的那些。
nginx的https压缩
为什么输入敏感数据（如登录信息）的页面也要做成 https？
有一种错误的观念是，对于不太敏感的内容（例如论坛之类），只要用 https 保护登录过程中提交密码的部分就足够了。例如国内非常流行的网易邮箱，很早以前便提供了"SSL安全登录"的选项，这样做显然是比完全不提供SSL登录选项的新浪邮箱要强多了[注1]，但是仍然是不够的。
nginx中的TLS/SSL配置
nginx可以作为很多种不同的用途。对Web服务器来说，nginx可以直接用作https服务器，也可以用于为现有的http Web服务器作为前端代理和负载平衡的同时提供https之用。
如何：申请用于服务器SSL/TLS的X.509证书
📓 注意
2015-03-05更新：本文中部分干货已过时，本文本身也不再更新。请参阅 这张作弊条。由于 ACME 协议的普及，现时通常只需生成密钥对即可。
SSL/TLS协议中，服务器证书是用于向客户端证明服务器身份的凭据，同时它还向用户提供了服务器的公钥，而服务器公钥则可以用来建立客户端到服务器的安全通讯（具体的通讯流程要比这个复杂，纯从技术而言，服务器的公钥主要用于与客户端进行会话密钥的协商）。
服务器的公钥只能确保拥有私钥的服务器（或人）能够解密信息，但它本身并不能确认服务器的身份。在实践中有很多种不同的方法来确保公钥确实来自受信任的服务器，在通常的SSL/TLS协商过程中，采用的方法是根据证书链来逐层验证公钥是否是有效的及其身份。简单地说，就是以安全的方法（例如安装光盘，或互相认证的签名等）事先将证书链上的某一个或某几个证书发给客户端，以便其验证最终用于服务器的安全证书。关于这一流程的具体细节，已经有很多文章进行了介绍，在此不再赘述。
如此，我们在实现采用SSL/TLS的服务器的时候，需要为证书准备的事项包括：
- 找到一家被客户端信任的、具备签发证书资质的发证机构。发证机构可以是根CA（对于浏览器来说，通常可以在安全选项中找到类似"查看证书"之类的选项），也可以是这些根CA认可的二级发证机构。
- 收集用于验证服务器身份的信息，例如服务器的FQDN，等
- 生成一对用于SSL/TLS的公钥/私钥。
有了这些信息，就可以制作证书申请（CSR）供发证机构去签名了。一般来说，发证机构需要首先验证申请人的身份信息，然后对CSR提交的信息进行核对和签名，并将签名之后的证书发给申请者，或供其下载。下面以 FreeBSD、OpenSSL 为例介绍从生成公钥/私钥对到签发、安装证书的全过程。
测试SSL
周末抽时间对网站做了一些调整。主要是把网站迁移到nginx上，不过遇到一些问题。Movable Type以FCGI::Spawn运行的时候，有时会反复出现先前的页面（例如，在mt.cgi上登录时，在提交登录之后仍会出现登录界面，而不是正常完成登录）。用ktrace看了一下FastCGI进程，结果发现之前看到的资料里面有相当多的小问题，但这个问题最终没有解决，暂时起了一个Apache来以cgi方式处理来绕过问题了。
端到端(End to End)加密与安全
说明：这篇文章希望能够以比较通俗的方式介绍一下相关的概念。
端到端加密，通常是指两个通信实体之间在会话通道基础上进行的、由两个实体之间协商的密文会话。端到端加密的好处是能够减少会话通道本身的泄密或其他问题导致两个通信实体之间的通讯遭到第三方破译，并避免通讯的对方对通讯内容抵赖（即，不承认通讯内容来自自己）。相对而言，端到端加密的实施成本要比单独架设一条物理的通讯线路要便宜许多，因此有时它也用于架设这类通讯线路。端到端加密本身不能阻止由于使用的会话通道本身的丢包导致的干扰。然而，由于端到端加密可以工作在较高的抽象层次上，它可以使用多个实际的会话通道而提高抗干扰能力。
通常我们会希望在一个安全系统中设置多个层次的安全设施，或者说类似"洋葱"的模型，例如，在系统中，将所有与安全有关的信息记录日志并放到不可擦除的介质上、对连接进行加密，和对发送的消息进行加密，这几种方法分别考虑的是不同级别的信息安全，而这些方法可以在同一个安全系统中作为其不同的保护层次来使用。在这一类模型中，我们不仅视阻止入侵为目标，同时也将检测入侵做为目标，或者换言之，每攻破系统中的一个层次，入侵者都需要付出额外的努力，并冒更大的被发现的风险才能达到这样的目标。
以邮件系统为例，传统的电子邮件系统是完全不使用任何加密或签名的手段的。拥有接入层控制权的网络管理员，可以轻易地通过在网络上监听数据包来获知用户与自己所使用的邮件服务器之间交换的邮件内容。随后，当邮件到达了邮件服务器时，邮件服务器管理员也可以很容易地知道邮件内容；在邮件服务器将邮件传送到互联网上的另一台邮件服务器时，问题就更多了，每一跳路由，以及它们所经过的所有网络都可以被监听，并将邮件内容泄漏出去；最后，在另一台服务器和收件人之间，也有和发件人这一边一样的风险。
在Internet上传输电子邮件的过程，由于其经过的环节众多，并且几乎完全不受收发邮件的双方控制，因此很容易导致一些敏感信息的泄露。针对这种问题，人们设计出了一种叫做Transport Layer Security（TLS，用于替代SSL）的密码学协议来实现服务器之间，以及客户端到服务器的端到端安全。简而言之，这套协议首先使用公钥加密算法在通讯双方之间协商一个会话密钥，并用这个密钥完成之后的通讯加密/解密。公钥加密算法是一种加密和解密时使用不同密钥的加密算法，以对方公开密钥加密的数据，只能以（不公开的）解密密钥解密，而从公开密钥或已知明文、密文推算出解密密钥的代价非常大，因此它能够确保数据只能被"正确的"那个接收方解密。
Apache中同一IP多个HTTPS虚拟主机的实现
在 Apache 文档中提到，不能在单个 IP 上同时有多个按名字识别的虚拟主机(“named virtual host”)。不完全是这样。
HTTPS协议的过程是：服务器首先与客户机之间进行服务器身份验证并协商安全会话，然后，客户端向服务器发送 HTTP 请求。这样一来，在客户端开始发送请求之前，服务器就已经把证书发给了客户端（客户端根据本地的根证书去验证证书链，等等）。而最重要的是，为了表明身份，这个证书的周知名称（“Common Name”）填写的应该是域名，否则浏览器会给出警告。