Security

接着上一篇 TLS Perfect Forward Secrecy 之 RSA 缺陷 继续来看看 DH/ECDHE 如何解决这个问题。 前面提到 RSA 做密钥协商过程中，最关键的缺陷是客户端用公钥加密了 PreMaster Key，服务器用私钥解密 PreMaster Key。理想中更好的方法是 公钥/私钥只用来对证书签名，不参与到密钥协商的过程中来，换句话说，希望通信的双方能独立计算出对称加密的密钥。于是密码学家找到了尘封已久的，几乎与 RSA 同时出现的 DH 算法。 其实我一直有一个疑问：既然问题出在传送 PreMaster Key，那么客户端不发送 PreMaster Key 不就行了？握手的过程中已经有了 2 个随机数了，难道一定要 3 个随机数才能生成 master key 吗？ 首先来看一下 DH 算法的数学基础。 +-------------------------------------------------------------------+ | Global Pulic Elements | | | | p prime number | | a prime number, a < p | +-------------------------------------------------------------------+ +-------------------------------------------------------------------+ | User A Key Generation | | | | Select private Xa Xa < p | | Calculate public Ya Ya = a^Xa mod p | +-------------------------------------------------------------------+ +-------------------------------------------------------------------+ | User B Key Generation | | | | Select private Xb Xb < p | | Calculate public Yb Yb = a^Xb mod p | +-------------------------------------------------------------------+ +-------------------------------------------------------------------+ | Calculation of Secret Key by User A | | | | Secret Key K K = Yb^Xa mod p | +-------------------------------------------------------------------+ +-------------------------------------------------------------------+ | Calculation of Secret Key by User B | | | | Secret Key K K = Ya^Xb mod p | +-------------------------------------------------------------------+ 上面一共出现了 a, p, Xa, Ya, Xb, Yb, K 共 7 个数，其中： ...

HTTPS 这样的加密传输，最关键的是要解决两个问题， 一个是通信双方如何协商出一个对称加密的密钥（密钥交换） 二是自己如何确认对方的服务器就是我想访问的，即认证。 第一个问题可以由非对称加密解决，第二个问题是证书的合法性校验，“签发数字签名”，指的是用hash函数，对证书中的发行者，有效期，证书名等信息计算得到一个摘要（digest），然后用私钥进行加密，得到签名A。而对应的“校验数字签名”，则是先用相同的hash函数得到digest, 再利用相应的公钥解密A，然后对比自己hash出的和解密出的A是否相同，以此来认证对方是不是我们想要通信的人。 写到这里，正好最近有一个有趣的新闻：SHA1签名算法被破解，也就是说，安全研究人员根据理论上的SHA1破解算法，运用大量的计算资源，终于生成了两个不同的 PDF文件，但是它们的SHA1 值是一样的，所以以后我们应该使用更高级的签名算法来避免可能的安全漏洞。有兴趣的可以移步到上面的链接查看。 |算法 | 密钥交换 | 认证 | |--------|---------|---------| |基于 RSA | RSA | RSA | |基于 DH | DH | RSA/DSA| 相比传统的 RSA 握手，ECDHE 能支持 forward secrecy(DH 算法本身没有forward secrecy，要 ECDHE 才行)。DH 算法让 client 和 server 分别独立的计算出同步加密的密钥，注意：是独立计算出，而不是通过一方传递给另一方。 加密套件，类似于 “ECDHE-ECDSA-AES256-SHA384” 这样的一串，主要包含这些信息： 密钥协商的算法，要么 RSA，要么 DH 认证方法，比如 SHA 同步加密的方法，即 session key 所属的类型 hash 函数，保证传输的用户数据的完整性 在探讨 Perfect Forward Secrecy 之前，先来回顾一下旧的 TLS 握手过程会有什么缺陷。 没有 PFS 的 RSA 握手过程 第一步，ClientHello 这一步，客户端向服务器提供以下信息： ...

