tls压缩

㈠ 什么是TLS协议

安全传输层协议（TLS）用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。
TLS 协议包括两个协议组―― TLS 记录协议和 TLS 握手协议――每组具有很多不同格式的信息。
TLS 记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用 MAC 、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等，然后将它们传送到高层客户机。
TLS 连接状态指的是TLS 记录协议的操作环境。它规定了压缩算法、加密算法和 MAC 算法。
TLS 记录层从高层接收任意大小无空块的连续数据。密钥计算：记录协议通过算法从握手协议提供的安全参数中产生密钥、 IV 和 MAC 密钥。TLS 握手协议由三个子协议组构成，允许对等双方在记录层的安全参数上达成一致、自我认证、例示协商安全参数、互相报告出错条件。

㈡ 更好的 TLS 1.3 协议解析

网络安全篇，面对复杂多变的网络环境，我们需要掌握哪些关于网络安全的相关知识，聊一聊与网络安全相关的：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 ，关于这部分大家还有哪些要分享的呢？欢迎您的留言或指正。

网络安全系列专题

扩展阅读

㈢ tls1.2安全吗

是的，属于安全协议，目前最新版本：TLS1.3

㈣ 通信安全：哈希、加密、证书、签名、密钥协商、ECDH、TLS、DTLS

哈希也叫散列，是把任意长度的输入通过散列算法变换成固定长度的输出，该输出就是散列值，也叫摘要（Digest）。

这种转换是一种 压缩映射。 也就是，散列值的空间通常远小于输入的空间，不同的输入可能会散列成相同的输出，所以不可能从散列值来确定唯一的输入值，但如果输出的位数足够，不同输入散列成相同输出的概率非常非常小。

简单的说， 散列就是一种将任意长度的消息压缩到某一固定长度的消息摘要的过程 。

散列是不可逆的 ，也就是无法通过输出还原输入，此特性常被用于密码保存。

SHA-512、MD5等都是着名的散列函数，MD5生成的散列码是128位，甚至MD5就是哈希的同名词，你可以通过网站：https://passwordsgenerator.net/sha512-hash-generator/ 在线计算哈希。

散列有什么用？

加密就是把 明文变成密文的过程，解密就是反方向把密文变成明文 。

比如着名的 凯撒密码 ，就是把每个字对应到另一个，这样的话，只要有密码本，就能对照完成加解密。比如最简单的，对于英文26个字母，每个字母右移3个，abc变成def，这也是一种加密，当然这种加密很简单，很容易被破译。

而诸如AES（高级加密标准）、3DES（三重数据加密算法）则被公认为很难破解，不过山东大学女教授王小云很厉害，破解了MD5和SHA-1，迫使加密标准升级，最终当上了院士。

对称加密

对称加密就是加解密的密钥是一样的，优点是快，这也是传统的加密方式，像AES、3DES都是对称加密。

非对称加密

非对称加密用于加解密的密钥不一样，有2个密钥，公钥和私钥，公钥可以公开，私钥妥善保管。RSA、ECC（椭圆曲线加密算法）、DH（密钥交换算法）这些都是非对称加密。

非对称加密很慢，有多慢？相比对称加密慢1000倍，因为慢，所以它常用于密钥协商（Handshake），协商出会话密钥后，再用对称密钥加密通信数据。

1976年，Whitfield Diffie和Martin Hellman首次提出了非对称加密的概念，该算法被称为Diffie-Hellman密钥交换。然后在1978年，麻省理工学院的Ron Rivest，Adi Shamir和Leonard Adleman发表了RSA 算法。这些都可以被视为非对称加密的基础。

非对称加密也称为公钥基础结构，又称PKI。 非对称加密的提出是密码学上的一次革命，影响深远。

非对称加密算法用私钥加密，用公钥解密，或者用公钥加密，用私钥解密。

证书就是为了证明我是我，比如你要访问中国银行网站，但中行官网如何证明它是中行官网呢？答案就是数字证书。

