匿名加密套件检测（CVE-2007-1858），支持对SSL3.0、TLS1.0、TLS1.1、TLS1.2多种协议，19个ANON类加密套件，包含DES、AES、CAMELLIA和ARIA等算法。

TLS_DH_ANON_WITH_AES_256_GCM_SHA384
TLS_DH_ANON_WITH_AES_128_GCM_SHA256
TLS_DH_ANON_WITH_AES_256_CBC_SHA256
TLS_DH_ANON_WITH_AES_256_CBC_SHA
TLS_DH_ANON_WITH_AES_128_CBC_SHA256
TLS_DH_ANON_WITH_AES_128_CBC_SHA
TLS_DH_ANON_WITH_3DES_EDE_CBC_SHA
TLS_DH_ANON_WITH_RC4_128_MD5
TLS_DH_ANON_EXPORT_WITH_RC4_40_MD5
TLS_DH_ANON_WITH_DES_CBC_SHA
TLS_DH_ANON_WITH_CAMELLIA_128_CBC_SHA256
TLS_DH_ANON_WITH_CAMELLIA_128_GCM_SHA256
TLS_DH_ANON_WITH_CAMELLIA_256_GCM_SHA384
TLS_DH_ANON_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_ANON_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_ANON_WITH_ARIA_128_CBC_SHA256
TLS_DH_ANON_WITH_ARIA_256_CBC_SHA384
TLS_DH_ANON_WITH_ARIA_128_GCM_SHA256
TLS_DH_ANON_WITH_ARIA_256_GCM_SHA384

以上都是不安全套件，存在严重安全风险。

如何解决使用了anonymous套件？

SSL 配置生成器 https://ssl-config.mozilla.org/

服务器支持不安全的加密套件

不安全的加密套件，容易被攻击者破解，从而解密两端加密信息，影响网站安全。

如何设置安全的加密套件？

SSL 配置生成器 https://ssl-config.mozilla.org/

不建议加密协议上使用64bits块加密套件（3DES/DES/RC2/IDEA）

怎么解决使用了64bits块加密套件?

SSL 配置生成器 https://ssl-config.mozilla.org/

RC4密码套件

2015年3月26日，国外数据安全公司Imperva的研究员Itsik Mantin在BLACK HAT ASIA 2015发表论文《Attacking SSL when using RC4》阐述了利用存在了13年之久的RC4漏洞——不变性弱密钥（《Weakness in the Key Scheduling Algorithm of RC4》,FMS 发表于2001年）进行的攻击，并命名为“受戒礼”攻击（Bar Mitzvah Attack）。

根据《Attacking SSL when using RC4》中的阐述，漏洞的成因主要在于不变性弱密钥是RC4密钥中的一个L型的图形，它一旦存在于RC4的密钥中，在整个初始化的过程之中保持状态转换的完整性。这个完整的部分包括置换过程中的最低有效位，在由RPGA算法处理的时候，决定伪随机输出流的最低有效位。这些偏差的流字节和明文进行过异或，导致密文中会泄露重要明文信息。

怎么解决使用了RC4密码套件?

如果您的服务器需要支持IE6这种古董级别的浏览器，那么可以支持SSLv3版本协议，如果说对兼容性没有太大的需求，只要主流的浏览器能够访问那么就不要支持3DES系列的加密套件，如果说想要在保证安全性的同时，也要有最好的兼容性，那么就可以采取TLS1.x协议+FS加密套件配置方式进行配置。

服务采用了TLSv1.0+TLSv1.1+TLSv1.2的SSL协议，安全加密套件使用了不带RC4的加密套件，并且设置了优先使用FS系列加密套件。

服务器不支持安全的密钥交换参数

如何设置安全的密钥交换参数？

SSL 配置生成器 https://ssl-config.mozilla.org/

服务器支持弱Diffie-Hellman(DH)密钥交换参数

Diffie-Hellman:一种确保共享KEY安全穿越不安全网络的方法，它是OAKLEY的一个组成部分。Whitefield与Martin Hellman在1976年提出了一个奇妙的密钥交换协议，称为Diffie-Hellman密钥交换协议/算法(Diffie-Hellman Key Exchange/Agreement Algorithm).这个机制的巧妙在于需要安全通信的双方可以用这个方法确定对称密钥。然后可以用这个密钥进行加密和解密。但是注意，这个密钥交换协议/算法只能用于密钥的交换，而不能进行消息的加密和解密。双方确定要用的密钥后，要使用其他对称密钥操作加密算法实现加密和解密消息。

怎么解决弱Diffie-Hellman(DH)密钥交换参数?

服务采用了TLSv1.0+TLSv1.1+TLSv1.2的SSL协议，安全加密套件使用了不带RC4的加密套件，并且设置了优先使用FS系列加密套件。

没有使用AEAD系列加密套件

AEAD的全称是Authenticated encryption (AE) and authenticated encryption with associated data (AEAD, variant of AE)。也就是带附加数据的加密和验证算法。

常见的 AEAD 算法如下：

• AES-128-GCM
• AES-192-GCM
• AES-256-GCM
• ChaCha20-IETF-Poly1305
• XChaCha20-IETF-Poly1305

怎么解决加密套件问题?

使用以RSA和ECDSA键为对象的以下套件配置作为起点：

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

没有优先使用FS系列加密套件

怎么解决加密套件问题?

需要配置符合PFS规范的加密套件，推荐配置：

ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE

