OCSP stapling是Https优化方案之一，将原本需要客户端实时发起的 OCSP 请求转嫁给服务端
- 在线证书状态协议（Online Certificate Status Protocol），简称 OCSP，是一个用于获取 X.509 数字证书撤销状态的网际协议，在 RFC 6960 中定义。OCSP 用于检验证书合法性，查询服务一般由证书所属 CA 提供。OCSP 查询的本质，是一次完整的 HTTP 请求加响应的过程，这中间涵括的 DNS 查询、建立 TCP 连接、Web 端工作等步骤，都将耗费更多时间，使得建立 TLS 花费更多时长。
- OCSP存在隐私和性能问题。
- 浏览器直接去请求第三方CA(Certificate Authority, 数字证书认证机构)，会暴露网站的访客(CA 机构会知道哪些用户在访问我们的网站)；
- 浏览器进行OCSP查询会降低HTTPS性能(访问我们的网站会变慢) OCSP实时查询会增加客户端的性能开销。
OCSP Stapling将原本需要客户端实时发起的 OCSP 请求转嫁给服务端，Web 端将主动获取 OCSP 查询结果，并随证书一起发送给客户端，以此让客户端跳过自己去寻求验证的过程，提高 TLS 握手效率。 可以提高HTTPS性能。
开启ocsp装订
在网站配置文件中添加以下内容
# 开启 OCSP Stapling ---当客户端访问时 NginX 将去指定的证书中查找 OCSP 服务的地址，
获得响应内容后通过证书链下发给客户端。
ssl_stapling on;
# 启用OCSP响应验证，OCSP信息响应适用的证书
ssl_stapling_verify on;
#若 ssl_certificate 指令指定了完整的证书链，则 ssl_trusted_certificate 可省略。
ssl_trusted_certificate /path/to/xxx.pem;
#添加resolver解析OSCP响应服务器的主机名，valid表示缓存。
resolver 8.8.8.8 8.8.4.4 valid=60s;
# resolver_timeout表示网络超时时间
resolver_timeout 2s;配置完成后可以去myssl查看有没有生效。
-------------
最近推上热闹的 MacOS 系统 OCSP 用户应用隐私泄露问题简记
这两天的推上有一件挺热闹并且骇人听闻的事，夸张一点地说： 在 MacOS 上，包括 Apple、运营商、CDN、中间人在内的任何人 / 设备都完全知道你在何时打开了哪个 App。
第一次听到这个消息时你是什么反应？反正我是惊呆了。 至少我个人作为开发者而言是较注重隐私的，而且在隐私方面，我也挺相信苹果，但是出了今天这一茬，简直是毁灭性的打击。
推友们在说啥
ocsp是非加密的，等于苹果把你机器上每个运行的软件的证书都请求了一次，那么意味着运营商和所有网络上监听的人，都借此知道了你安装了什么app。因为检查是实时的，也就知道了你在什么时间运行了它。换句话说所有人都知道你几点打开过twitter app…
关于 macOS OCSP 我只提醒一点：如果你在墙内的话，由于它走的非加密 http，一个最简单的网络监控就能够知道在你的 macOS 上运行了什么程序，比如常见的 ShadowsocksX-NG 考虑到最近因为翻墙被请喝茶的各种报道，请自己编译这些软件，或者下载后移除签名： codesign --remove-signature.
某应用用户应该发个邮件问问作者：听说Mac上的应用有OCSP隐私泄露问题，继续在国内用安全吗？ 就想知道作者会不会捏着鼻子回复No body knows OCSP better than me
有太多的讨论，我就不过多的贴推文了。知道是怎么回事足以。
OCSP 是什么
OCSP 全称是 Online Certificate Status Protocol，即在线证书状态协议。为什么要有这个？且从数字证书说起。
苹果为了“保证在 MacOS 上运行的应用安全”，所以需要开发者用其密钥对所发布的应用进行数字签名，然后才能上架发布。 而开发者的密钥由苹果签发，所以，当有一天，苹果觉得开发者违反了它的条款等等，就能主动吊销（Revoke）此开发者的证书。 那 MacOS 怎么知道证书已经被吊销了呢？每次启动一个应用的时候，检查一下该应用的证书的状态即可。 向谁检查？http://ocsp.apple.com。注意到，这是一个 HTTP 协议的地址，而非 HTTPS。那就是，明文、不安全的，非常容易被人知道传输的内容。
至于为什么不走 HTTPS？这貌似涉及到是先有鸡还是先有蛋的问题。我暂时还不太懂，这里不过多讨论，可以看这里。
这里有一篇文章比较详细地讲解了 MacOS 上 OCSP 的工作过程：Can't open apps on macOS: an OCSP disaster waiting to happen。
如何规避检查
最最容易想到的办法自然是在本地 /etc/hosts 文件中屏蔽（污染）掉以下域名。目前已知如下：
- ocsp.apple.com
- ocsp.g.aaplimg.com
另外还有几个 CNAME，我觉得上面几个就够了。
- ocsp-lb.apple.com.akadns.net
- ocsp-cn-lb.apple.com.akadns.net
- ocsp.apple.com.download.ks-cdn.com
- k128-mzstatic.gslb.ksyuncdn.com
- ocsp.apple.com.cdn20.com
屏蔽掉域名以后，会有什么后果？MacOS 的 fall-back 规则是什么呢？
- 如果检查失败，默认通过？
- 如果检查失败，默认不通过？
根据上面较详细介绍 OCSP 的文章可以知道苹果目前是前者，默认通过。 所以我们目前来说，污染域名的方式是可行的。 但是如果哪一天苹果悄悄改成默认不通过。 岂电脑岂不是废了？目前感觉还不太可能，不然没网的时候岂不是不能用电脑了？
其它阅读：如何避免App被苹果永久撤消或签署。
我的实验
怀揣着一堆的疑问，我打开了 Wireshark，设定了 http 作为过滤器，然后开始抓包，然后随便打开了一个应用，果然立马抓到了包！
淦，太可怕了。一打开的时候就立马发出了，路径中包含了证书相关信息，就能够推断出正在使用的应用。
从响应中还能看到 KS-CLOUD 字眼，没错，这是金山云的 CND、缓存服务器之类的东西。这些信息无疑被它们掌控了。
我会先把上述的几个域名先屏蔽，然后观察一阵子，看看有没有什么不良后果。（其实那篇详述 OCSP 原理的文章解释过了）。
参考
提升 Nginx TLS/SSL HTTPS 性能的7条优化建议
自2018年7月起，谷歌浏览器开始将“HTTP”网站标记为“不安全”。在过去的几年中，互联网已经迅速过渡到HTTPS，Chrome浏览器的流量超过70％，并且Web排名前100位的网站中有80多个现在默认使用HTTPS,当前Nginx作为最常见的服务器，广泛用于负载均衡（LB)、网关、反向代理。考虑到这一点，让我们看一下Nginx调优技巧，改善Nginx + HTTPS的性能以获得更好的TTFB和更少的延迟。
1. 开启 HTTP/2
HTTP/2最初是在Nginx版本1.9.5中实现的，以取代spdy。在Nginx上启用HTTP/2模块很简单。
原先的配置：
listen 443 ssl;修改为：
listen 443 ssl http2;可以通过curl来验证：
curl --http2 -I https://domain.com/2. 开启 SSL session 缓存
启用 SSL Session 缓存可以减少 TLS 的反复验证，减少 TLS 握手。 1M 的内存就可以缓存 4000 个连接，非常划算，现在内存便宜，尽量开启。
ssl_session_cache shared:SSL:50m; # 1m 4000个，
ssl_session_timeout 1h; # 1小时过期 1 hour during which sessions can be re-used.3. 禁用 SSL session tickets
由于Nginx中尚未实现SSL session tickets，可以关闭：
ssl_session_tickets off;4. 禁用 TLS version 1.0
1.3已经出来。1.0可以丢进历史垃圾堆。
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;修改为：
ssl_protocols TLSv1.2 TLSv1.3;5. 启用OCSP Stapling
如果不启用 OCSP Stapling 的话，在用户连接你的服务器的时候，需要去验证证书，这个验证证书的时间不可控，我们开启OCSP Stapling后，可以省掉这一步。
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/full_chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;6. 减小ssl buffer size
ssl_buffer_size 控制在发送数据时的 buffer 大小，默认情况下，缓冲区设置为16k，为了最大程度地减少TTFB（至第一个字节的时间），最好使用较小的值，这样TTFB可以节省大约30 – 50ms。
ssl_buffer_size 4k;7. 调整 Cipher 优先级
更新更快的 Cipher放前面，这样延迟更小。
# 手动启用 cipher 列表
ssl_prefer_server_ciphers on; # prefer a list of ciphers to prevent old and slow ciphers
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';------------------------------------启用OCSP Stapling
前言
尽管相对于 HTTP ，HTTPS 在安全性上已经有了质的飞跃，然而简单的设置 HTTPS 仍无法避免类似于中间人攻击这样的恶意行为，而本文所要介绍的 OCSP Stapling 和 下篇文章将要介绍的 Certification Transparency 就是用来防范这些恶意行为的。
什么是 OCSP Stapling
OCSP (Online Certificate Status Protocol) 通常由 CA 提供，用于在线实时验证证书是否合法有效，这样客户端就可以根据证书中的 OCSP 信息，发送查询请求到 CA 的验证地址，来检查此证书是否有效。
然而这些默认查询 OCSP 的客户端在获得查询结果的响应前势必会一直阻塞后续的事件，在网络情况堪忧的情况下（尤其是大陆地区）会造成较长时间的页面空白。
而 OCSP Stapling ，顾名思义，是将查询 OCSP 接口的工作交给服务器来做，服务器除了可以直接查询 OCSP 信息，还可以仅进行少数次查询并将响应缓存起来。当有客户端向服务器发起 TLS 握手请求时，服务器将证书的 OCSP 信息随证书链一同发送给客户端，从而避免了客户端验证会产生的阻塞问题。由于 OCSP 响应是无法伪造的，因此这一过程也不会产生额外的安全问题。
如何开启
Nginx
在配置文件的 server 块中添加如下内容：
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/certs/chained.pem;
随后检测配置并重载：
nginx -t
nginx -s reload
Apache
修改主机配置文件：
SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
<VirtualHost *:443>
SSLEngine on
SSLProtocol all -SSLv3 -SSLv2
SSLCertificateFile /path/to/your_domain.crt
SSLCertificateKeyFile /path/to/your_private.key
SSLCertificateChainFile /path/to/CA.crt
SSLUseStapling on
</VirtualHost>
然后使用 systemctl reload apache 或 service apache reload 重载 Apache.
验证 OCSP Stapling 是否开启，
使用 SSLLAB 验证,,
访问 https://www.ssllabs.com/ssltest/ ，输入欲测试的域名，稍等片刻后，如果发现结果中出现如下内容则证明已成功开启 OCSP Stapling：“OCSP stapling yes"
手动验证：
echo QUIT | openssl s_client -connect www.example.com:443 -status 2> /dev/null | grep -A 17 'OCSP response:'
若结果为以下内容，则开启成功:
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Produced At: Mar 18 04:34:00 2017 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
Serial Number: 03EFDB2DC2103617A9CB5D33E1BE28CA880D
Cert Status: good
This Update: Mar 18 04:00:00 2017 GMT
Next Update: Mar 25 04:00:00 2017 GMT
No comments:
Post a Comment