提醒：本文最后更新于 1400 天前，文中所描述的信息可能已发生改变，请仔细核实。
于北京时间10月27号23:20更新的Nginx 1.19.4，更新了3个特性，内容如下：
Feature: the "ssl_conf_command", "proxy_ssl_conf_command", "grpc_ssl_conf_command", and "uwsgi_ssl_conf_command" directives.
Feature: the "ssl_reject_handshake" directive.
Feature: the "proxy_smtp_auth" directive in mail proxy.
其中http_ssl_module新增两个方法：ssl_conf_command和ssl_reject_handshake；mail_proxy_module新增了proxy_smtp_auth。
ssl_conf_command可以设置任意的OpenSSL配置，需要OpenSSL 1.0.2+，另外注意修改OpenSSL配置后可能会导致意外错误。
我觉得比较有用是在http作用域使用：
ssl_conf_command Options PrioritizeChaCha;等效于SSL_OP_PRIORITIZE_CHACHA，详见传送门OpenSSL SSL_CONF_cmd。
最早有nginx_auto_using_PRIORITIZE_CHACHA.patch这个Patch，但其实我很早就删掉这个Patch，通过服务端配置让客户端自己选择了。不过现在就一行参数，何乐不为。
有了ssl_reject_handshake这个参数，再也不需要strict-sni.patch了。
本质需求就是为了当机器人或者奇怪的人类通过HTTPS访问你的IP时不暴露证书，也就不会暴露域名。
官方文档给了个例子如下，在以下配置中，除example.com以外，其他域名的SSL握手将被拒绝。（返回UNRECOGNIZED NAME，Chrome提示ERR_SSL_UNRECOGNIZED_NAME_ALERT）
server {
listen 443 ssl;
ssl_reject_handshake on;
}
server {
listen 443 ssl;
server_name example.com;
ssl_certificate example.com.crt;
ssl_certificate_key example.com.key;
}
proxy_smtp_auth主要是通过AUTH指令可以在SMTP后端上启用或禁用用户身份验证。
注意，如果使用了XCLIENT，则XCLIENT指令不会发送LOGIN参数。
刚刚严谨的测试了下，发现使用ssl_reject_handshake后，TLS 1.3协商不起来，握手握着握着降级了。。。
经Nginx答复，这是个已知问题，是OpenSSL的锅。详细见传送门。
OpenSSL准备Merge修复PR了，介时Nginx with openssl就没问题了。
2020/12/02更新。
OpenSSL已经合并了PR。
下一1.1.1版本可以获得修复。主dev分支（master）已支持。
2020/12/10补充。
OpenSSL 1.1.1j已经修复此问题。
2021/02/20补充。
转载请注明转自:kn007的个人博客的《Nginx 1.19.4新特性推荐》