需要在服务端TLS协议中启用TLS1.2，推荐配置：TLSv1 TLSv1.1 TLSv1.2;

服务器只使用SSL3作为最好的协议

ssl3 存在POODLE漏洞，并且最新浏览器的兼容性较差，不支持最新的安全特性。

如何设置服务器协议？

推荐配置：TLSv1 TLSv1.1 TLSv1.2;  SSL 配置生成器

服务器仅支持老的协议，没有启用安全性与兼容性最佳的TLSv1.2协议

怎么支持TLSv1.2协议？

SSL 配置生成器 https://ssl-config.mozilla.org/

启用了SSLv3协议

POODLE（在降级的传统加密上填充Oracle）是2014年10月14日发现的一个漏洞，它使攻击者可以通过执行中间人攻击来使用SSLv3协议读取任何加密信息。尽管许多程序使用SSLv3作为后备，但它已经到了应禁用的地步-因为许多客户端可能被迫使用SSLv3。强制客户端进入SSLv3会增加发生攻击的机会。本文将向您展示如何在当今常用的某些软件应用程序中禁用SSLv3。

怎么关闭SSLv3协议?

推荐配置：TLSv1 TLSv1.1 TLSv1.2;  SSL 配置生成器

主页面引用了不安全的HTTP资源

HTTP 协议在传输过程中是明文数据，很容易被第三方劫持和修改。

怎么解决不安全HTTP资源?

引用的资源都是用 Https 请求进行替换。

使用HSTS，但是使用的max-age属性小于180天(15768000秒)

HTTP严格传输安全（英语：HTTP Strict Transport Security，缩写：HSTS）是一套由互联网工程任务组发布的互联网安全策略机制。网站可以选择使用HSTS策略，来让浏览器强制使用HTTPS与网站进行通信，以减少会话劫持风险。

HSTS可以用来抵御SSL剥离攻击。SSL剥离攻击是中间人攻击的一种，由Moxie Marlinspike于2009年发明。他在当年的黑帽大会上发表的题为“New Tricks For Defeating SSL In Practice”的演讲中将这种攻击方式公开。SSL剥离的实施方法是阻止浏览器与服务器创建HTTPS连接。它的前提是用户很少直接在地址栏输入https://，用户总是通过点击链接或3xx重定向，从HTTP页面进入HTTPS页面。所以攻击者可以在用户访问HTTP页面时替换所有https://开头的链接为http://，达到阻止HTTPS的目的。

HSTS可以很大程度上解决SSL剥离攻击，因为只要浏览器曾经与服务器创建过一次安全连接，之后浏览器会强制使用HTTPS，即使链接被换成了HTTP。

另外，如果中间人使用自己的自签名证书来进行攻击，浏览器会给出警告，但是许多用户会忽略警告。HSTS解决了这一问题，一旦服务器发送了HSTS字段，将不再允许用户忽略警告。

怎么设置HSTS?

HSTS的作用是强制客户端（如浏览器）使用HTTPS与服务器创建连接。服务器开启HSTS的方法是，当客户端通过HTTPS发出请求时，在服务器返回的超文本传输协议（HTTP）响应头中包含Strict-Transport-Security字段。非加密传输时设置的HSTS字段无效。

比如，https://example.com/ 的响应头含有Strict-Transport-Security: max-age=31536000; includeSubDomains。这意味着两点：

1. 在接下来的31536000秒（即一年）中，浏览器向example.com或其子域名发送HTTP请求时，必须采用HTTPS来发起连接。比如，用户点击超链接或在地址栏输入 http://www.example.com/ ，浏览器应当自动将 http 转写成 https，然后直接向 https://www.example.com/ 发送请求。
2. 在接下来的一年中，如果 example.com 服务器发送的TLS证书无效，用户不能忽略浏览器警告继续访问网站。

参考网址：

SSL 配置生成器 https://ssl-config.mozilla.org/

证书由正规机构签发，拥有完整证书链，并且根证书在系统和浏览器中可信。证书签发过程可查，可追踪。

怎么解决证书不可信?

申请或购买正规证书提供商的证书。

证书链不完整

证书与上级签发证书组成的可信链，是浏览器检查网站是否可信的关键，不完整的证书链有一定概率导致浏览器判定网站为不可信。

怎么解决证书链不完整?

证书链下载  https://myssl.com/chain_download.html

输入域名或者上传证书文件，下载补全的证书链信息

使用了Symantec旧PKI平台在2016年6月1日前签发的证书

关于Symantec旧平台签发的证书升级提示说明 https://blog.myssl.com/symantec-update-tip/

使用了不符合CT政策的证书

Chrome 证书透明度（CT）相关政策 https://blog.myssl.com/chrome-certificates-transparency-ct-policy/

Apple 证书透明度（CT）相关政策 https://blog.myssl.com/apple-ct-policy/

怎么解决不符合 CT 政策?

申请或购买符合 CT 政策的证书提供商的证书

证书公钥长度低于2048位

使用位数较于 2048 的公钥，有一定几率被攻击者破解，影响网站安全。

怎么解决低于2048位的公钥?

到正规证书提供商申请证书，并使用密码强度较高和长度大于等于2048位的密钥算法。

证书使用MD5签名算法

证书使用MD5 签名容易被攻击者破解，影响网站安全。

如何申请安全证书？

到正规证书提供商申请证书，并使用签名强度较高的算法。

服务器证书使用SHA1弱签名算法

