我认为本站没有必要强制256位加密套件优先。
对于证书只有2048（RSA）位和256（ECC）位的网站而言，256位套件意义不大（因为证书的密钥强度并不满足256位的要求）。
使用128位加密套件（nginx设定：服务器不强制要求客户端按照服务端的加密套件），且只保留AEAD+FS（前向安全性）套件和TLS 1.2/1.3协议即可。
2 个赞
https://ssl-config.mozilla.org/
参考这个网站做SSL配置。
用Intermediate，不建议用Modern。
因为，Modern配置仅保留了TLS 1.3，如果你只用TLS 1.3，那么意味着你完全抛弃了“中间”（不旧也不新）的客户端，只给现代设备提供安全通信。
也不建议用Old配置，现在只支持TLS 1.0/1.1的设备已经是极少数，你相当于在为了保护那些老设备，又给自己引入了那些老旧不安全的协议。
1 个赞
本站使用Cloudflare，能直接看到的所有ssl/tls性能开销都是cf出
当然 不知道cf到ll服务器中间是什么加密
2 个赞
那就很奇怪，CloudFlare并没有强制256套件优先，那我的浏览器为什么使用了256位套件？（正常情况应该是128位套件）。
CF到源站一般也是128位套件进行加密，当然源站配置成只支持256位套件，CF还是会连接上去。
还有为什么本站还在支持TLS 1.0/1.1，仅支持这两个版本协议的老设备已经不多了。
1 个赞
XP SP3使用Chrome 49或者FireFox 52都可以支持TLS 1.2。
Android 4开始也提供了对TLS 1.2的支持。但也需要自带完整内核的浏览器。
1 个赞
还可以配置无tls直连呢（
Cloudflare默认最低TLS版本是1.0，这个需要站长调整
1 个赞
无TLS直连，或者有TLS但不验证对端证书，会有个安全风险：无法保证CDN到源站的链路上是否存在攻击者。
NSA当年破坏掉谷歌的加密，用的原理就是：用户到Google前端有加密，但是Google前端到后端反而没有。
（此对话条件默认信任了CDN不会做坏事）
理论上当然是这样的，我只是说可以这样操作
事实上tls开销… 这都出不起也没必要搞站了（
加密套件太强会导致客户端-服务端延迟。
这个延迟在于：客户端和服务端本地加密是需要时间的。
过度安全（Over sec）的问题在于：并没有提升安全性，反而提高了通信延迟。
那keep-alive？
降低不必要的加密层级即可，这个延迟来自于双方本地CPU加解密的延迟。
问题是用了cf的ssl 似乎并没法修改这种东西…
显然我在怀疑我的请求没有发送到CloudFlare。
因为我在SSL Labs上看了，它确实解析出了CloudFlare的IP，但是证书是Baltimore CyberTrust Root和Cloudflare Inc ECC CA-3。证书是ECC 256。
可我这里获取到的证书是ISRG Root X1（Let`s encrypt）。证书是RSA 2048。
我这里是cf
你看一下DNS Name？
等等 你ping的结果是cloudflare anycast吗？
本地结果是CloudFlare。
但是我用代理服务器，我的Chrome浏览器强制走位于香港的Azure服务器。
（先去吃饭，一会后回来）
我怀疑是Azure香港服务器解析出来的结果还是以前的记录？
反正无法解释，我确信我的机器到香港服务器之间已经经过合理的加密（AES-256-GCM）。
1 个赞
证书已撤销。
以前的记录也不应该，因为以前的服务器注销之后应该已经无法访问了。