CA是数字证书中心，服务器需要找CA做认证，让CA给自己颁布数字证书，数字证书内一般包含服务的一些信息、以及服务器的公钥，通过CA的私钥加密后，产生的数字证书，因为CA的权威性，且它的公钥天下皆知，所以，如果你能用CA的公钥解开证书，那便可证明该证书一定是CA颁发的，要不然它不会有CA的私钥，也便没法产生可用CA公钥解密的证书。

所以，由此可见，数字证书用到了非对称加密。

日常生活中也有签名，每个人的笔迹是不一样的，你刷卡消费后在账单签上大名，服务员校验过之后保存下来，你哪天赖账，便可以有签名为证，因为别人写的字跟你的笔迹终有差别。

那数字签名是什么呢？比如a发一封email，接收方怎么证明这封信是a写的？

本质上，数字签名也是利用了非对称加密。

前面讲了，非对称加密有公钥和私钥，如果发生方用私钥加密，然后接收方用发送方的公钥可以解密，那便可以证明是从某发送方发送的，因为别人拿不到你的私钥，也便无法用你的私钥加密，你不能抵赖。

数字签名通常先对内容算哈希，产生内容摘要，再用私钥加密，得到签名。

下面举一个例子来说明这几个问题：

张三有2把钥匙，一把公钥，公告天下，一把私钥，妥善保管，只有自己知道，很明显，非对称加密。

李四给张三写信，写完之后，用张三的公钥加密，通过邮局寄给张三，即使邮递员拆开信封看，他也看不懂，因为内容是密文，只有张三的密钥才能解密。

张三收到信后，用私钥解密，可以正常阅读。

现在张三要给李四回信，写完后，用hash函数生成摘要digest。

然后张三，再用私钥对摘要加密，生成数字签名signature。

然后把签名附在信的下面，一起发给李四。

过程是：信明文 -> hash -> digist -> 私钥加密 -> signature。

李四收到回信后，用张三的公钥对数字签名解密，得到摘要，由此证明，信确实是张三发出的，为什么？因为如果不是张三发的，那写信的人就没有张三私钥，用别的私钥加密得到的签名，是无法用张三的公钥解开的。

李四，再对信的内容做hash，得到摘要，与上一步得到的摘要对比，如果一致，则证明信的内容没有被修改过，信的内容是完整的。

复杂的情况出现了。

王五，用自己的公钥替换李四保存的张三的公钥，也就是王五欺骗了李四，李四误把王五的公钥当张三的公钥，这样一来，王五就能冒充张三给李四写信（王五用自己的私钥加密）。

问题是什么？问题是李四不能确信自己保存的公钥真的是张三的公钥。如果客户端电脑上存的工商银行官网的公钥，实际上是骗子公司的公钥，那就麻烦大了。

怎么破？让张三去认证中心CA（Certificate Authority），为公钥做认证，怎么做呢？CA中心用自己的私钥，对张三的公钥和其他相关信息一起加密，生成数字证书（Digital Certificate）。

张三拿到数字证书后，以后给李四回信，在签名的同时，附带上数字证书。

李四收到信之后，从CA的公钥解开数字证书，取出张三的公钥（一定是真的），然后就能放心的愉快的按之前的流程解开签名了。

数字证书加入后，核心区别就是张三的公钥不再保存在李四处，而是通过数字证书下发。

为什么数字证书里的张三的公钥一定是真的呢？因为CA是权威机构，假设全世界就一家（其实不止，但也不多），它的公钥天下尽知，就是固定的串，所以能用CA公钥解开的证书，一定是CA颁布的，因为CA用它的私钥加密产生的证书。很明显，非对称加密能用于证明我是我。

密钥交换算法

着名的DH密钥交换算法，这个算法很有意思，也很巧妙，简而言之，就是通信双方交换一点信息（不怕被偷看到），然后就在两端，分布产生出一个相同的密钥，神奇啊。

有一个很有意思的例子。

