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 `....

本文内容来自《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....