证书使用SHA1签名容易被攻击者破解，影响网站安全。

如何申请安全证书？

到正规证书提供商申请证书，并使用签名强度较高的算法。

证书被吊销

常见吊销原因有：

• 网站私钥泄漏
• 不合规签发的证书

怎么解决证书吊销？

到正规证书提供商询问吊销原因并重新申请证书。

 "DROWN"全称是 Decrypting RSA with Obsolete and Weakened Necryption，是指"利用过时的脆弱加密算法来对RSA算法进破解"，主要针对SSLv2协议漏洞来对TLS进行跨协议攻击。

 "DROWN攻击"主要影响支持SSLv2的服务端和客户端。SSLv2是一种古老的协议，许多客户端已经不支持使用，但由于配置上的问题，许多服务器仍然支持SSLv2。

 "DROWN"使得攻击者可以通过发送probe到支持SSLv2的使用相同密钥的服务端和客户端解密TLS通信。例如：将相同的私钥同时用在Web服务端和Email服务端，如果Email服务支持SSLv2，但web服务不支持，那么攻击者仍然能够利用EMAIL服务的SSLv2漏洞获取到web服务器的TLS连接数据。

如何预防DROWN漏洞？

1. 这里建议用户不要用相同的私钥生成多张SSL证书，也不要将同一张SSL证书部署在多台服务器上。建议在每台服务器上均部署独立的SSL证书，这样攻击者将无法利用其它服务器的漏洞，对关键服务器进行攻击，即使其中一台服务器出现问题也不会影响其他服务器的正常运行。
2. 关闭所有服务器的SSLv2协议。
3. 如果使用了OpenSSL，大家可以参考OpenSSL官方给出的DROWN修复指南

FREAK漏洞

FREAK漏洞（全称：Factoring RSA Export Keys，中文：分解RSA出口级密钥）是SSL/TLS协议中的密码学安全漏洞。

1990年代时，美国对于货物的出口设立了一些规定，从而引入了这个漏洞。规定中指出，美国软件制造商出口的软件只能使用512位及以下的RSA加密。此举是为了便于NSA破译加密。时至2015年，随着计算能力的发展，破解这种加密已经不再是政府机构才能做到的事，任何人只要拥有充足的计算资源，就能通过普通数域筛选法加上约100美元的云计算服务轻而易举地将其破译。这个漏洞还能和中间人攻击结合利用，只要先破译网站的512位弱加密，再进行中间人攻击，就能使任何允许使用512位出口级密钥的网站失去安全保障。此漏洞于2015年发现，但从1990年代开始就已经存在。

如何预防FREAK漏洞？

RSA 的加密长度应大于 2048 位或使用 ECC 算法进行加密。

服务器支持不安全的重协商会受到MITM漏洞攻击

如何预防MITM漏洞？

1. 升级到支持安全的重协商
2. 禁止client发起重协商：目前看来似乎是个不错的选择；
3. 速率限制：对新到来的TLS连接和重协商的速率进行限制；
4. 使用SSL加速卡：通过极大地提高server对handshake的处理能力来增加攻击的成本，但可能攻击者只增加一到两台主机进行攻击就可以使得此措施无效。
5. 使用安全重协商，为了解决中间人攻击的问题，【RFC5764】提出了“安全重协商”机制。本质很简单，就是关联两次握手，方式是提供了一个新的扩展（renegotiation_info）。SSLv3/TLS 1.0不支持扩展，为了使其支持安全重协商，client需要发送TLS_EMPTY_RENEGOTIATION_INFO_SCSV（0xFF）密码套件（缩写为SCSV）。

安全重协商的流程如下：

1. 在某个连接的第一次握手期间，双方通过renegotiation_info扩展或SCSV套件通知对方自己支持安全重协商；
2. 在handshake过程中，client和server都分别记录Finish消息之中的client_verify_data和server_verify_data；
3. 重协商时client在ClientHello中包含client_verify_data，server在ServerHello中包含client_verify_data和server_verify_data。对于受害者，如果协商中不会携带这些数据则连接无法建立。由于Finished消息总是加密的，攻击者无法得到client_verify_data和server_verify_data的值。

POODLE漏洞

OODLE即Padding Oracle On Downgraded Legacy Encryption.是安全漏洞(CVE-2014-3566)的代号，俗称“贵宾犬”漏洞。

此漏洞是针对SSL3.0中CBC模式加密算法的一种padding oracle攻击，可以让攻击者获取SSL通信中的部分信息明文，如果将明文中的重要部分获取了，比如cookie,session，则信息的安全出现了隐患。

从本质上说，这是SSL设计上的缺陷，SSL先认证再加密是不安全的。

如何预防POODLE漏洞？

禁用sslv3协议。

CVE-2016-2107漏洞

OpenSSL 漏洞安全预警(CVE-2016-2107)

CCS(CVE-2014-0224)漏洞

CVE-2014-0224 ChangeCipherSpec 注入

按照TLS的协议 在固定的时间顺序内服务端发送和接收ChangeCipherSpec（更改密钥规格）数据，但是实际上openssl的实现：

服务端在发送时是按照时间线的顺序发送，接收时却没有检查顺序，导致攻击者可以构造伪造的ChangeCipherSpec（比如使用空的主密钥），导致可以中间人攻击解密两端加密信息。

如何预防CCS(CVE-2014-0224)漏洞？

漏洞产生必须客户端和服务端都使用了受影响版本的openssl。