Alice和Bob要协商出一个公共的颜色，他们可以交换信息，但交换的信息，可以被偷看到，怎么办？既能协商出公共颜色，又不能让别人知道呢。

密钥交换算法的原理跟这个差不多，网上有大量的资料讲述这个问题，我觉得理解了上面的例子，再看ECDH便也不难了。

众所周知http是互联网协议，但是它不够安全，所以后面有改进版的https，其实就是多了一个TLS，这个是传输层加密，本质上，就是通过handshake，协商出一个会话密钥，后面的数据传递，都用这个密钥做对称加解密。

我们经常讲安全通道，其实也就是协商出一个会话密钥，他并不神秘。胡乱放几张图片吧。

为了减少这几个RTT，又想了各种办法，然后复用连接的话，就可以做到0RTT，1RTT了。

就说这些吧，最后抛几个名词，有兴趣自行网络学习：DTLS，HMAC，AEAD，重放攻击，放大攻击，是不是很高端？

㈤ 如何使用 TLS/SSL 确保 WebSocket 连接的安全

TLS 为传输层安全性协议，是 MySQL 在客户端与服务器之间进行加密连接的协议。TLS 有时被称为 SSL（安全套接层），但是 MySQL 实际上并不使用 SSL 协议进行加密连接，因为它的加密很弱。TLS 协议通过加密数据来确保在两个通信应用程序之间提供隐私和数据完整性，以便任何第三方都无法拦截通信。它还会验证对等方以验证其身份。通过在两个对等点之间提供安全的通信通道，TLS 协议可以保护消息的完整性并确保其不会被篡改。MySQL 支持多种 TLS 版本协议，此次测试使用 8.0 的 client 为 TLSv1.2。

从 wireshark 中看一下 TLS 握手的步骤：

㈥ TLS协议的协议结构

TLS 协议包括两个协议组―― TLS 记录协议和 TLS 握手协议――每组具有很多不同格式的信息 。
TLS 记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用 MAC 、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等，然后将它们传送到高层客户机。
TLS 连接状态指的是TLS 记录协议的操作环境。它规定了压缩算法、加密算法和 MAC 算法。
TLS 记录层从高层接收任意大小无空块的连续数据。密钥计算：记录协议通过算法从握手协议提供的安全参数中产生密钥、 IV 和 MAC 密钥。TLS 握手协议由三个子协议组构成，允许对等双方在记录层的安全参数上达成一致、自我认证、例示协商安全参数、互相报告出错条件。
TLS握手协议：
1.改变密码规格协议
2.警惕协议
3.握手协议

㈦ SSL/TLS协议原理解读

HTTPS是什么相信大家都知道，如果你不知道。。。请关闭此文！！！
HTTP的数据是明文传输的，没有安全性可言。HTTPS是秘文传输，那么HTTPS是怎么实现数据的安全(加密)传输的？那是因为HTTPS比HTTP多了个'S'。 即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

SSL/TLS协议是网络安全通信的重要基石，本文将简单介绍SSL/TLS协议，主要关注SSL/TLS协议的安全性，特别是SSL规范的正确实现。 本系列的文章大体分为几个部分：

1、SSL/TLS简介
2、SSL/TLS协议的基本流程
3、从SSL到TLS
4、SSL/TLS的流行实现库

SSL全称是Secure Sockets Layer，安全套接字层，它是由网景公司(Netscape)设计的主要用于Web的安全传输协议，目的是为网络通信提供机密性、认证性及数据完整性保障。如今，SSL已经成为互联网保密通信的工业标准。

SSL最初的几个版本(SSL 1.0、SSL2.0、SSL 3.0)由网景公司设计和维护，从3.1版本开始，SSL协议由因特网工程任务小组(IETF)正式接管，并更名为TLS(Transport Layer Security)，发展至今已有TLS 1.0、TLS1.1、TLS1.2这几个版本。

