更好的 TLS 1.3 协议解析
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了更好的 TLS 1.3 协议解析相关的知识,希望对你有一定的参考价值。
参考技术A网络安全篇,面对复杂多变的网络环境,我们需要掌握哪些关于网络安全的相关知识,聊一聊与网络安全相关的:HTTPS、SSL、TLS 等。
《 网络安全 — HTTPS 》
《 网络安全的基石(上)— 加密 》
《 网络安全的基石(下)— 完整性与身份认证 》
《 公钥信任问题 — 数字证书与 CA 》
《 信任始于握手 — TLS 连接过程详解 》
《TLS 1.3 特性解析》
《 如何优化 HTTPS 连接 》- 待完善
早在 2013 年,IETF(互联网工程小组) 就对 TLS 1.2 的过时设计和两次往返开销心生不满,因此开始着手准备新版本的 TLS。同年 8 月由 Eirc Rescorla 提议出新版本 TLS 的 功能愿望清单 。在经过一番 辩论 后,最终该提议内容被定义为 TLS 1.3。推动 TLS 1.3 设计的主要问题大概有:
终于在 2018 年 8 月 10 日,历经 4 年时间,TLS 1.3 最终版本发布了 — RFC-8446 。新的协议使得互联网变得更快、更安全;随着 TLS 1.3 的采用率不断提高,它势必会长远影响互联网的发展;同时尽快将 TLS 1.3 平滑应用到线上环境无疑是势在必行。
不过在这之前, TLS 1.2 的应用也已经有 10 年(2008 年)的时间了,毕竟历经了种种考验,新的协议在推广和部署上必定会带来新的挑战。接下来我们就来看看新版本的 TLS 是如何做的?
由于 TLS 1.1/1.2 等协议已经出现了很多年,很多应用软件、中间代理(Middlebox)只认老的记录协议格式,更新改造很困难,甚至僵化。
可部署性
正式由于这些中间代理/软件(Middlebox)在新的更改中表现不佳,即使是对 TLS 1.3 协议的细微更改(例如消除冗余的 ChangeCipherSpec 消息,版本号从 0x03 升级为 0x04),也最终导致了某些设备的连接失败问题。这也是 TLS 1.3 从草稿到最终发布花费了这么长时间的重要原因之一。
为了保证这些被广泛部署的“旧设备”能够继续使用,TLS 1.3 不得不做出妥协,通过“伪装”来实现兼容:保持现有的记录格式不变,使得 TLS 1.3 看上去“像是” TLS 1.2。
扩展协议
那么,如何区分是 1.2 还是 1.3 呢?
这里用到一个新的 扩展协议 (Extension Protocol),它有点“补充条款”的意思,通过在记录末尾添加一系列的“扩展字段”来增加新的功能,旧版本的 TLS 不认识它可以直接忽略,这就实现了“向后兼容”。
TLS 1.3 正是利用扩展实现了许多重要的功能,比如 “supported_groups” “key_share” “signature_algorithms” “server_name” 等。
在经历十余年的实践中获得许多宝贵经验的 TLS 1.2 陆续发现了很多的漏洞和加密算法的弱点。因此消除潜在的危险设计来纠正以前的错误成为 TLS 1.3 的设计目标之一。所以新版本的 TLS 协议里要修补这些不安全的因素。
例如:
固定密钥交换
经过这样一番“减肥瘦身”之后,TLS 1.3 的密钥交换算法只有 ECDHE 和 DHE 了,关于椭圆曲线(ECC)也被“砍”到只剩 P-256 和 x25519 等 5 种。
首先来说下废除 RSA 和 DH 密钥交换算法的原因:
由于客户端默认会选择 ECDHE 而非 RSA 做密钥交换,这是因为它不具有“ 前向安全 ”(Forward Secrecy):“假设有人长期记录了加密的数据,然后在后续的某个时间段获得了服务器的 RSA 私钥,那么黑客就能够使用该私钥解密出之前所有报文的 “Pre-Master”,再计算出会话密钥,破解所有密文。这便是 今日截获,明日破解 ”
而 ECDHE 算法在每次握手时都会生成一对临时公钥和私钥,每次通信的秘钥对都是不同的,也就是“一次一密”,即使黑客花大力气破解了这一次的会话密钥,也只是这次通信被攻击,之前的历史消息不会受到影响,仍然是安全的。
所以现在主流的服务器和客户端在握手阶段都已经不再使用 RSA,改用 ECDHE,而 TLS 1.3 在协议里明确废除了 RSA 和 DH 则在标准层面保证了“前向安全”。
固定密码
多年以来,密钥交换机制不是唯一引起安全漏洞的部分,对称密钥部分也有相当一部分问题。
同样,用于对称加密的算法在经过“减肥瘦身”之后也只保留了 AES、ChaCha20 ,分组模式只能用 AEAD 的 GCM、CCM 和 Poly1305,摘要算法也只能用 SHA 256、SHA 384。
这样原来众多的加密算法、参数组合导致密码套件非常复杂,难以选择。而经过瘦身之后的 TLS 1.3 只剩下 5 个套件,使得客户端或服务端在选择密码套件时变得“更加容易”。然而更重要的是,这些算法在 TLS 长期的实践过程中先后已经被证实是构成不安全的因素,从而导致安全漏洞。
修复数字签名
经过前面的学习,相信你也知道 TLS 另一个重要部分是身份验证。在每个连接中服务都是用具有公钥的数字证书向客户端提供身份认证。在 RSA 加密模式下,服务器通过解密预主密钥并通过对话记录计算 MAC 来证明其对私钥的所有权。在 Diffie-Hellman 模式下,服务器使用数字签名来证明私钥的所有权。
在 TLS 1.2 和更早的版本中,服务器的签名仅涵盖部分握手。用于协商使用哪种对称密码的部分没有由私钥签名。这也导致许多引人注目的漏洞 FREAK , LogJam 等。而在 TLS 1.3 由于服务器对整个握手记录进行签名,因此可以避免这些情况。
HTTPS 建立连接时除了要做 TCP 握手,还要做 TLS 握手,在 TLS 1.2 中会多花两个消息往返(2 - RTT),这可能导致几十毫秒甚至上百毫秒的延迟,在移动网络中延迟还会更严重。
1-RTT 模式
密码套件的大幅度简化,也就没有必要再像以前那样走复杂的的协商流程了。TLS 1.3 压缩了以前的 “Hello” 协商过程,删除了 “Key Exchange” 消息,把握手时间减少到了 “1-RTT”,效率提高了一倍。
下面是 TLS 1.3 握手过程的简图,注意与前面介绍的 TLS 1.2 对比区别在哪里。
0-RTT 恢复
除了标准的 “1-RTT” 握手,受 QUIC 协议的启发,客户端可以在其第一条消息中将加密的数据发送到服务器,与未加密的 HTTP 相比,没有额外的延迟成本。
在 TLS 1.2 中,有两种恢复连接的方法:会话 ID 和会话 Ticket,而 1.3 则将他们组合在一起形成称为 PSK(pre-shared key,预共享密钥)恢复的新模式。
握手分析
目前 nginx 等 Web 服务器都能够很好的支持 TLS 1.3,但是要求底层的 OpenSSL 必须是 1.1.1。因此如果要部署需要先升级你的 OpenSSL 版本。
首先TCP 建立连接之后,浏览器首先还是发一个 “ Client Hello ”。
由于 1.3 的消息要兼容 1.2,所以开头的版本号、支持的密码套件和随机数(Client Random)结构都是一样的(这时的随机数是 32 个字节)。
注意 “Client Hello” 里的扩展,“ supported_versions ” 表示这是 TLS 1.3,“ supported_groups ” 是支持的曲线,“ key_share ”是曲线对应的参数。
这有点是像是“有话尽量一口气说完”,还是按照老规矩进行“打招呼”,我这边有这些信息,考虑到版本升级,所以附带了一些信息,可能后面会用到。
服务器收到 “Client Hello” 同样返回 “Server Hello” 消息,还是要给出一个 随机数 (Server Random)和选定密码套件。
表面上看 Version 和 TLS 1.2 是一样的,重点是后面的扩展。“ supported_versions ” 里确认使用的是 TLS 1.3,然后在 “ key_share ” 扩展带上曲线和对应的公钥参数。
服务器的回应还是老套路,服务端对客户端的提供的信息作出选择,另外服务端还要再附加上几个参数,这次加密就协商定了。
可以看到相比 TLS 1.2 的握手过程,TLS 1.3 仅用两条消息就共享了 4 个信息: Client Random 和 Server Random 、 Client Params 和 Server Params 。两边就可以各自用 DH 算出 “ Pre-Master ”,再用 HKDF 生成主密钥 “ Master Secret ”,效率比 TLS 1.2 提高了一大截。
在计算出主密钥后,服务器立刻发出 “ Change Cipher Spec ” 消息,比 TLS 1.2 提早进入加密通信,后面的证书等就都是加密的了,减少握手时明文信息泄露。
TLS 1.3 还多了一个 “ Change Cipher Spec ” 消息,服务器用私钥把前面的曲线、套件、参数等握手数据加了签名,作用和 “ Finished ” 消息差不多。但由于是私钥签名,所以强化了身份认证和防篡改。
两个“打招呼”消息之后,客户端验证服务器证书,再发 “Finished” 消息,就正式完成了握手,开始收发 HTTP 报文。
现在已经有很多网站都支持了 TLS 1.3,例如 GitHub :
今天我们主要介绍了 TLS 1.3 的一些新特性,简单总结下来主要包含下面几点:
TLS 1.3 涉及的内容很多,有关它的更详细信息请去参照 RFC-8446 ,关于这部分大家还有哪些要分享的呢?欢迎您的留言或指正。
网络安全系列专题
扩展阅读
SSL/TLS深度解析--测试TLS/SSL加密
- 项目地址
https://github.com/drwetter/testssl.sh
testssl.sh 是一个免费且开源的功能丰富的命令行工具,用于在 Linux/BSD 服务器上检查支持加密,协议和一些加密缺陷的支持 TLS/SSL 加密的服务。
testssl
git clone --depth 1 --branch 2.9.5 https://github.com/drwetter/testssl.sh.git
- 错误
Fatal error: Neither "dig", "host", "drill" or "nslookup" is present
- 解决方法
[[email protected] testssl.sh]# yum install bind-utils -y
- 常用参数
-b,-v:这2个是显示版本的testssl自身的信息
-V:输出现有的本机密码套件列表
-t(--startssl):指明要测试的协议:
https ,ftp,smtp,pop3,imap,xmpp,telnet,ldap,postgres,mysql,
其中 telnet,ldap,postgres ,mysql 这4个协议要指定openssl
--mode < serial| parallel> 模式,默认是串行模式,若多核CPU大规模测试可选并行
--parallel:选项启用并行测试 (默认是串行),等同于 --mode parallel
-e:测试每个密码套件
-E:测试每个协议(SSL2 SSL3 TLS1 TLS1.1 TLS1.2
)
-s (--std):测试加密强度很高的一些密码套件
-p(--protocols ) :测试每个TLS与SSL协议 并且检测 spdy 与 http2
-S:测试并显示服务器端证书信息
-P:测试并显示服务器偏好(也就是服务器优先配置的TLS协议和密码套件)
-x( --single-cipher <pattern> ): 指定一个密码套件,也就是测试一下是否支持指定的这个套件
-c:测试客户端支持情况
-h (--header):测试是否支持 HSTS, HPKP, cookie ,ipv4 ,代理 ,安全头部等
-U:测试所有的漏洞
所有漏洞
-H, --heartbleed:tests for Heartbleed vulnerability
-I, --ccs, --ccs-injection:tests for CCS injection vulnerability
-T, --ticketbleed:tests for Ticketbleed vulnerability in BigIP loadbalancers
-R, --renegotiation:tests for renegotiation vulnerabilities
-C, --compression, --crime:tests for CRIME vulnerability (TLS compression issue)
-B, --breach:tests for BREACH vulnerability (HTTP compression issue)
-O, --poodle:tests for POODLE (SSL) vulnerability
-Z, --tls-fallback:checks TLS_FALLBACK_SCSV mitigation
-W, --sweet32:tests 64 bit block ciphers (3DES, RC2 and IDEA): SWEET32 vulnerability
-A, --beast:tests for BEAST vulnerability
-L, --lucky13:tests for LUCKY13
-F, --freak:tests for FREAK vulnerability
-J, --logjam:tests for LOGJAM vulnerability
-D, --drown:tests for DROWN vulnerability
-f, --pfs, --fs, --nsa:checks (perfect) forward secrecy settings
-4, --rc4, --appelbaum:which RC4 ciphers are being offered?
-6:支持ipv6
--ip [one]: 直接测试ip所指向的地址,不使用DNS解析出来的ip地址; 参数one 是指使用NDS解析返回的第一个IP地址,因为很多站点会有多个IP,那么会重复测试多次。
-n (--nodns) :不使用DNS
--sneaky:在服务器端少留痕迹
--quiet:不输出banner
--fast:只显示第一个密码套件 与-P 合用
--log:输出文档(有默认名称)
--logfile:指定一个输出文档
--json:json格式的文档 (有默认名称)
--jsonfile:指定一个json格式文档
--csv:csv格式的文档 (有默认名称)
--csvfile:指定一个csv 格式文档
--html:html 格式文档 (有默认名)
--htmlfile:指定一个html文档
--append:允许追加
- 测试
[[email protected] testssl.sh]# ./testssl.sh --quiet 172.16.216.188
Start 2018-11-10 23:08:40 -->> 172.16.216.188:443 (172.16.216.188) <<--
rDNS (172.16.216.188): --
Service detected: HTTP
Testing protocols via sockets except SPDY+HTTP2
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 offered
TLS 1.1 offered
TLS 1.2 offered (OK)
SPDY/NPN http/1.1 (advertised)
HTTP2/ALPN http/1.1 (offered)
Testing ~standard cipher categories
NULL ciphers (no encryption) not offered (OK)
Anonymous NULL Ciphers (no authentication) not offered (OK)
Export ciphers (w/o ADH+NULL) not offered (OK)
LOW: 64 Bit + DES encryption (w/o export) not offered (OK)
Weak 128 Bit ciphers (SEED, IDEA, RC[2,4]) not offered (OK)
Triple DES Ciphers (Medium) not offered (OK)
High encryption (AES+Camellia, no AEAD) offered (OK)
Strong encryption (AEAD ciphers) offered (OK)
Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4
PFS is offered (OK) ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA
Elliptic curves offered: prime256v1 secp384r1 secp521r1 X25519 X448
Testing server preferences
Has server cipher order? yes (OK)
Negotiated protocol TLSv1.2
Negotiated cipher ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Cipher order
TLSv1: ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES256-SHA AES128-SHA AES256-SHA
TLSv1.1: ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES256-SHA AES128-SHA AES256-SHA
TLSv1.2: ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES256-SHA AES128-SHA AES256-SHA
Testing server defaults (Server Hello)
TLS extensions (standard) "renegotiation info/#65281" "EC point formats/#11" "session ticket/#35" "next protocol/#13172"
"max fragment length/#1" "application layer protocol negotiation/#16" "encrypt-then-mac/#22"
"extended master secret/#23"
Session Ticket RFC 5077 hint 300 seconds, session tickets keys seems to be rotated < daily
SSL Session ID support yes
Session Resumption Tickets: yes, ID: no
TLS clock skew Random values, no fingerprinting possible
Server Certificate #1 (in response to request w/o SNI)
Signature Algorithm ECDSA with SHA384
Server key size RSA 2048 bits
Fingerprint / Serial SHA1 126CAC24E8D08ED4BB90B330D166929C57D39A0D / 92F43BDFF9AC3B5CAA3189D661C69AFA
SHA256 5C9AD396AE017DC395BF9720D3D00BAC6C5C28CBF1AA2D921F32930B125F9336
Common Name (CN) www.linuxplus.com
subjectAltName (SAN) missing (NOT ok) -- Browsers are complaining
Issuer root_ca (CAdevops from CN)
Trust (hostname) certificate does not match supplied URI
Chain of trust NOT ok (chain incomplete)
EV cert (experimental) no
Certificate Expiration 294 >= 60 days (UTC: 2018-11-05 21:27 --> 2019-09-01 21:27)
# of certificates provided 1
Certificate Revocation List NOT ok -- neither CRL nor OCSP URI provided
OCSP URI --
OCSP stapling --
OCSP must staple no
DNS CAA RR (experimental) --
Certificate Transparency no
Server Certificate #2 (in response to request w/o SNI)
Signature Algorithm ECDSA with SHA256
Server key size ECDSA 256 bits
Fingerprint / Serial SHA1 F8DBD1BC27D744AC23C31C505C58FB55B33C7085 / 92F43BDFF9AC3B5CAA3189D661C69AFC
SHA256 5C7FAD30072D151AD5D6EA1EC0CCA669C6C7A1E8CB66E3AC2341502763723409
Common Name (CN) www.linuxplus.com
subjectAltName (SAN) missing (NOT ok) -- Browsers are complaining
Issuer root_ca (CAdevops from CN)
Trust (hostname) certificate does not match supplied URI
Chain of trust NOT ok (chain incomplete)
EV cert (experimental) no
Certificate Expiration 364 >= 60 days (UTC: 2018-11-10 22:32 --> 2019-11-10 22:32)
# of certificates provided 1
Certificate Revocation List NOT ok -- neither CRL nor OCSP URI provided
OCSP URI --
OCSP stapling --
OCSP must staple no
DNS CAA RR (experimental) --
Certificate Transparency no
Testing HTTP header response @ "/"
HTTP Status Code 200 OK
HTTP clock skew 0 sec from localtime
Strict Transport Security --
Public Key Pinning --
Server banner nginx/1.15.5
Application banner --
Cookie(s) (none issued at "/")
Security headers --
Reverse Proxy banner --
Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension
CCS (CVE-2014-0224) not vulnerable (OK)
Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK)
Secure Renegotiation (CVE-2009-3555) not vulnerable (OK)
Secure Client-Initiated Renegotiation not vulnerable (OK)
CRIME, TLS (CVE-2012-4929) not vulnerable (OK)
BREACH (CVE-2013-3587) no HTTP compression (OK) - only supplied "/" tested
POODLE, SSL (CVE-2014-3566) not vulnerable (OK)
TLS_FALLBACK_SCSV (RFC 7507) Downgrade attack prevention supported (OK)
SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK)
FREAK (CVE-2015-0204) not vulnerable (OK)
DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK)
make sure you don‘t use this certificate elsewhere with SSLv2 enabled services
https://censys.io/ipv4?q=5C9AD396AE017DC395BF9720D3D00BAC6C5C28CBF1AA2D921F32930B125F9336 could help you to find out
LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected
BEAST (CVE-2011-3389) TLS1: ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES256-SHA AES128-SHA
AES256-SHA
VULNERABLE -- but also supports higher protocols (possible mitigation): TLSv1.1 TLSv1.2
LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS
RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK)
Testing 359 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (RFC)
-----------------------------------------------------------------------------------------------------------------------------
xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 256 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 256 AESGCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
xc014 ECDHE-RSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
xc00a ECDHE-ECDSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA
xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 256 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
xc02b ECDHE-ECDSA-AES128-GCM-SHA256 ECDH 256 AESGCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
xc027 ECDHE-RSA-AES128-SHA256 ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
xc009 ECDHE-ECDSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA
Running client simulations via sockets
Android 2.3.7 TLSv1.0 AES128-SHA
Android 4.1.1 TLSv1.0 ECDHE-ECDSA-AES128-SHA, 256 bit ECDH (P-256)
Android 4.3 TLSv1.0 ECDHE-ECDSA-AES128-SHA, 256 bit ECDH (P-256)
Android 4.4.2 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Android 5.0.0 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Android 6.0 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Android 7.0 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
Chrome 51 Win 7 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
Chrome 57 Win 7 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
Firefox 49 Win 7 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Firefox 53 Win 7 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
IE 6 XP No connection
IE 7 Vista TLSv1.0 ECDHE-ECDSA-AES128-SHA, 256 bit ECDH (P-256)
IE 8 XP No connection
IE 8 Win 7 TLSv1.0 ECDHE-ECDSA-AES128-SHA, 256 bit ECDH (P-256)
IE 11 Win 7 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
IE 11 Win 8.1 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
IE 11 Win Phone 8.1 Update TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
IE 11 Win 10 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Edge 13 Win 10 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Edge 13 Win Phone 10 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Opera 17 Win 7 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
Safari 5.1.9 OS X 10.6.8 TLSv1.0 ECDHE-ECDSA-AES128-SHA, 256 bit ECDH (P-256)
Safari 7 iOS 7.1 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
Safari 9 OS X 10.11 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Safari 10 OS X 10.12 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Apple ATS 9 iOS 9 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Tor 17.0.9 Win 7 TLSv1.0 ECDHE-ECDSA-AES128-SHA, 256 bit ECDH (P-256)
Java 6u45 TLSv1.0 AES128-SHA
Java 7u25 TLSv1.0 ECDHE-ECDSA-AES128-SHA, 256 bit ECDH (P-256)
Java 8u31 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
OpenSSL 1.0.1l TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
OpenSSL 1.0.2e TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Done 2018-11-10 23:10:25 [ 107s] -->> 172.16.216.188:443 (172.16.216.188) <<--
[[email protected] testssl.sh]# ./testssl.sh -c --quiet --html 172.16.216.188
[[email protected] testssl.sh]# ll *.html
-rw-r--r--. 1 root root 5687 11月 24 15:59 172.16.216.188_p443-20181124-1558.html
[[email protected] testssl.sh]# ./testssl.sh -c --quiet --log 172.16.216.188
[[email protected] testssl.sh]# ll *.log
-rw-r--r--. 1 root root 985 11月 24 16:04 172.16.216.188_p443-20181124-1604.log
[[email protected] testssl.sh]# ./testssl.sh --quiet -U 172.16.216.188
Start 2018-11-24 16:06:40 -->> 172.16.216.188:443 (172.16.216.188) <<--
rDNS (172.16.216.188): --
Service detected: HTTP
Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension
CCS (CVE-2014-0224) not vulnerable (OK)
Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK)
Secure Renegotiation (CVE-2009-3555) not vulnerable (OK)
Secure Client-Initiated Renegotiation not vulnerable (OK)
CRIME, TLS (CVE-2012-4929) not vulnerable (OK)
BREACH (CVE-2013-3587) no HTTP compression (OK) - only supplied "/" tested
POODLE, SSL (CVE-2014-3566) not vulnerable (OK)
TLS_FALLBACK_SCSV (RFC 7507) Downgrade attack prevention supported (OK)
SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK)
FREAK (CVE-2015-0204) not vulnerable (OK)
DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK)
make sure you don‘t use this certificate elsewhere with SSLv2 enabled services
https://censys.io/ipv4?q=5C9AD396AE017DC395BF9720D3D00BAC6C5C28CBF1AA2D921F32930B125F9336 could help you to find out
LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected
BEAST (CVE-2011-3389) TLS1: ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES256-SHA AES128-SHA
AES256-SHA
VULNERABLE -- but also supports higher protocols (possible mitigation): TLSv1.1 TLSv1.2
LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS
RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK)
以上是关于更好的 TLS 1.3 协议解析的主要内容,如果未能解决你的问题,请参考以下文章