服务端已知的受影响版本 OpenSSL 0.9.8y及之前的版本，1.0.0m之前的1.0.0版本，1.0.1h之前的1.0.1版本。

Heartbleed漏洞

心脏出血（英语：Heartbleed），也简称为心血漏洞，是一个出现在加密程序库OpenSSL的安全漏洞，该程序库广泛用于实现互联网的传输层安全（TLS）协议。它于2012年被引入了软件中，2014年4月首次向公众披露。只要使用的是存在缺陷的OpenSSL实例，无论是服务器还是客户端，都可能因此而受到攻击。此问题的原因是在实现TLS的心跳扩展时没有对输入进行适当验证（缺少边界检查），因此漏洞的名称来源于“心跳”（heartbeat）。该程序错误属于缓冲区过读，即可以读取的数据比应该允许读取的还多。

如何预防Heartbleed漏洞？

升级 OpenSSL 到最新版本，受影响的OpenSSL版本为1.0.1至1.0.1f（含）。较新版本（1.0.1g以上）及先前版本（1.0.0分支以前）不受影响。

Logjam漏洞

该漏洞影响Diffie-Hellman的加密协议，该协议作为HTTPS, SSH, SMTPS协议的加密算法使用。

攻击者使用该漏洞可轻易对受影响网络进行中间人式攻击，降低加密强度，使得加密数据更加容易获取。

如何预防Logjam漏洞？

浏览器升级至最新版本，服务器最好禁用掉对外置加密系统的支持，并创建2048位的Diffie-Hellman加密组，同时升级至最新版本的OpenSSH。openssl-0.98m之后的版本就已经修复了该漏洞。

ROBOT漏洞

TLS ROBOT Attack漏洞

CRIME漏洞

CRIME（英语：Compression Ratio Info-leak Made Easy，意思为：压缩率使信息容易泄露）是一种可攻击安全隐患（Exploit），通过它可窃取启用数据压缩特性的HTTPS或SPDY协议传输的私密Web Cookie。在成功解读身份验证Cookie后，攻击者可以实行会话劫持和发动进一步攻击。CRIME被分配为CVE-2012-4929。

如何预防CRIME漏洞？

CRIME可以被禁用压缩设置解决，无论是在客户端的浏览器中禁用压缩，还是由网站根据TLS的协商特性阻止使用数据压缩都可以达到效果。

TLS 服务器身份验证证书必须符合 Apple 的证书透明性（CT）策略，才能在 Apple 平台上被评估为受信任的。

如果证书不符合 Apple 的政策，则会导致 TLS 连接失败，这可能会中断应用程序与 Internet 服务的连接或 Safari 的无缝连接能力。

在 2021 年第一季度，Apple 提出了自己的证书透明度日志计划。

政策要求

加入 Apple 证书透明度日志计划，日志必须满足以下所有要求：

• 日志实例必须按照 RFC6962 中的规定来实施 CT。
• 同一日志不得在不同时间并且/或向不同相关方呈现两个或更多相互冲突的墨克树视图。
• 日志的最大合并延迟 (MMD) 为 24 小时。
• 如果日志在 MMD 期限内为某个证书创建了 SCT，则日志必须包含这个证书。
• 日志实例必须满足 Apple 对于正常运行时间要达到 99%（由 Apple 来衡量）的要求。
• 日志的服务中断时长不能超过 MMD。
• Apple 的合规性根 CA 会发放相应的证书，以监控日志对于相关政策的遵守情况；因此，日志必须接受这些证书。
• 日志必须信任 Apple 受信任证书存储区内包含的所有根 CA 证书。日志可以信任 Apple 受信任证书存储区内可能并不包含的其他根证书。

每个运营商最多可以使用三个合格的或可用的日志实例。对于不存在证书过期限制的日志，实例会以 URL 和日志签名密钥的形式呈现。对于存在证书过期限制的日志，一组分时日志会被视为单个实例。以下示例呈现的就是一个运行四个时间分段的单日志实例：

Company A 'Loggy 2020' log: accepts certificates that expire between 2020-01-01 00:00:00 UTC - 2021-01-01 00:00:00 UTC
Company A 'Loggy 2021' log: accepts certificates that expire between 2021-01-01 00:00:00 UTC - 2022-01-01 00:00:00 UTC
Company A 'Loggy 2022' log: accepts certificates that expire between 2022-01-01 00:00:00 UTC - 2023-01-01 00:00:00 UTC
Company A 'Loggy 2023' log: accepts certificates that expire between 2023-01-01 00:00:00 UTC - 2024-01-01 00:00:00 UTC

对于 notBefore 值大于或等于 2021 年 4 月 21 日（2021-04-21T00:00:00Z）的证书，基于证书生存期的嵌入式 SCT 数量：

对于 notBefore 值小于 2021 年 4 月 21 日（2021-04-21T00:00:00Z）的证书，基于证书生存期的嵌入式 SCT 数量：

对于 notBefore 值等于或大于 2021-04-21T00:00:00Z 的证书，日志操作员可以拒绝不包含 serverAuth EKU 的叶子证书。

日志操作员必须至少提前 45 天书面通知 certificate-transparency-program@group.apple.com ，以了解其日志接受的一组叶子证书的任何更改。

2020年1月14日微软发布了CVE-2020-0601漏洞公告，此漏洞为Windows加密库中的一个关键的漏洞，Windows CryptoAPI(Crypt32.dll) 验证椭圆曲线加密 (ECC) 证书的方式中存在欺骗漏洞。