如TLS名字所说，SSL/TLS协议仅保障传输层安全。同时，由于协议自身特性(数字证书机制)，SSL/TLS不能被用于保护多跳(multi-hop)端到端通信，而只能保护点到点通信。

SSL/TLS协议能够提供的安全目标主要包括如下几个：

认证性——借助数字证书认证服务器端和客户端身份，防止身份伪造

机密性——借助加密防止第三方窃听

完整性——借助消息认证码(MAC)保障数据完整性，防止消息篡改

重放保护——通过使用隐式序列号防止重放攻击

为了实现这些安全目标，SSL/TLS协议被设计为一个两阶段协议，分为握手阶段和应用阶段：

握手阶段也称协商阶段，在这一阶段，客户端和服务器端会认证对方身份(依赖于PKI体系，利用数字证书进行身份认证)，并协商通信中使用的安全参数、密码套件以及MasterSecret。后续通信使用的所有密钥都是通过MasterSecret生成。

在握手阶段完成后，进入应用阶段。在应用阶段通信双方使用握手阶段协商好的密钥进行安全通信。

Handshake协议：包括协商安全参数和密码套件、服务器身份认证(客户端身份认证可选)、密钥交换;

ChangeCipherSpec 协议：一条消息表明握手协议已经完成;

Alert 协议：对握手协议中一些异常的错误提醒，分为fatal和warning两个级别，fatal类型的错误会直接中断SSL链接，而warning级别的错误SSL链接仍可继续，只是会给出错误警告;

Record 协议：包括对消息的分段、压缩、消息认证和完整性保护、加密等。

图2、图3都是表示的协议流程，大同小异。可以对比着看加深理解。

每一个SSL/TLS链接都是从握手开始的，握手过程包含一个消息序列，用以协商安全参数、密码套件，进行身份认证以及密钥交换。握手过程中的消息必须严格按照预先定义的顺序发生，否则就会带来潜在的安全威胁。今年顶级安全会议CCS 有文章提出了建立综合状态机来检查SSL链接中消息序列……

2.1 握手过程中的消息序列

ClientHello：ClientHello通常是握手过程中的第一条消息，用于告知服务器客户端所支持的密码套件种类、最高SSL/TLS协议版本以及压缩算法。

ClientHello中还包含一个随机数，这个随机数由4个字节的当前GMT UNIX时间以及28个随机选择的字节组成，共32字节。该随机数会在密钥生成过程中被使用。

另外，ClientHello中还可能包含客户端支持的TLS扩展。(TLS扩展可以被用来丰富TLS协议的功能或者增强协议的安全性)

ServerHello：服务器接受到ClientHello后，会返回ServerHello。服务器从客户端在ClientHello中提供的密码套件、SSL/TLS版本、压缩算法列表里选择它所支持的项，并把它的选择包含在ServerHello中告知客户端。接下来SSL协议的建立就基于服务器选择的密码套件类型、SSL/TLS协议版本以及压缩算法。

ServerHello中同样会包含一个随机数，同样4+28 字节类型，由服务器生成。

Certificate：客户端和服务器都可以发送证书消息来证明自己的身份，但是通常客户端证书不被使用。 服务器一般在ServerHello后会接一条Certificate消息，Certificate消息中会包含一条证书链，从服务器证书开始，到Certificate authority(CA)或者最新的自签名证书结束。下图形象地描述了证书链：

SSL中使用的证书通常是X.509类型证书，X.509证书的内容如下表所示：

在用的X.509证书包含Version 1和Version 3两种版本，其中v1版本的证书存在安全隐患，同时不支持TLS扩展，被逐渐弃用。现在大多数在用的SSL证书都是V3版本。

同时证书会附带与协商好的密钥交换算法对应的密钥。密钥交换算法以及它们所要求的密钥类型如下表所示。

ServerKeyExchange：该消息仅当以下密钥交换算法被使用时由服务器发出：

RSA_EXPORT(仅当服务器的公钥大于512bit时)、DHE_DSS、DHE_DSS_EXPORT、DHE_RSA、DHE_RSA_EXPORT、DH_anon 使用其它密钥交换算法时，服务器不能发送此消息。

