更好的 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 协议解析的主要内容,如果未能解决你的问题,请参考以下文章

HTTPS协议TLS协议证书认证过程解析

Docker安全之TLS加密通讯解析与配置验证

pfSense配置基于TLS协议的DNS(DoT)

开启 TLS 1.3 加密协议,极速 HTTPS 体验

又拍云 CDN 正式支持 TLS 1.3 加密协议,一键开启极速 HTTPS 体验

TLS/DTLS wireshark抓包端口设置