攻击者可以通过使用欺骗性的代码签名证书对恶意可执行文件进行签名来利用此漏洞，从而使该文件看似来自受信任的合法来源。美国国家安全局（NSA）已将CVE-2020-0601披露给了Microsoft 。

漏洞详情

crypt32.dll是Windows加密API应用程序接口模块，它提供的Microsoft Windows CryptoAPI无法以正确利用ECC密码术应提供的保护的方式来验证ECC证书。攻击者能够伪造具有受信任根证书颁发机构的证书。

Windows CertGetCertificateChain（）函数来确定是否将X.509证书跟踪到受信任的根CA。攻击者可能在易受攻击的Windows系统上欺骗有效的X.509证书链。攻击者甚至可能做到拦截和修改TLS加密的通信或欺骗Authenticode签名。根据NSA成功利用此漏洞将使攻击者能够提供来自受信任实体的恶意代码。其中包含：签名的文件和电子邮件、签名可执行代码等、HTTPS连接。

由于CVE-2020-0601可绕过Windows验证密码信任的功能，因此攻击者可能会将恶意代码或应用传递到用户主机上，使Windows主机面临风险。攻击者可以通过网络钓鱼等诱骗方式使用户受骗安装恶意软件，甚至可以让已中招的设备使用中间人攻击将合法的程序替换为恶意软件，从而部署利用此漏洞的恶意软件。

例, 下图为我们利用该漏洞搭建的SSL站点示例:

下图为受影响的代码签名示例:

注意：内核驱动签名不受影响，只有普通应用代码签名受影响。

影响版本

• Windows 10 for 32-bit Systems
• Windows 10 for x64-based Systems
• Windows 10 Version 1607 for 32-bit Systems
• Windows 10 Version 1607 for x64-based Systems
• Windows 10 Version 1709 for 32-bit Systems
• Windows 10 Version 1709 for ARM64-based Systems
• Windows 10 Version 1709 for x64-based Systems
• Windows 10 Version 1803 for 32-bit Systems
• Windows 10 Version 1803 for ARM64-based Systems
• Windows 10 Version 1803 for x64-based Systems
• Windows 10 Version 1809 for 32-bit Systems
• Windows 10 Version 1809 for ARM64-based Systems
• Windows 10 Version 1809 for x64-based Systems
• Windows 10 Version 1903 for 32-bit Systems
• Windows 10 Version 1903 for ARM64-based Systems
• Windows 10 Version 1903 for x64-based Systems
• Windows 10 Version 1909 for 32-bit Systems
• Windows 10 Version 1909 for ARM64-based Systems
• Windows 10 Version 1909 for x64-based Systems
• Windows Server 2016
• Windows Server 2016 (Server Core installation)
• Windows Server 2019
• Windows Server 2019 (Server Core installation)
• Windows Server, version 1803 (Server Core Installation)
• Windows Server, version 1903 (Server Core installation)
• Windows Server, version 1909 (Server Core installation)

快速检测