ServerkeyExchange消息会携带这些密钥交换算法所需要的额外参数，以在后续步骤中协商PreMasterSecret。这些参数需要被签过名。

CertificateRequest：这个消息通常在要求认证客户端身份时才会有。消息中包含了证书类型以及可接受的CA列表。

ServerHelloDone：服务器发送这条消息表明服务器部分的密钥交换信息已经发送完了，等待客户端的消息以继续接下来的步骤。这条消息只用作提醒，不包含数据域。

ClientKeyExchange：这条消息包含的数据与所选用的密钥交换算法有关。

如果选择的密钥交换算法是RSA，那么消息包含的参数为用服务器RSA公钥(包含在之前证书中的或者是ServerKeyExchange中的)加密过的PreMasterSecret，它有48个字节，前2个字节表示客户端支持的最高协议版本，后46个字节是随机选择的。

如果选择的密钥交换算法是DH或者DHE，则可能有两种情况：

隐式DH公开值：包含在Certificate消息里;

显示DH公开值：公开值是本消息的一部分。

CertificateVerify：这条消息用来证明客户端拥有之前提交的客户端证书的私钥。

Finished：表明握手阶段结束。这是第一条用协商的算法和密钥保护的消息。

因为是用协商好的密钥加密的消息，它可以用来确认已经协商好的密钥。

同时Finished消息包含一个verify_data域，可以用来校验之前发送和接收的信息。

Verify_data域是一个PRF函数的输出(pseudo-random function)。这个伪随机函数的输入为：(1)两个hash值：一个SHA-1，一个MD5，对之前握手过程中交换的所有消息做哈希;(2)the MasterSecret，由预备主密钥生成;(3)finished_label，如果客户端发送的则是”client finished”，服务器发送的则是”server finished”。关于这个PRF的细节在3.3节中会具体描述。 此外，Finished 消息不能够在ChangeCipherSpec前发送。

2.2 不同密钥交换算法对应的握手过程

不同的密钥交换算法对应的握手过程中的消息序列是不同的，相应的实现方式也不同，本节介绍几个常见密钥交换算法对应的握手过程。

TLS-RSA：在这个场景下，PreMasterSecret是由客户端指定的，并用RSA公钥加密发送给服务器。服务器不影响PReMasterSecret的生成。

TLS-DH：基于DH的密钥交换也被称为静态Diffie-Hellman。在这种场景下，可能是双方各自提交一个证书包含DH公开值，或者服务器端提交证书包含DH公开值，客户端在每次会话中选择一个值。协商好的DH值被用作PreMasterSecret。显然证书中的参数是固定的，那么每次链接的PreMasterSecret也是相同的。

TLS-DH不能提供前向安全性。

TLS-DHE：基于DHE的TLS握手中会有ServerKeyExchange消息。握手过程中交换参数的认证通过数字签名来实现，支持的签名算法包括RSA和DSS。DH参数会有它的数字签名一起被包含在ServerKeyExchange中被发送出去。客户端在ClientKeyExchange中返回它的公开DH参数，但没有签名保护。同样协商出来的DH密钥被用作PreMasterSecret。

2.3 密钥生成

Pseudo-random Function(PRF)：伪随机函数是SSL协议中的一个重要组成部分，它被用来秘密扩展以及生成密钥。在3.1节讲解Finished消息时已经简单提及PRF，在这里我们详细讨论PRF的工作原理。SSL/TLS协议中的PRF如下图所示：

这个PRF基于两个hash函数：MD5和SHA-1，它有3个输入，一个Secret(比如PreMasterSecret)，一个标志符(比如”client finished”, “server finished”)，还有一个种子值(比如客户端随机数+服务器端随机数)。

Secret在使用时被分为长度相同的两半：S1和S2，分别作为P_MD5和P_SHA-1的输入。

PRF的输出按如下方式处理得到：

