传输层安全性协议 (Transport Layer Security，缩写作 TLS)，它的前身是安全套接层 (Secure Sockets Layer，缩写作 SSL)，是一个被应用程序用来在网络中安全通信的 protocol（通讯协议），防止电子邮件、网页、消息以及其他协议被篡改或是窃听。
是用来替代SSL的，是一种密码协议，用来提供计算机之间交互的安全通信。主要用于https通信，也用于email，即使通信等。
SSL 即安全套接字层，它在 OSI 七层网络模型中处于第五层，SSL 在 1999 年被 IETF(互联网工程组)更名为 TLS ，即传输安全层，直到现在，TLS 一共出现过三个版本，1.1、1.2 和 1.3 ，目前最广泛使用的是 1.2，所以接下来的探讨都是基于 TLS 1.2 的版本上的。
所有现代浏览器都支持 TLS 协议，它们都要求服务器提供一个有效的digital certificate（数字证书）来确认身份以建立安全连接。如果客户端和服务器都能提供自己的数字证书，则它们可以互相认证。
TLS1.2 和 TLS 1.3 的区别
在 TLS 1.2 的握手中，一般是需要 4 次握手，先要通过 Client Hello （第 1 次握手）和 Server Hello（第 2 次握手） 消息协商出后续使用的加密算法，再互相交换公钥（第 3 和 第 4 次握手），然后计算出最终的会话密钥，下图的左边部分就是 TLS 1.2 的握手过程：
上图的右边部分就是TLS 1.3的握手过程，可以发现TLS 1.3 把 Hello 和公钥交换这两个消息合并成了一个消息，于是这样就减少到只需 1 RTT 就能完成 TLS 握手。
TLS握手协议过程
握手协议是TLS握手协议的一部分，负载生成共享密钥以及交换证书。其中，生成共享密钥是为了进行密码通信，交换证书是为了通信双方相互进行认证。
握手协议这一名称中的“握手”，是服务器和客户端在密码通信之间交换一些必要信息这一过程比喻。
由于握手协议的信息交换是在没有加密的情况下进行的（即使用“不加密”这一密码套件），也就是说，在这一协议中所收发的所有数据都可能被窃听者窃听，因此在这一过程中必须使用公钥密码或DH密钥交换。
服务器认证阶段：
1)客户端向服务器发送一个开始信息“Hello”以便开始一个新的会话连接；
2)服务器根据客户的信息确定是否需要生成新的主密钥，如需要则服务器在响应客户的“Hello”信息时将包含生成主密钥所需的信息；
3)客服根据收到的服务器响应信息，产生一个主密钥，并用服务器的公开密钥加密后传给服务器；
4)服务器恢复该主密钥，并返回给客户一个用主密钥认证的信息，以此让客户认证服务器。
用户认证阶段：
在此之前，服务器已经通过了客户认证，这一阶段主要完成对客户的认证。经认证的服务器发送一个提问给客户，客户则返回(数字)签名后的提问和其公开密钥，从而向服务器提供认证。
HTTPS
HTTPS 在HTTP 的基础下加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。 整体架构如下：
HTTPS 的全称是 Hypertext Transfer Protocol Secure，它用来在计算机网络上的两个端系统之间进行安全的交换信息(secure communication)，它相当于在 HTTP 的基础上加了一个 Secure 安全的词眼，那么我们可以给出一个 HTTPS 的定义：HTTPS 是一个在计算机世界里专门在两点之间安全的传输文字、图片、音频、视频等超文本数据的约定和规范。HTTPS 是 HTTP 协议的一种扩展，它本身并不保传输的证安全性，那么谁来保证安全性呢？在 HTTPS 中，使用传输层安全性(TLS)或安全套接字层(SSL)对通信协议进行加密。也就是 HTTP + SSL(TLS) = HTTPS。
如果网站没有使用HTPPS，谷歌浏览器会显示不安全的提示。
SSL vs TLS
Secure Socket Layer (SSL)是用于为 HTTP 流量提供加密的原始协议,有两个公开发布的 SSL 版本 - 版本 2 和 3, 这两者都有严重的加密弱点，不应再使用.
由于各种原因，该协议的下一个版本（实际上是 SSL 3.1）被命名为传输层安全 (TLS) 版本 1.0。随后发布了 TLS 版本 1.1、1.2 和 1.3。
术语“SSL”、“SSL/TLS”和“TLS”经常互换使用，在许多情况下，当指代更现代的 TLS 协议时会使用“SSL”。此备忘单将使用术语“TLS”，除非是指旧协议。
TLS
安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。较低的层为 TLS 记录协议，位于某个可靠的传输协议(例如 TCP)上面。安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。
TLS的最大优势就在于：TLS是独立于应用协议。高层协议可以透明地分布在TLS协议上面。然而，TLS标准并没有规定应用程序如何在TLS上增加安全性；它如何启动TLS握手协议以及如何解释交换的认证证书的决定权留给协议的设计者和实施者来判断。
SSL协议提供的服务主要有：
1)认证用户和服务器，确保数据发送到正确的客户机和服务器；
2)加密数据以防止数据中途被窃取；
3)维护数据的完整性，确保数据在传输过程中不被改变。
如果正确实施，TLS 可以提供许多安全优势：
机密性 - 防止攻击者读取流量内容。 完整性 - 防止攻击者修改流量。 重放预防 - 防止攻击者对服务器重放请求。 身份验证 - 允许客户端验证它们是否连接到真实服务器（请注意，除非使用客户端证书，否则不会验证客户端的身份）。许多其他协议使用 TLS 来提供加密和完整性，并且可以以多种不同的方式使用,
example1 : The HTTPStrict-Transport-Securityresponse header (often abbreviated asHSTS)
服务器配置Server Configuration
仅支持强协议
SSL 协议有很多弱点，在任何情况下都不应该使用。通用 Web 应用程序应默认为 TLS 1.3（必要时支持 TLS 1.2），并禁用所有其他协议。 如果已知 Web 服务器必须支持带有不受支持的不安全浏览器（例如 Internet Explorer 10）的旧客户端，则可能需要启用 TLS 1.0 来提供支持。
在需要旧协议的情况下，应启用“TLS_FALLBACK_SCSV”扩展，以防止针对客户端的降级攻击。
仅支持强密码
TLS 支持大量不同的密码（或密码套件），它们提供不同级别的安全性。在可能的情况下，应仅启用 GCM 密码
但是，如果需要支持旧客户端，则可能需要其他密码。
至少应始终禁用以下类型的密码：
空密码 匿名密码 导出密码有关安全配置密码的完整详细信息，请参阅 TLS 密码字符串备忘单。
使用强 Diffie-Hellman 参数
使用临时 Diffie-Hellman 密钥交换的密码（由密码名称中的“DHE”或“EDH”字符串表示）应使用足够安全的 Diffie-Hellman 参数（至少 2048 位）
以下命令可用于生成 2048 位参数：
openssl dhparam 2048-outdhparam2048.pem
Weak DH网站提供了有关如何配置各种 Web 服务器以使用这些生成的参数的指导。
禁用压缩
应禁用 TLS 压缩以防止漏洞（绰号为 CRIME），该漏洞可能允许攻击者恢复会话 cookie 等敏感信息。
补丁加密库
除了 SSL 和 TLS 协议中的漏洞外，SSL 和 TLS 库中也存在大量历史漏洞，其中Heartbleed 是最广为人知的。 因此，确保这些库与最新的安全补丁保持同步非常重要。
测试服务器配置
加固服务器后，应测试配置。关于 SSL/TLS 测试的 OWASP 测试指南章节包含有关测试的更多信息。
有许多在线工具可用于快速验证服务器的配置，包括：
SSL Labs Server Test CryptCheck CypherCraft Hardenize ImmuniWeb Observatory by Mozilla Scanigma OWASP PurpleTeamcloud此外，还有许多可以使用的离线工具：
O-Saft - OWASP SSL advanced forensic tool CipherScan CryptoLyzer SSLScan - Fast SSL Scanner SSLyze testssl.sh - Testing any TLS/SSL encryption tls-scan OWASP PurpleTeamlocal关于数字证书
证书内容：如发行机构、有效期、公司信息等
摘要：证书内容等经过hash之后生成摘要
数字签名：CA使用私钥对摘要，加密之后生成签名
数字证书主要由证书内容、公钥、数字签名、使用的hash算法等组成
证书验证分为真实性验证与有效性验证：
真实性验证：
通过内置根证书的公钥对数字签名解密，得到一个hash值，这个hash值就是摘要
使用证书内的hash算法将证书内容进行hash之后得到一个hash值，用这个新的hash值与上一步的hash值进行对比
若相同，证明证书真实有效，若不同，则证明被串改过
有效性验证：
CA会提供一份证书失效名单，浏览器会缓存并定期更新该名单。
CA提供实时接口查询
使用强密钥并保护它们
用于生成密码密钥的私钥必须足够强大，以确保私钥和相应证书的预期寿命。 当前的最佳实践是选择至少 2048 位的密钥大小。 有关密钥寿命和类似密钥强度的更多信息，请参见此处和 NIST SP 800-57。
还应使用文件系统权限和其他技术和管理控制来保护私钥免受未经授权的访问。
使用强密码散列算法
证书应该使用 SHA-256 作为散列算法，而不是旧的 MD5 和 SHA-1 算法。它们具有许多加密弱点，并且不受现代浏览器的信任。
使用正确的域名
证书的域名（或主题）必须与提供证书的服务器的完全限定名称匹配。 从历史上看，这存储在证书的 commonName (CN) 属性中。 但是，现代版本的 Chrome 会忽略 CN 属性，并要求 FQDN 位于 subjectAlternativeName (SAN) 属性中。 出于兼容性原因，证书应在 CN 中具有主要 FQDN，在 SAN 中具有完整的 FQDN 列表。
在创建证书时，应考虑以下几点：
考虑是否还应包括“www”子域。 不要包含不合格的主机名。 不包括 IP 地址。 不要在面向外部的证书中包含内部域名 如果可以使用内部和外部 FQDN 访问服务器，请使用多个证书对其进行配置。仔细考虑使用通配符证书
Reference
https://sslhow.com/ssl-tls-handshake-process TLS握手 Transport Layer Security (TLS) : 该备忘单主要关注如何使用 TLS 保护通过 HTTPS 连接到 Web 应用程序的客户端 RFC 2246 rfc3546/rfc4366:Transport Layer Security (TLS) Extensions rfc4680:TLS Handshake Message for Supplemental Data OWASP - TLS Cipher String Cheat Sheet OWASP - Testing for SSL-TLS, and OWASP Guide to Cryptography OWASP - Application Security Verification Standard (ASVS) - Communication Security Verification Requirements (V9) Mozilla - Mozilla Recommended Configurations NIST - SP 800-52 Rev. 1 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations NIST - NIST SP 800-57 Recommendation for Key Management, Revision 3, Public DRAFT NIST - SP 800-95 Guide to Secure Web Services IETF - RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile IETF - RFC 2246 The Transport Layer Security (TLS) Protocol Version 1.0 (JAN 1999) IETF - RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 (APR 2006) IETF - RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 (AUG 2008) Bettercrypto - Applied Crypto Hardening: HOWTO for secure crypto settings of the most common services)