TLS

共 22 篇文章。

关掉了 Google 账户的 passkey

2023-05-23 21:57 • Security

最近， Google 账户新增了一种叫做 passkey 的登录方式。

传统的采用密码登录的登录方式中，用户需要用某种方式证明自己知道密码，而绝大多数实现中这意味着网站必须保存用户的密码，或是密码的 hash 值（通常是HMAC），这意味着网站如果发生了拖库的情况，有可能会将用户的密码或其 hash 值泄漏出去。此外，用户可能必须输入密码，并将密码通过某种方式传输到服务器上，这样一来在这个过程中便有可能由于本地的木马，或是网站采用的 SSL/TLS 实现的漏洞导致密码泄漏。除此之外，即使用户十分小心地在每一个不同的网站都使用了不同的密码，他们仍然需要担心被「钓鱼」的问题，所谓「钓鱼」是这样一种攻击方式：攻击者架设一个看起来很像是用户希望登录的网站的网站，并诱骗用户输入密码。

阅读全文… ( 本文约 1697 字，阅读大致需要 4 分钟 )

FreeBSD 上的 nginx kTLS 支持

2023-04-11 21:19 • Security

昨天，FreeBSD 13.2 正式发布了。kTLS 是在 FreeBSD 13.0 中由 Netflix 赞助的新功能，过去，TLS/SSL 应用程序对于通讯内容的加解密通常是在用户态进行的，这样一来，系统在读取出数据和发出数据之前需要进行额外的上下文切换，并在内核和用户地址空间之间来回复制缓冲区来满足加解密的需要。有了 kTLS 之后，内核可以在 sendfile(2) 时直接在内核上下文中完成加密和填充到网络协议栈的操作，从而减少了上下文切换和不必要的复制操作。

阅读全文… ( 本文约 836 字，阅读大致需要 2 分钟 )

Let's Encrypt SSL证书失效问题

2021-09-30 23:37 • Security

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 的根证书过期了。这样一来，这一边的信任链便不再成立。

阅读全文… ( 本文约 1606 字，阅读大致需要 4 分钟 )

India NIC签发未经授权的 Google SSL证书事件

2014-07-11 18:18 • Security

详情参见 Google Online Security Blog。

说两个我认为比较有意思的事情：

第一个是 Google 并没有公布作为证据的证书。由于证书是以 CA 的私钥签署，因此这类未经授权的证书本身就可以作为证据。但是，Google这样做（不公布证书）意味着签发者不得不销毁全部签发的证书，而不仅仅是被公布的那些。

阅读全文… ( 本文约 362 字，阅读大致需要 1 分钟 )

OpenSSL 的新一批漏洞

2014-06-06 00:47 • Security

今天早上4点多就爬起来准备发安全公告（友商约的是早上5点发），一刷，OpenSSL官方已经正式发表了（时间大约是4点30），于是立即开始相关手续，commit修正，发公告，通知CERT，这些不表。

阅读全文… ( 本文约 779 字，阅读大致需要 2 分钟 )

nginx的https压缩

2012-07-24 05:31 • Security

官方版本的 nginx 在 https 的时候是不对流量做压缩的，具体原因在这里和这里有解释，它会增加半兆的连接内存开销。

启用 https 压缩除了需要 nginx 本身做少量修改（例如去掉 if[n]def SSL_OP_NO_COMPRESSION 部分的语句块）之外，还需要 OpenSSL 本身编译了加密支持。FreeBSD ports 的 security/openssl 预设启用了 ZLIB 扩展，但基本系统目前没有（由于 zlib 是很大的一片代码，也许需要做了 Capsicum 处理之后才可以放进来用）。

阅读全文… ( 本文约 286 字，阅读大致需要 1 分钟 )

为什么输入敏感数据（如登录信息）的页面也要做成 https？

2011-12-31 10:50 • Security

有一种错误的观念是，对于不太敏感的内容（例如论坛之类），只要用 https 保护登录过程中提交密码的部分就足够了。例如国内非常流行的网易邮箱，很早以前便提供了"SSL安全登录"的选项，这样做显然是比完全不提供SSL登录选项的新浪邮箱要强多了[注1]，但是仍然是不够的。

阅读全文… ( 本文约 467 字，阅读大致需要 1 分钟 )

nginx中的TLS/SSL配置

2010-07-18 04:47 • Security

nginx可以作为很多种不同的用途。对Web服务器来说，nginx可以直接用作https服务器，也可以用于为现有的http Web服务器作为前端代理和负载平衡的同时提供https之用。

阅读全文… ( 本文约 1201 字，阅读大致需要 3 分钟 )

如何：申请用于服务器SSL/TLS的X.509证书

2010-07-15 01:07 • Security

📓 注意
2015-03-05更新：本文中部分干货已过时，本文本身也不再更新。请参阅这张作弊条。由于 ACME 协议的普及，现时通常只需生成密钥对即可。

SSL/TLS协议中，服务器证书是用于向客户端证明服务器身份的凭据，同时它还向用户提供了服务器的公钥，而服务器公钥则可以用来建立客户端到服务器的安全通讯（具体的通讯流程要比这个复杂，纯从技术而言，服务器的公钥主要用于与客户端进行会话密钥的协商）。

服务器的公钥只能确保拥有私钥的服务器（或人）能够解密信息，但它本身并不能确认服务器的身份。在实践中有很多种不同的方法来确保公钥确实来自受信任的服务器，在通常的SSL/TLS协商过程中，采用的方法是根据证书链来逐层验证公钥是否是有效的及其身份。简单地说，就是以安全的方法（例如安装光盘，或互相认证的签名等）事先将证书链上的某一个或某几个证书发给客户端，以便其验证最终用于服务器的安全证书。关于这一流程的具体细节，已经有很多文章进行了介绍，在此不再赘述。

如此，我们在实现采用SSL/TLS的服务器的时候，需要为证书准备的事项包括：

找到一家被客户端信任的、具备签发证书资质的发证机构。发证机构可以是根CA（对于浏览器来说，通常可以在安全选项中找到类似"查看证书"之类的选项），也可以是这些根CA认可的二级发证机构。
收集用于验证服务器身份的信息，例如服务器的FQDN，等
生成一对用于SSL/TLS的公钥/私钥。

有了这些信息，就可以制作证书申请（CSR）供发证机构去签名了。一般来说，发证机构需要首先验证申请人的身份信息，然后对CSR提交的信息进行核对和签名，并将签名之后的证书发给申请者，或供其下载。下面以 FreeBSD、OpenSSL 为例介绍从生成公钥/私钥对到签发、安装证书的全过程。

阅读全文… ( 本文约 1666 字，阅读大致需要 4 分钟 )