P_MD5和P_SHA-1都是扩展函数，用来扩展秘密值以用于密钥生成，它们的计算方式如下：

其中A(0) = seed, A(i) = HMAC hash( secret, A( i −1) )

这个秘密扩展会一直进行直到得到足够多的扩展数据。 Key Derivation：主密钥(MasterSecret)是利用上述PRF从预备主密钥(PreMasterSecret)生成的。每个MasterSecret为48字节，生成方式如下：

得到MasterSecret后，它会被进一步处理最后生成4个不同的密钥和2个初始向量(IV)。处理过程如下：

处理过程一直持续到足够多的输出被生成，然后把输出分为4个key和2个IV：

下图完整阐述了SSL/TLS协议中的密钥生成过程。

本节介绍SSL/TLS协议的版本变迁，不同版本的区别以及安全特性等。

SSL 1.0由于从来没有被公开过，并且存在严重安全漏洞，我们就不讨论了。

SSL 2.0：SSL 2.0于1995年4月被发布。SSL 2.0中主要存在的问题如下：

MAC不能覆盖填充长度域，攻击者可能利用这点破坏消息完整性;

缺乏握手认证，攻击者可以篡改密码套件列表，诱骗通信双方使用较弱的密码套件;

使用较弱的或有问题的密码算法(如MD5，RC4等)，或者使用不安全的分组模式(如CBC模式);

对于不同的密码学基元使用相同的密钥，违背基本安全常识。

由于以上安全问题，RFC 6176已经明确提出避免使用SSL 2.0，但是现实生活中还有少量客户端和服务器支持SSL 2.0.

SSL 3.0：SSL 3.0引入了一些新的特性和机制解决了很多之前版本存在的漏洞。此外，SSL 3.0中引入了ChangeCipherSpec子协议。SSL 3.0向后兼容SSL 2.0，相对于SSL 2.0，它的主要改变包括以下几点：

支持更多的密码套件(支持更多的密码算法如DSS，SHA-1)

在握手阶段支持密钥协商(DH和FORTEZZA)

支持密码学参数的重协商

增加了消息压缩选项

MAC能够覆盖填充长度域了，同时MAC可以使用MD5或者SHA-1

不同的密码学基元使用不同的key

Alert子协议能对任何错误给出两种提示：Warning和Fatal

中止链接的时候会用一个close_notify警告通知通信双方

支持证书链，而非单个证书

通过Finished消息认证所有发送和接收的消息

加密了的PreMasterSecret包含当前使用的协议版本，防止协议回滚

TLS 1.0：TLS 1.0和SSL 3.0差别非常小。实际上，TLS 1.0是SSL 3.1，在IETF接手后改名为TLS。TLS 1.0版本是目前使用最广泛的SSL/TLS协议版本。

TLS 1.0不再支持使用FORTEZZA的密码套件。

TLS 1.0中MAC被替换成HMAC。

之前提到ChangeCipherSpec消息必须在Finished消息前发送，在TLS 1.0中，如果消息序列不符合这个要求，会产生FATAL警告并终止链接。

TLS 1.1：这个版本相比之前改动也很小。最重要的改动是预防了针对CBC分组模式的一些攻击。现在的填充错误变的和非法MAC错误不可区分了，防止攻击者利用可区分错误响应建立解密预言机对密文进行攻击。

在每次加密过程中，使用CBC分组模式时，都需要显示给出IV，而不用再密钥生成时使用PRF生成IV。

此外，TLS 1.1禁止为适应之前出口限制而使用弱化的密码套件。

TLS 1.2：这是最新的版本，部署的还比较少。这个版本禁用了PRF中的MD5和SHA-1，而用一个可配置的hash函数取代了它们，这样的修改简化了计算过程。修改后的PRF风格如下：

此外，TLS 1.2的一个重要变化是支持认证加密模式(支持GCM等)。但是由于一些AEAD(Authenticated Encryption with Associated Data)密码算法要求IV为隐式的，所以IV又恢复到由MasterSecret生成，即TLS 1.0以前的风格。

