update nginx docs

Author: fengzhao

http/HTTP权威指南.markdown

@@ -5156,9 +5156,29 @@ CT 可防止签发恶意证书，并检测任何错误签发的证书。 它提
 
 根证书发证机构的证书通常是自签名的，更新相对来说比较麻烦（它通常依赖于操作系统的在线或离线更新机制）， 因此这些证书的私钥事关重大，因此人们通常不希望经常更新它们，因而证书发证机构在绝大多数时候并不会使用这些私钥来签署证书。取而代之的是，他们会创建一些称为中级发证机构的证书用来签署日常的证书，这样根证书的私钥可以采用更为严密的方法来保护， 例如可以把它们从网络上彻底断开，而中级发证机构的证书则可以以较高的频率进行密钥轮换，借此来避免其私钥暴露导致的风险。
 
-一个新的发证机构进入市场时，其自签名的根证书往往不会被已经在市场上的客户端系统认可， 因此这样一来新的发证机构想要获得用户就必须想办法解决能被用户承认这个问题。 一旦获得了一定的知名度并证明了自己的可靠性， 这些发证机构便可以遵循一定的流程获得主流浏览器或操作系统的认可， 并将自己的根证书也加入到它们的受信根证书列表中了。 所以，在起步阶段，新的发证机构往往会要求一些已经存在的根证书去对其根证书进行交叉签署， 在客户端验证证书有效性时，由于这些根证书在他们看来是一个经过了受信根证书签名的中级证书而不是一个普通的不受信自签名根证书， 因此也就不会给出无法验证证书是否有效的提示，而是能够正确地对其有效性进行验证了。
 
-Let’s Encrypt 在起步阶段正是采用了这种做法。通俗地说，它的中级发证机构的证书被两家根证书机构同时签名， 其一是它自己的 ISRG Root，另一个是另一家根证书机构 IdenTrust 的 DST Root X3。初期，由于 DST Root X3 已经被许多操作系统和浏览器认证过，因此为其普及起到了非常重要的作用。
+
+
+
+一个新的发证机构进入市场时，其自签名的根证书往往不会被已经在市场上的客户端系统认可， 因此这样一来新的发证机构想要获得用户就必须想办法解决能被用户承认这个问题。
+
+一旦获得了一定的知名度并证明了自己的可靠性， 这些发证机构便可以遵循一定的流程获得主流浏览器或操作系统的认可， 并将自己的根证书也加入到它们的受信根证书列表中了。 
+
+
+
+所以，在起步阶段，新的发证机构往往会要求一些已经存在的根证书去对其根证书进行交叉签署， 在客户端验证证书有效性时，由于这些根证书在他们看来是一个经过了受信根证书签名的中级证书而不是一个普通的不受信自签名根证书， 因此也就不会给出无法验证证书是否有效的提示，而是能够正确地对其有效性进行验证了。
+
+
+
+
+
+
+
+Let’s Encrypt 在起步阶段正是采用了这种做法。通俗地说，它的中级发证机构的证书被两家根证书机构同时签名， 其一是它自己的 ISRG Root，另一个是另一家根证书机构 IdenTrust 的 DST Root X3。
+
+初期，由于 DST Root X3 已经被许多操作系统和浏览器认证过，因此为其普及起到了非常重要的作用。
+
+
 
 UTC 时间 2021年9月29日 19:21:40，DST Root X3 的根证书过期了。这样一来，这一边的信任链便不再成立。
 

nginx/HTTPS证书.markdown

@@ -70,10 +70,83 @@ https://miaotony.xyz/2020/03/28/Server_IssueACertWithACME/
 
 
 
-## SSL缓存
+## TLS会话恢复
+
+ TLS session resumption
+
+TLS 会话恢复使用 session ticket 的机制在 **RFC 5077** 中进行了定义，该 RFC 于 **2008 年** 发布，适用于 TLS 1.2 版本。
 
 
 
 在 Nginx 中配置 SSL 会话缓存可以提高 SSL 握手性能和服务器负载能力，因为 SSL 握手需要进行密钥协商和证书验证等操作，会占用服务器的计算资源。
 
-通过使用 SSL 会话缓存，可以在客户端和服务器之间缓存 SSL 会话状态信息，从而加快 SSL 握手速度和减轻服务器负载。
+通过使用 SSL 会话缓存，可以在客户端和服务器之间缓存 SSL 会话状态信息，从而加快 SSL 握手速度和减轻服务器负载。
+
+
+
+
+
+```
+Syntax: ssl_session_cache off | none | [builtin[:size]] [shared:name:size];
+Default: ssl_session_cache none;
+Context: http, server
+```
+
+设置存储会话参数的缓存的类型和大小。缓存可以是下面的类型中的任意一个：
+
+- `off`    严格禁止使用会话缓存：nginx 显式地告诉客户端不重用会话
+
+- `none`    不允许使用会话缓存：nginx 告诉客户端可能重用会话，但不真正地在缓存中存储会话参数
+
+- `builtin`    OpenSSL 内置的缓存。仅能被一个工作进程使用。在会话中指定缓存大小。默认保存 20480 个会话。使用内置缓存将导致内存碎片
+
+- `shared`    所有工作进程共享缓存。以字节为单位指定缓存大小；1M 大约可以存储 4000 个会话。每个共享缓存可以拥有任意的名称。可以在多个虚拟主机中使用具有相同名称的缓存。
+
+  它还用于自动生成、存储和定期轮换 TLS 会话票据密钥（1.23.2），除非使用 `ssl_session_ticket_key` 指令显式地进行配置。可以同时使用这两种缓存类型，比如：
+
+
+
+
+
+
+
+
+
+握手协议完成后，服务器端会在内存中保存会话信息，包括如下部分：
+
+- 会话标识符（session identifier）：每个会话都有唯一编号。
+
+- 证书（peer certificate）：对端的证书，一般情况下都为空。
+
+- 压缩算法（compression method）：一般不启用。
+
+- 密码套件（cipher spec）：客户端和服务器端协商出的密码套件。
+
+- 密钥（master secret）：每个会话会保存一个主密钥，注意不是预备主密钥。
+
+- 话可恢复标识（is resumable）：表示某个会话是否可恢复。
+
+  
+
+通过服务器保存的会话信息，最终能够生成 TLS 记录层协议所需要的加密参数（security parameters），从而能够保护应用层的数据。
+
+
+
+
+
+每次建立新 SSL/TLS 连接都需要握手，如果会话中断，那么需要重新握手。此时，有两种方法恢复原来的 Session：
+
+1. Session ID
+
+Session ID 重用的前提是客户端和服务端都保存会话密钥。每次会话都有唯一的编号（Session ID）。会话中断，需要重连时，客户端只要给出该编号，并且服务器端拥有该记录，双方就可以重用已有的会话密钥，而不必重新生成。
+
+客户端提供 Session ID，服务端确认该编号存在，双方不再进行握手阶段剩余的步骤，而是直接使用已有的会话密钥。
+
+目前所有浏览器都支持 Session ID，但其缺点是：因为 Session ID 往往只保留在一台服务器上，所以如果客户端的请求发到另一台服务器，那么无法恢复会话。当然也可以要求负载均衡的时候只用 IP hash，尽管在实际情况中这么做不太现实。
+
+Session ID 方案要求服务端记住会话状态，有违于 HTTP 服务无状态的特点。
+
+
+
+
+