Author: admin
-
RSA Key Exchange
本篇文章, 我们以 TLS_RSA_WITH_AES_253_CBC_SHA256 为例,来学习一种 TLS Key 交换算法.: RSA key 交换算法. 注意, 这种 key 交换算法已经被证明并不安全,因此请在实践中不要使用它, 这里我们只是以此来学习以下相关算法原理. 握手过程 使用 RSA Key 交换算法的 TLS 握手流程大体如下： Client Server ClientHello{CipherSuites: TLS_RSA_…} –> <– ServerHello{CipherSuite: TLS_RSA_…} <– Certificate(RSA) <– ServerHelloDone ClientKeyExchange** –> ChangeCipherSpec –> EncryptedHandshakeMessage –> <– ChangeCipherSpec <– EncryptedHandshakeMessag 算法解析 RSA Key 交换算法流程： 1. TLS 服务器端 当 TLS 握手过程中选择了 RSA…
-
TLS Session Resumption: 基于 Session ID
在 TLS1.3 之前的 TLS 版本中, 可以通过 Session ID 字段来完成 Session Resumption. Session ID: This is the identity of the session corresponding to this connection 那么具体实现如何呢，我们一起来看看。 流程 初始连接 （完整的握手后建立） 首先，在 ClientHello 和 ServerHello 都附带 Session ID 字段。 当客户端一次尝试与服务器通信时，它通常没有任何可以恢复的 tls session， 因此，需要进行一次完整的 tls 握手流程。 这个流程中以下点需要注意： 通常 ClientHello 中的 Session ID 设置为空。 ServerHello 中的 Session ID 不为空。 在这次握手成功之后，我们便有了一个可以在其他…
-
TLS13 Session resumption
TLS13 的 Session resumption 和之前版本不同 什么是 Session resumption： 在之前的 TLS 连接之上，基于已经交换过的信息， 快速的建立另外一个TLS 连接的机制。 为什么需要 Session resumption： 加速TLS握手, 更快的准备好安全的数据通道. 常见的使用场景： FTP 协议。 在 FTP 协议中，当 control channel 使用 TLS 协议进行通信，通常会要求 Data channel 也进行 TLS 加密通信，并且强制要求 Data channel 使用 Session resumption 机制建立 TLS 连接。 HTTP 协议中，当我们需要和同一个服务器建立多个 TLS 连接时，我们可以选择在成功的建立一条TLS连接之后，后续连接使用 Session resumption 来加速 TLS 连接建立的速度。 其他场景。 概述 正如前面所说, Session…
-
TLS 版本协商
当前所有的 TLS/SSL 版本： SSL 2.0 (废弃) SSL 3.0 (废弃) TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 无论是客户端还是服务器端，同时支持多个协议版本非常常见，那么不可避免的需要进行版本协商。 不过，这并不难，因为TLS协议已经制定了协商的方法。 由于当前 SSL2.0 已经没人使用，并且它的数据包格式和其他版本也不兼容，版本协商不可用，这里不在讨论 SSL2.0。 SSL 握手阶段需要通过交换 ClientHello 和 ServerHello 来协商当前即将建立的 TLS/SSL 版本。 TLS 1.3 协议下的协商 TLS1.3 扩展：supported_versions 这个扩展用来包含一个或多个 TLS 版本信息， 它可以在 ClientHello 和 ServerHello 中使用。 在 ClientHello 中表示客户端支持的 TLS 版本. 在 Server Hello 中，表示服务器端想使用的 TLS 版本.…
-
PRF
PRF = Pseudorandom function 它的作用是: 扩展密钥. 也就是说从一个密钥,生成另外一个密钥. 它的输入是: secret, seed, label. 它的输出是: 任意长度的字节数组 它的定义: PRF(secret, label, seed) = P_<hash>(secret, label+seed) P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(3) + seed) + … A() = A(0) = seed A(i) = HMAC_hash(secret, A(i-1)) 上述表达式中 + 号代表字符数组拼接. P_hash 定义中， HMAC_hash 可以重复无数次，直到生成的结果长度达到期望。…
-
TLS 安全重协商扩展
1. 重协商(Renegotiation) 就是在现有的 TLS 连接之上，重新进行 TLS 握手过程，以产生全新的 TLS 加密参数的过程。 服务器和客户都可以发起这个重协商过程(在任何时刻)。 客户端： 可以在任意时刻发送新的 ClientHello 消息来出发重协商过程。 服务器：当服务器端想发起重协商的过程，它需要给客户端发送一个 HelloRequest的请求，客户端在收到这个消息后可以根据情况决定是否开始重协商。 重协商的握手和初始的 TLS 握手流程相同，不同的是在重协商时，服务器和客户端已经有了可以用于加密通信数据的加密参数，因此，此时发送的握手TLS数据包都是加密的。 2. 为什么需要安全的重协商扩展？ TLS 协议中允许通信双方（服务器或者客户端）发起重协商来建立一套新的加密参数。 但是，由于缺乏必要的信息来将重协商前后的上下文关联起来，这里就存在中间人攻击的安全隐患。 中间人攻击示意图： Client Attacker Server 1. ——- TCP CONNECT ———–> 2. ———– TCP CONN && TLS CONN —-> 3. ———– Send Attack App Data —-> 4. ———– TLS Handshake —–> 5. ———–…
-
Extended Master Secret Extension
1. TLS 协议中存在的一个安全问题 在 TLS (version 1.2) 的基本协议设计中， master secret 的计算方式依赖于 pre master secret, client.random, server.random, 而与握手过程中其他参数无关(比如，服务器证书)。 TLS 中master secret 的计算方法： master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47]; 因此，就存在一种可能的被攻击的漏洞。 如何实现攻击： 假定: 客户端是 C，攻击者是 A， 服务器是 S。 这里 C 被 A 所欺骗，而错误的建立了 TCP 连接到 A，把 A 当作了 S。 握手流程中使用 RSA Key 交换算法。 那么攻击过程大体如下： C…
-
Cipher Suites
简介 Cipher Suite 在 TLS 中用来指定整个通信过程中所使用的加密相关的参数， 包括如何协商加密得到加密所用的密钥，以及签名使用的算法和哈希算法。 主要涉及到下面几个方面： Key exchange (Key 交换算法) Bulk encryption （批量加密） Message authentication (消息认证) Authentication Key 交换算法 用户交换一个叫做 Shared key 的私钥。 这里主要使用非对称加密算法(asymmetric key algorithm). 这个key 将作为种子，用来生成多个密钥，生成的密钥将用于保护不同的数据。 因为非堆成加密的特性，它只被用来加密少量的数据。 大量数据的情况下，性能会很低，因此不用它来做大数据量的加密操作。 Bulk encryption 用来加密客户端和服务器的通信数据。 不同与非对称加密算法， 这些算法可以用来进行大量数据的加密，而且性能比非对称加密算法强很多。 Message authentication 算法用来生成 消息的哈希，签名等，用来确保消息的完整性。 TLS 中如何协商 Cipher Suite？ TLS 协议中通过 ClientHello 和 SeverHello 两个包来协商当前链接将要使用的 CipherSuite. 客户端将自己支持的所有 Cipher Suite…