TLS 1.2支持使用GCM、CCM的新密码套件。

同时SSL 2.0被宣布放弃，不再向后兼容SSL 2.0.

本节简单介绍一下流行的SSL/TLS实现库，SSL协议非常复杂，由开发者自己实现常常会出错，开发者在具体实现SSL协议时通常会依赖于这些密码学库。

4.1 常见的SSL/TLS 实现

OpenSSL：这是非常流行的开源SSL/TLS实现。

OpenSSLim完全用C语言实现，支持SSL 2.0/3.0，TLS 1.0/1.1/1.2以及DTLS 1.0。

OpenSSL 近年来出现了很多的安全漏洞，比如2014年曝出的着名的Heartbleed漏洞等。

JSSE：这是使用Java实现的，支持SSL 3.0，TLS 1.0/1.1/1.2.

Bouncy Castle：它不仅仅支持SSL/TLS，它是一个完整的密码学库，支持各种密码学算法和协议。不过它仅仅支持TLS 1.0版本。

Android平台主要使用这个密码学库。

GnuTLS：这是另一个用C语言实现的库，支持SSL 3.0，TLS 1.0/1.1/1.2以及DTLS 1.0。主要在Unix世界被使用。同时以各种安全漏洞多而闻名。

NSS：这是最初由网景公司(Netscape)开发的库，支持SSL 2.0/3.0，TLS 1.0/1.1，现在主要被浏览器和客户端软件使用，比如Firefox使用的就是NSS库，Chrome使用的是一个NSS库的修正版。

下表是一些常见软件以及它们所使用的SSL/TLS实现库的情况：

其它还有一些常用的SSL实现库，如cryptlib、CyaSSL、MatrixSSL、PolarSSL等，由于市场占有率不高，我们这里就不多做介绍了。

4.2 流行SSL/TLS实现库的安全研究

最近几年曝出的高风险SSL安全漏洞大多跟SSL实现库有关，比如2014年4月曝出的“心脏滴血”漏洞，存在于OpenSSL 1.0.1-1.0.1f版本中，影响全球近17%的Web服务器;同样是2014年曝出的苹果公司iOS 7.0.6版本系统中存在的“gotofail”漏洞，因为程序员的疏忽导致SSL证书校验中的签名校验失效;包括今年曝出的SSL Freak攻击也是由于SSL实现库的安全漏洞导致的攻击，我们研究小组的同学对这个攻击有详细的分析，参见《SSL Freak来袭：如何实施一个具体的SSL Freak攻击》。同时我们还开发了一个基于python的中间人代理攻击框架“风声”对某国内知名电商的服务器进行具体的攻击，并上报了漏洞。

考虑到大量SSL/TLS实现库中存在安全问题，同时这些主流的SSL/TLS实现库对开发者而言使用难度较高，比如有些SSL/TLS实现库要求开发者自己进行随机数生成或密钥管理，让缺乏系统信息安全知识培训的开发者去使用这样高度复杂的密码学库容易产生很多安全问题。我们在这里推荐一些高级密码学库：Google keycazer、NaCl、Cryptlib、GPGME。这些密码学库存在的安全问题较少，同时封装了一些底层的密码学操作，降低了开发者的使用难度。

以上就是本次要介绍的SSL /TLS协议基本知识，后续的文章我们会对一些典型SSL/TLS攻击进行具体介绍。

参考：
1、 http://netsecurity.51cto.com/art/201505/476337.htm
2、 http://www.cnblogs.com/NathanYang/p/9183300.html
3、 https://www.cnblogs.com/bhlsheji/p/4586597.html

㈧ 网页设置tls是什么意思

网页设置tls是加密的安全协议。TLS 保证安全，这里的，安全，分两部分，一是传输内容加密，二是服务端的身份认证。

此为服务端单向认证，还有客户端或服务端双向认证，流程类似，只不过客户端也有自己的证书，并发送给服务器进行验证。