可利用MySSL客户端检测功能快速检测(https://myssl.com/myclient.html), 如果检测到“客户端漏洞“中，CVE-2020-0601为“受影响“，建议按照文末的建议修复。

修复建议

• 开启windows10的自动更新
• 或手动访问官方补丁下载链接下载安装更新包，链接如下

• 官方文档
• 参考地址

证书透明度（CT）是一种设计用于修复SSL/TLS证书生态体系中几个结构缺陷的协议。RFC 6962描述到，它提供一个公开的、只具备附加属性的数据结构，它可以记录由证书颁发机构（CA）颁发的证书。

通过记录证书，大众可以查看由给定CA颁发的证书，这使得网站运营商能够检测到何时为他们的域名颁发了证书，允许他们检查未授权的发行。它还允许浏览器和根存储，以及广大社区，检查CA颁发的证书，并确保CA遵守他们所期望的或公开的实践。

在过去的几年中，Chrome逐渐的对越来越多的公开可信证书要求证书透明度。

1.自2015年1月1日

Chrome已经要求所有EV证书都要通过证书透明度来公开。未正确公开的证书将被剥夺其EV状态（绿色状态栏的EV指示），但不会向不遵守规定的网站的访问者显示警告。

2.自2016年6月1日

Chrome要求所有由赛门铁克公司所拥有的根证书颁发的新证书都通过证书透明度公开。未公开的证书，或未以符合RFC 6962的方式公开的证书将以不可信被拒绝。

3.自2018年4月30日

Chrome要求2018年4月30日以后颁发的所有TLS服务器证书都要符合Chromium CT政策。 在此日期之后，当Chrome连接到一个提供不符合Chromium CT政策的公开可信证书的站点时，用户将会看到一个完整的页面警告（如下图所示），表明他们的连接不符合CT的政策。不符合CT政策的https连接上提供的子资源将无法加载，并在Chrome DevTools中显示错误。如果收到错误，这表明您的CA没有采取措施确保您的证书支持CT，您应该联系您的CA销售或支持团队，以确保您能够获得一个有效的替代证书。

颁发带有嵌入SCT的TLS证书的CA应确保它们符合Chromium CT政策，以便能够在Chrome中正常访问。

Chrome 68关于证书有效期与SCT个数的政策如下表所示：

*EV证书的生命周期不应多余27个月。

您可以通过MySSL.com官网下的证书信息查询工具检测您的网站是否符合Chrome CT政策。

若您需要对 MySSL.com 上域名的查询信息进行隐藏，则您需要在 EE.MySSL.com 对所查询的域名进行认领，认领成功以后，您可以对已认领的域名在 MySSL.com 中的显示状态进行设置。

域名认领规范

首先请确保您可以对需要认领的域名进行域名解析，因为在认领过程中，我们会对域名的所有权进行验证，若所有权验证失败，将无法成功认领域名；目前我们尚未支持对子域名的认领，若您需要对子域名进行隐藏，则只需要将主域进行认领，便可统一设置该主域名下所有域名的显示状态。

域名认领流程

1、在输入框中填写需要认领的域名，点击域名认领。

2、屏幕上会弹出您需要进行域名解析的信息（若您不小心将对话框关掉，稍后可在认领详情中获取到记录信息并继续进行认证）。

3、前往您申请域名的控制台，对域名进行解析，添加TXT类型记录。

4、解析完成后，点击我已配置完成进行验证（若之前的弹框已关闭，可打开认领详情点击）。

5、稍等片刻，获取认证结果，（若认证失败，请确认认证信息，稍后再试），点击【MySSL报告中隐藏】下的按钮便可完成隐藏。

MySSL v1.20中，主要改动内容如下：

• TLSv1.3检测；
• 证书透明度政策相关检测上线；
• 相关域名批量监控；
• 域名认领功能上线；
• MySSL安全签章上线；
• 新增用户反馈入口；

详细内容如下。

TLS v1.3 正式版上线

8月10号，TLS v1.3正式版发布(RFC 8446)。 在MySSL v1.20中我们支持了TLS v1.3正式版的检测,如下图所示。

证书透明度（CT）政策相关工具

今年早些时候，chrome更新了其CT政策，在Chrome68中正式得以实施。新政策表明凡2018年4月30号后签发的证书如果不符合CT政策，将被Chrome拦截。关于政策的详细内容，另一篇博客将为你详细解读。

MySSL v1.20中，我们支持检测你的站点证书是否符合CT政策。如果你的站点使用的证书不符合CT政策，你的评级将会降至E，如下图所示。

另外，我们还提供了单独的证书透明度检测工具，输入域名即可检测。如下图所示，我们为你提供了更详细的证书透明度信息。

相关域名批量监控

在v1.18中，我们推出相关域名功能。

该功能能将你在MySSL.com检测过的同一主域下的相关域名展示出来。

为了让你能更好的管理域名，你需要点击我想监控这些域名即可将相关域名导入到MySSL企业版中。

然后，你就可以通过MySSL企业版来监控这些域名。

域名认领功能

在推出【相关域名】功能后，我们收到了大量好评。当然，其中也就一些非议的声音。有少部分用户认为我们将其服务IP等信息暴露在大家面前是不对的，要求我们将其记录删除。

面对这样的声音，我们推出了域名认领功能。如下图所示：

在验证了域名所有权（通过TXT记录认证）后，你就可以对MySSL.com这边是否显示相关域名进行操作。

MySSL安全签章

在v1.20中，我们对MySSL签章进行了重新设计。

在新对签章中，只要你点击该签章，你就会看到该页面的安全评级等相关信息，如下图所示。

你可以通过MySSL签章工具申请，然后将生成的html代码插入到你的页面即可。

新增用户反馈入口

用户反馈接口在v1.19中，我们已经加入。已经有不少小伙伴向我们反馈了一些问题。我们非常欢迎你的反馈，我们也会尽可能的为你解决相关问题。或许你的反馈在下一版本中就会得以实现。

一些更新

除了这些较大的功能更新，v1.20在细节上也有需要改进。

v1.20中，我们的兼容性更好了，我们对更多的浏览器进行了适配；

v1.20中，我们对于一些UI细节进行了优化；

v1.20中，客户端握手模拟功能更新了Baidu/Google/Sougou等蜘蛛引擎的模拟；

v1.20中，常用邮件服务商列表新增了STARTTLS评级的展示；

v1.20中，我们还修复了一些BUG。

MySSL.com每一次版本升级，每一次性能优化，每一次Bug Fix 都将在这里记录。

v1.20

• 支持TLSv1.3检测；

• 域名认领功能上线(ee)；

• MySSL安全签章更新；

v1.19

• MySSL签章功能上线；

• 证书透明度合规检测上线；

• 修复了一些BUG，优化了页码细节。

v1.18

• 证书透明度政策相关检测上线；

• 相关域名批量监控；

• MySSL安全签章上线；

• 新增用户反馈入口；

随着 MySSL 企业版的开发进度的推进，我们最近上线了 HTTPS 外链监控的功能。下面是该功能相关使用说明。

进入 MySSL 企业版：

你会获取到类似：https://2d89e693d66a49d6993df623e272311f.myssl-uri.com/api/csp-report 类似的 URL。这是我们为你分配的专属不安全外链的上报地址。

你拿到该地址需要做的是，将该地址添加到服务器的 header 处。

配置规则

在添加之前，你需要了解内容安全策略的配置规则：

• Content-Security-Policy：内容安全策略，当网站加载的内容违背了该策略，浏览器将会阻止该资源的加载，并上报。
• Content-Security-Policy-Report-Only：内容安全策略仅报告，网站加载的资源违背了该策略仍然会被加载，并上报。

一般来说，你不知道自己添加的策略有什么问题，建议你先通过配置 Content-Security-Policy-Report-Only，然后在 MySSL EE 上查看相关报告之后并改正，最后改为 Content-Security-Policy。

常用配置项的说明：

• style-src：指定样式表的加载来源。如 style-src https: 'unsafe-inline'。
• img-src：指定图片的来源。如 img-src https: data: https://xx.xxx.co。
• font-src：指定可提供网页字体的来源。如 font-src https://themes.googleusercontent.com。
• child-src：用于列出适用于工作线程和嵌入的帧内容的网址。如 child-src https://youtube.com。
• connect-src：用于限制可（通过 XHR、WebSockets 和 EventSource）连接的来源。
• media-src：用于限制允许传输视频和音频的来源。
• object-src：可对 Flash 和其他插件进行控制。
• default-src：默认策略，当你没有配置上面的内容策略时，默认使用。
• report-uri：用于指定在违反内容安全政策时浏览器向其发送报告的网址。
• base-uri：用于限制可在页面的 <base> 元素中显示的网址。
• upgrade-insecure-requests：指示 User Agent 将 HTTP 更改为 HTTPS，重写网址架构。 该指令适用于具有大量旧网址（需要重写）的网站，慎用。

一般来说，以 -src 结尾的都适用于 default-src，即在没有指定 xx-src 的情况下将默认使用 default-src。

例：

Content-Security-Policy-Report-Only "default-src https://example.com; font-src https://st.example.com"

这个策略，font-src 只能加载 https://st.example.com 的字体资源，不能加载 https://example.com 的字体资源。其它没有指定的均使用 default-src。

那么，以 xx-src 的内容可以填什么呢，一般可以填写：

• 'none'：不执行任何匹配。
• 'unsafe'：与当前来源（而不是其子域）匹配。
• 'unsafe-inline'：允许使用内联 JavaScript 和 CSS。
• 'unsafe-eval'：允许使用类似 eval 的 text-to-JavaScript 机制。
• https:：以 https: 开头的。
• data:：以 data: 开头的。
• blob:：以 blob 开头的。
• 网址：直接指定网址。

这里列举 Nginx 和 Apache 相关例子，在添加该 header 之前请详细了解 Content-Security-Policy-Report-Only 的作用：

1、Nginx 如何配置

add_header Content-Security-Policy-Report-Only "default-src https: data: 'unsafe-inline' 'unsafe-eval' wss:; report-uri https://2d89e693d66a49d6993df623e272311f.myssl-uri.com/api/csp-report";

2、 Apache 如何配置

Header add Content-Security-Policy-Report-Only "default-src https: data: 'unsafe-inline' 'unsafe-eval' wss:; report-uri https://2d89e693d66a49d6993df623e272311f.myssl-uri.com/api/csp-report"

当 MySSL 企业版获取到上报的外链时，你会看到这样的画面：

如果你想了解更多有关内容安全响应头：

• Content-Security-Policy。
• Content-Security-Policy-Report-Only。

MySSL v1.17中，主要改动内容如下：

• 支持TLSv1.3(Draft28)检测；
• 备用名称缺失提示；
• Expect-CT头部检测；
• XSS保护头部检测；
• Symantec旧平台签发的证书升级提示；
• 更优雅的工具箱展示;
• OCSP证书吊销信息查询；
• 常见邮件服务器（SMTP/IMAP/POP3）评级检测。

部分特性如下图所示：

工具箱展示如下图所示：

OCSP证书吊销信息查询如下图所示：

常见邮件服务器（SMTP/IMAP/POP3）评级检测如下图所示：

接下来，我们带您深入了解一下，此次更新的几个新特性。

TLSv1.3(Draft28)

在v1.17版本中，我们支持了TLSv1.3(Draft 28)的检测，如下图所示。

备用名称缺失

备用名称缺失是指证书的备用名称(subjectAlternativeName)内不包含通用名称(commonName)。对于使用了该类证书的站点，当使用Chrome浏览器访问时会提示NET::ERR_CERT_COMMON_NAME_INVALID 错误,如下图所示：

在谷歌帮助手册中解释了导致被拒的原因。原来在Chrome 58及以上版本只会使用subjectAlternativeName扩展程序（而不是 commonName）来匹配域名和网站证书。也就是说，当在证书备用名称中匹配不到访问站点域名的情况下，Chrome浏览器会出现该错误提示。

此类证书，我们会在报告中给出如下图所示提示：

Expect-CT

期望CT(Expect-CT),该HTTP头部用来告诉浏览器期望证书透明度。期望CT头部允许站点选择报告或强制执行证书透明度要求，这可以防止站点证书错误被忽视的情况。 当站点启用期望CT头部时，浏览器会检查该站点使用的证书是否出现在公共CT日志中，这能有效的避免中间人攻击等HTTPS威胁，让站点更加安全。

部署

期望CT头部规则如下：

Expect-CT: report-uri="<uri>", enforce,max-age=<age>

在部署的时候有两种策略可供选择，一种是仅报告，一种是强制执行。

在仅报告策略中，浏览器在没有收到有效的CT信息情况下，会向report-uri设置的地址发送报告。对于该策略，您可以如下设置：

Expect-CT: max-age=0, report-uri="https://{$subdomain}.report-uri.com/r/d/ct/reportOnly"

该策略下，如果浏览器未收到有效的CT信息，不会终止连接，只会向您指定的URI发送报告。

而第二种策略可如下设置：

Expect-CT: enforce, max-age=30, report-uri="https://{$subdomain}.report-uri.com/r/d/ct/enforce"

这也就是告诉浏览器强制执行该期望CT策略并且缓存该状态30s。如果浏览器没有收到有效的CT信息，将会终止链接同时也会发送报告。在正确的配置好CT信息后，你可以将该时间设置的更长。

XSS保护

XSS保护(X-XSS-Protection),一个防止XSS攻击(跨站脚本攻击)的HTTP头部。部署后，当浏览器侦测到XSS攻击，会根据不同的策略做出相应的反应。

部署

XSS策略主要有四种:

• 0:
  • 关闭XSS过滤功能；
• 1：
  • 开启XSS过滤功能，如果检测到XSS攻击，浏览器会删除不安全部分；
• 1；mode=block :
  • 开启XSS过滤功能，如果检测到XSS攻击的话，浏览器不会渲染网页；
• 1；report="report.exmaple.com" :
  • 开启XSS过滤功能，如果检测到XSS攻击，浏览器将向指定URI报告。

您可以根据具体的安全需求设置该策略，部署实例如下：

X-XSS-Protection	1; mode=block;

以上就是本次更新的一些新特性，如果您有什么意见或建议请联系我们：support@myssl.com。

早些时候，DigiCert完成对了Symantec网站安全和公钥基础设施(PKI)业务的收购，成为了SSL/TLS与PKI全球领先的数字证书提供商。同时，DigiCert签署了一项Sub CA协议，将Symantec升级到DigiCert的PKI可信平台上，且表示将于2017年12月1日验证并升级所有Symantec证书，其详细时间表如下图所示。

从上图中我们可以了解，对于2016年6月1号之前使用Symantec旧平台签发的证书，最终替换时间为3月15日。对于2016年6月1日后签发的证书，最终替换日期为9月13日。

对于还没有替换且尚在有效期内的证书，我们通过Chrome浏览器访问时将被拦截，并显示如下图所示错误。

对于使用该证书的站点，我们将其评级降至E，并提示升级。

注意

距离2016年6月1日后使用Symantec旧平台签发证书的替换时间只有两个月了，使用该类证书的站点，在MySSL.com检测时，我们会给出如下图所示提示，如果您正好在使用该类证书，请尽快更新替换。

检测

您也可以使用我们的Symantec SSL升级检测来检测是否需要更新。

更新

对于一般DV域名型证书，重新申请即可。对于EV或OV证书，您可以联系您的证书提供商协助更新。

PCI DSS，全称Payment Card Industry Data Security Standard,第三方支付行业数据安全标准，是由PCI安全标准委员会制定，力在使国际上采用一致的数据安全措施。

早在去年6月30号PCI安全标准委员会官方发表博文将于2018年6月30号（最晚），也就是本月月底禁用早期SSL/TLS，并实施更安全的加密协议(TLS v1.1或更高版本,强烈建议使用TLS v1.2)以满足PCI数据安全标准的要求，从而保护支付数据。

随着时间的临近，我们提前调整了PCI DSS合规判定标准（在原有的标准之上，支持TLS v1.0或更早的加密协议将会判定为不合规），方便您提前调整您的服务以避免违规的风险。

解决方案

评估兼容性后，禁用TLS1.0

nginx，如下所示:

ssl_protocols                TLSv1.1 TLSv1.2 TLSv1.3;

调整之后别忘了再检测一下。

说明

在未来我们的安全评级也将对TLS1.0做出合适的降级处理，在评估兼容性影响后，还是建议大家关闭TLS1.0, 现在TLS1.3都出来了，未来主流应该是TLS1.2+TLS1.3。

关于关闭TLS1.0的兼容性参考

大多数是比较老旧系统上自带浏览器不支持，如果是主流用户使用的Chrome、Firefox和国产浏览器基本都兼容

最近有人反馈在他们的域名在MySSL检测报告中出现:

很疑惑为什么只是证书链不完整就会降级到B。那在这里简单的说明一下：

浏览器的处理

现代的浏览器都有证书自动下载的功能，但很多浏览器在安装后是使用系统内置的证书库，如果你缺失的那张CA证书，在系统的内置证书库中不存在的话，用户第一次访问网站时会显示如下情况：（以Chrome为例）

即使你的证书确实是可信的，但依旧会显示成不可信，只有等到浏览器自动把缺失的那张CA证书从网上下载下来之后，访问该网站才会显示成可信状态。

硬件设备的处理

大量的硬件设备并不会像浏览器一样下载CA证书，如果你缺失的CA证书不再这些硬件设备的内置证书库中，那么使用这些硬件设备访问网站就会一直显示你的域名是不可信状态。

修复

其实修复的办法很简单，就是在部署证书的时候，把那张缺失的CA证书一并部署。目前一般的证书签发机构在签发证书的时候会把该CA证书一并打包。但如果确实缺失了这张CA证书也不要慌，MySSL能够帮你补全证书链。

使用单独的补全工具

证书补全工具传送门

该工具支持输入域名和上传证书，如果使用输入域名（支持非443端口）的方式，并且您的域名使用双证书策略，修复结果就会如图所示，该工具会对双证书对进行补全（如果双证书都存在缺链的情况）。

MySSL检测工具

MySSL检测报告中暗含着证书链补全的功能：

只要点击下载证书链，会跳转到证书下载页面。
但有一点需要注意：如果您的网站部署了双证书：

下面的下载证书链对应的是上选中证书（蓝色选项卡）的证书链，千万不要下错证书哦。