本文是《Traffic Analysis of an SSL/TLS Session》的笔记，原文见此处。 在 TLS 协议格式 中详细分析了协议数据的各个字段， 现在就来实战 ——用 Wireshark 抓包并观察数据。 第一发（Client -> Server） Full contents of the packet 0000 02 00 00 00 45 00 00 98 13 ed 40 00 40 06 00 00 ....E.....@.@... 0010 7f 00 00 01 7f 00 00 01 ec 26 01 bb 43 7c ee 74 .........&..C|.t 0020 60 b5 50 0a 80 18 31 d7 fe 8c 00 00 01 01 08 0a `.P...1......... 0030 21 62 1e 1e 21 62 1e 1e 16 03 01 00 5f 01 00 00 !b..!b......_... 0040 5b 03 01 54 9a ab 72 98 65 11 2f da 9e cf c9 db [..T..r.e./..... 0050 6c bd 4b 4c 56 4b 0c a5 68 2b aa 60 1f 38 66 e7 l.KLVK..h+.`.8f. 0060 87 46 b2 00 00 2e 00 39 00 38 00 35 00 16 00 13 .F.....9.8.5.... 0070 00 0a 00 33 00 32 00 2f 00 9a 00 99 00 96 00 05 ...3.2./........ 0080 00 04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 ................ 0090 00 03 00 ff 01 00 00 04 00 23 00 00 .........#.. ------------ Family: IP 0000 02 00 00 00 .... IP protocol <--- IP协议首部 20 个字节，无“选项”字段。 0000 45 00 00 98 13 ed 40 00 40 06 00 00 7f 00 00 01 E.....@.@....... 0010 7f 00 00 01 .... TCP protocol <-- TCP 协议首部标准的为 20 个字节，这里一共32个字节，说明有“选项”字段。 0000 ec 26 01 bb 43 7c ee 74 60 b5 50 0a 80 18 31 d7 .&..C|.t`.P...1. 0010 fe 8c 00 00 01 01 08 0a 21 62 1e 1e 21 62 1e 1e ........!b..!b.. ------------ TLSv1 protocol 0000 16 03 01 00 5f 01 00 00 5b 03 01 54 9a ab 72 98 ...._...[..T..r. 0010 65 11 2f da 9e cf c9 db 6c bd 4b 4c 56 4b 0c a5 e./.....l.KLVK.. 0020 68 2b aa 60 1f 38 66 e7 87 46 b2 00 00 2e 00 39 h+.`.8f..F.....9 0030 00 38 00 35 00 16 00 13 00 0a 00 33 00 32 00 2f .8.5.......3.2./ 0040 00 9a 00 99 00 96 00 05 00 04 00 15 00 12 00 09 ................ 0050 00 14 00 11 00 08 00 06 00 03 00 ff 01 00 00 04 ................ 0060 00 23 00 00 .#.. TLSv1 Record protocol 0000 16 03 01 00 5f ...._ 16 Handshake protocol type 03 01 SSL version (TLS 1.0) 00 5f Record length (95 bytes) TLSv1 Handshake protocol 0000 01 00 00 5b 03 01 54 9a ab 72 98 65 11 2f da 9e ...[..T..r.e./.. 0010 cf c9 db 6c bd 4b 4c 56 4b 0c a5 68 2b aa 60 1f ...l.KLVK..h+.`. 0020 38 66 e7 87 46 b2 00 00 2e 00 39 00 38 00 35 00 8f..F.....9.8.5. 0030 16 00 13 00 0a 00 33 00 32 00 2f 00 9a 00 99 00 ......3.2./..... 0040 96 00 05 00 04 00 15 00 12 00 09 00 14 00 11 00 ................ 0050 08 00 06 00 03 00 ff 01 00 00 04 00 23 00 00 ............#.. 01 ClientHello message type 00 00 5b Message length <---- 这里消息长度为3字节，大于记录协议的2字节， 也就是说，一个记录块放不下可以放到下一个？ 03 01 SSL version (TLS 1.0) 54 .. b2 32-bytes random number 00 Session Id length 00 2e Cipher Suites length (46 bytes, 23 suites) 00 39 .. ff 23 2-byte Cipher Suite Id numbers 01 Compression methods length (1 byte) 00 Compression method (null) 00 04 Extensions length (4 bytes) 00 23 SessionTicket TLS extension Id 00 00 Extension data length (0) 第二发（Server -> Client） 这个例子中，服务端发送了三种消息，ServerHello，Certificate，ServerHelloDone。这是一种最简单的方式，服务端没有要求验证客户端证书。 ...

本文内容来自《Traffic Analysis of an SSL/TLS Session》的阅读笔记，原文见此处。 TLS 全称为 Transport Layer Security，它本身也分为了 Lower 和 Higher 两层协议。 Lower Layer Lower Layer 协议在 TCP 协议之上，提供面向连接的可靠传输，在这一层的协议主要是记录协议（TLS Record Protocol）。 记录协议首先把上层协议传来的数据分成小于2^14字节的数据块，如果设置了压缩选项，则第二步为压缩数据，然后在数据块的末尾增加 MAC（Message Authentication Code），第三步将数据块加密，最后增加记录头。该过程如下所示。 each block is packed into a structure that does not preserve client message boundaries, meaning that mulitiple message of the same type maybe coalesced into a single structure -----------+ data --+--------------> 1. Fragment data -----------+ +------------------------+ | | | | +------------------------+ 2. Compress data (generally no compression applied) +------------------------+----+ | |MAC | Add a Message Authentication Code | | | +------------------------+----+ 3. Encrypt data +-----------------------------+ |ciphertext | | | +-----------------------------+ 4. Add header +----+-----------------------------+ TLS Record | |ciphertext | Add a TLS Record header header | | | +----+-----------------------------+ Higher Layer 主要有四种协议。 ...