内容结构

安全传输层协议TLS用于在两个通信应用程序之间提供保密性和数据完整性，TLS协议包括两个协议组TLS记录协议和TLS握手协议每组具有很多不同格式的信息。

TLS记录协议是一种分层协议，每一层中的信息可能包含长度，描述和内容等字段，记录协议支持信息传输，将数据分段到可处理块，压缩数据，应用MAC，加密以及传输结果等，对接收到的数据进行解密，校验，解压缩，重组等，然后将它们传送到高层客户机。

TLS连接状态指的是TLS记录协议的操作环境，它规定了压缩算法，加密算法和MAC算法。

㈨ ssl协议包含几个子协议

SSL(Secure Sockets Layer 安全套接层)协议目前已成为互联网上用来鉴别网站和网页浏览者的身份，以及在浏览器使用者及网页服务器之间进行加密通讯的全球化标准协议。简单理解是网络连接的一种安全协议，可以保护用户信息安全。

目前SSL协议有SSL记录协议和SSL握手协议两种：

• SSL记录协议建立在可靠的传输协议之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。

• SSL握手协议建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

SSL协议的主要作用有哪些：

1、认证用户和服务器，确保数据发送到正确的客户机和服务器;

2、加密数据以防止数据中途被窃取;

3、维护数据的完整性，确保数据在传输过程中不被改变。

㈩ 什么是TLS

资料来自网络

TLS
TLS：安全传输层协议
（TLS：Transport Layer Security Protocol）
安全传输层协议（TLS）用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。 TLS 记录协议提供的连接安全性具有两个基本特性：

私有――对称加密用以数据加密（DES 、RC4 等）。对称加密所产生的密钥对每个连接都是唯一的，且此密钥基于另一个协议（如握手协议）协商。记录协议也可以不加密使用。
可靠――信息传输包括使用密钥的 MAC 进行信息完整性检查。安全哈希功能（ SHA、MD5 等）用于 MAC 计算。记录协议在没有 MAC 的情况下也能操作，但一般只能用于这种模式，即有另一个协议正在使用记录协议传输协商安全参数。
TLS 记录协议用于封装各种高层协议。作为这种封装协议之一的握手协议允许服务器与客户机在应用程序协议传输和接收其第一个数据字节前彼此之间相互认证，协商加密算法和加密密钥。 TLS 握手协议提供的连接安全具有三个基本属性：

可以使用非对称的，或公共密钥的密码术来认证对等方的身份。该认证是可选的，但至少需要一个结点方。
共享加密密钥的协商是安全的。对偷窃者来说协商加密是难以获得的。此外经过认证过的连接不能获得加密，即使是进入连接中间的攻击者也不能。
协商是可靠的。没有经过通信方成员的检测，任何攻击者都不能修改通信协商。
TLS 的最大优势就在于：TLS 是独立于应用协议。高层协议可以透明地分布在 TLS 协议上面。然而， TLS 标准并没有规定应用程序如何在 TLS 上增加安全性；它把如何启动 TLS 握手协议以及如何解释交换的认证证书的决定权留给协议的设计者和实施者来判断。

协议结构

TLS 协议包括两个协议组―― TLS 记录协议和 TLS 握手协议――每组具有很多不同格式的信息。在此文件中我们只列出协议摘要并不作具体解析。具体内容可参照相关文档。

TLS 记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用 MAC 、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等，然后将它们传送到高层客户机。

TLS 连接状态指的是 TLS 记录协议的操作环境。它规定了压缩算法、加密算法和 MAC 算法。

TLS 记录层从高层接收任意大小无空块的连续数据。密钥计算：记录协议通过算法从握手协议提供的安全参数中产生密钥、 IV 和 MAC 密钥。 TLS 握手协议由三个子协议组构成，允许对等双方在记录层的安全参数上达成一致、自我认证、例示协商安全参数、互相报告出错条件。

改变密码规格协议
警惕协议
握手协议