0x1 SSL/TLS

注意看，这个男人叫小帅，正在某网站观看好莱坞动作大片，电脑突然弹出一个神秘链接

小帅迫不及待的打开链接，浏览器给出如下提示

那么这个时候，换做是你，你会选择关掉网页，还是无视风险继续前往呢

思考两个问题，为什么会出现这个页面？浏览器的左上角又为何变红提示不安全呢？这背后的原因是什么，是人性的扭曲，还是...........

这就需要了解一下HTTPS了

在平常使用HTTP的时候，数据都是以明文的形式传输，将一些敏感信息如账号密码等暴露在这样的网络下显示是不安全的，且某运营商和一些流氓在数据包中插入一些垃圾信息和广告，十分不讲武德。

于是一些聪明的大哥们觉得是时候要对HTTP做一下升级了，于是便产生了HTTPS，HTTPS是基于HTTP协议的安全版本，它通过使用SSL/TLS协议来加密和保护数据在网络上安全的传输。

SSL/TLS协议（Secure Sockets Layer/Transport Layer Security）是一种用于加密和保护数据在网络上传输的安全协议。SSL最初由Netscape公司开发，后来被标准化并更名为TLS,它通过使用公钥和私钥来实现加密解密，并使用数字证书来验证身份和建立信任。当客户端与服务器建立连接时，它们会协商并选择一个协议版本、加密算法和密钥长度。然后，服务器会发送自己的数字证书给客户端，客户端会验证证书的有效性，然后使用服务器的公钥来加密生成一个对称密钥，该密钥将用于在之后的通信中加密和解密数据。之后，所有的数据传输都会被加密并使用该对称密钥进行解密，以确保数据在传输过程中的机密性和完整性。

0x2 原理

算法

1. 对称加密算法

对称加密算法是一种使用相同密钥进行加密和解密的加密算法。常见的对称加密算法有DES、3DES、AES等。

对称加密算法中，加密密钥和解密密钥是相同的，只要在数据传输前双方协商好密钥并各自保存密钥，发送方可以使用该密钥对数据进行加密，接收方则使用同样的密钥对数据进行解密。由于对称加密算法计算速度快，适合对大量数据进行加密和解密操作，但加解密都必须使用同一个密钥，密钥在发送过程中可能被黑客截获。

要不咱俩找个咖啡厅，线下交换一下密钥，后续都用这个密钥进行加密解密，这样也太麻烦了，我懒得去，于是又推出了非对称加密算法。

2. 非对称加密算法

   非对称加密算法使用一对密钥（公钥和私钥）来进行加密和解密，其中公钥可以公开，任何人都可以使用它来加密数据，但只有配对的私钥才能解密该数据。这种算法的安全性依赖于数学原理，例如质因数分解或离散对数问题。著名的非对称加密算法包括RSA、DSA和ECC等。

然而随着算力的提升和量子计算机的发展，这种算法面临着威胁与挑战。但目前来说，即使使用地表最强的算力破解4096位的rsa密钥也需要很长很长时间，所以到目前为止，这种算法仍可以看做是安全的。

3. 消息认证码（MAC）算法

   用于确保数据在传输过程中的完整性和身份验证。常见的MAC算法包括：md5(已被淘汰)、sha256等

工作方式和存在缺陷

那么https到底使用了对称加密算法还是非对称加密算法呢？

小孩子才做选择，俺全都要

让我们来简单的看一下过程

如图，客户端生成并拥有随机数C，服务器拥有公钥A和私钥B

1. 客户端请求服务器

2. 服务器将 公钥A发送给客户端，私钥B自己留存且不能泄露

3. 客户端收到 公钥A后，用公钥A加密 随机数C并发送给服务器 (这里客户端并不能确定消息是服务器发送的)

4. 服务器使用 私钥B解密数据得到 随机数C(由于这段加密数据是客户端使用服务器的公钥加密的，所以只有服务器的私钥可以解密这段数据)

5. 接下来双方的手里都有这个 随机数C,后面都使用对称加密算法对数据进行加密传输，而这个随机数C就是对称加密的密钥。

从就可以看出为什么要同时使用多种算法来确保HTTPS的安全性

1. 单独使用对称加密算法可以吗？当然不行

   

   在加密之前密钥明文传送，黑客在中间链路截获，即使你后面的数据使用加密传输，黑客凭借截获的密钥可对数据进行任意解密。

   什么？你说你不在网络上传送密钥就是了，你坐飞机过去，把密钥给他，那完全没问题，你要看看这是在什么场景下，全世界那么多网站你怕是跑不过来。

2. 那单独使用非对称加密算法可以吗？也不行

   

2.1 服务器向客户端发送公钥，这个公钥可能被黑客截获

2.2 客户端用服务器给的公钥加密数据，发送给服务器，此时黑客拿到数据是无法进行解密的，因为黑客手上没有服务器的私钥。

2.3 当服务器使用私钥加密数据，发送给客户端时，问题出现了，由于在第一步中黑客就已经截获了服务器的公钥，所以黑客可以使用这个公钥来解密服务器发送的数据。

由此可见，这种情况下加密是单向安全的，客户端向服务器发送加密数据时，黑客没有私钥，无法解密数据，此时数据是安全的。当服务器使用私钥加密数据向客户端发送数据时，黑客和客户端手里都有公钥，黑客完全可以对数据进行解密，此刻是存在风险的。

所以非对称加密算法只是为了交换秘钥，当秘钥交换完成后，由对称加密算法来对数据进行加密传输。

然而，使用这两种加密方式的解决方案是否就无懈可击了吗，聪明的黑客还有办法

1.服务器向客户端发送公钥，黑客截获公钥，并自己生成一对公钥和私钥，将自己生成的公钥发送给客户端

2.客户端收到公钥并不能判断这个公钥是不是服务器的，用这个公钥加密后续用来做对称加密算法的随机数，并将其发送给服务器

3.黑客劫持到这个客户端发来的加密数据，由于是用自己公钥加密的数据，可以用自己的私钥解密得到了这个用来做对称加密的随机数。

4.黑客用服务器的公钥加密这个刚解开的随机数，发送给服务器

此时黑客已经获取到了后续用来做对称加密的秘钥，后续的所有加密数据在黑客眼里都是明文。

问题就出在客户端并不能确定这个公钥是否真的是对方的，这就需要引入证书和数字签名了

0x3 CA机构

TLS证书

既然无法确认这个证书到底是谁的，那就引入一个裁判，这个裁判就是ca机构

CA机构是指数字证书认证机构(Certificate Authority)，也被称为证书颁发机构。它是一种负责签发和管理公钥证书的可信第三方机构，用于证明数字证书中公钥持有者的身份和公钥的合法性。CA机构的主要职责包括验证申请者的身份、审核公钥证书请求、颁发数字证书、管理证书吊销列表等。常见的CA机构有Symantec、Comodo、Let's Encrypt等。

网站管理员将自己的公钥、组织名、域名等一系列数据集合提交给CA机构，CA机构核对信息后会返回一个证书，证书包含原始明文信息和数字签名。

一般情况下证书包含以下信息

1. 主体信息（Subject）：主体是证书所代表的实体（通常是服务器），其信息包括：

   • 通用名称（CN，Common Name）：通常是服务器的完全限定域名（FQDN）。

   • 组织名称（O，Organization）：申请证书的组织或公司名称。

   • 组织单位（OU，Organizational Unit）：组织内负责管理证书的部门或单位名称。

   • 地理位置信息：包括国家（C，Country）、省/州（ST，State/Province）和城市（L，Locality）。

2. 颁发者信息（Issuer）：颁发者是签发证书的证书颁发机构（CA）。其信息与主体类似，包括颁发者的名称、组织和地理位置信息。

3. 有效期（Validity）：证书的有效期限，包括开始日期（Not Before）和结束日期（Not After）。证书在此期间有效，过期后需要重新申请或续期。

4. 公钥（Public Key）：证书持有者（通常是服务器）的公钥，用于在SSL/TLS握手过程中建立加密通信。

5. 序列号（Serial Number）：证书的唯一序列号，由颁发者分配。

6. 签名算法（Signature Algorithm）：用于对证书进行数字签名的算法，如RSA、ECDSA等。

7. 扩展信息（Extensions）：证书扩展提供了额外的可选信息，例如：

   • 主体备用名称（Subject Alternative Names，SANs）：除了通用名称（CN）之外，证书还可以包含其他有效的域名或IP地址。

   • 密钥使用（Key Usage）：描述证书公钥的用途，如数字签名、密钥加密等。

   • 扩展密钥使用（Extended Key Usage，EKU）：更详细地描述证书的用途，如服务器身份验证、客户端身份验证等。

   • 基本约束（Basic Constraints）：指定证书是否为CA证书，以及CA证书的最大路径长度。

8. 数字签名（Signature）：证书颁发机构（CA）对证书内容的数字签名，用于确认证书的真实性和完整性。

数字签名的生成

这个数字签名如何生成的？

1. 计算证书的哈希值：首先，CA会使用某种哈希算法（例如SHA-256）计算证书内容的哈希值。哈希算法可以将证书内容压缩成一个固定长度的哈希值，对证书内容的任何更改都会导致哈希值发生显著变化。

2. 加密哈希值：CA机构也有一对公钥和私钥，CA使用其私钥对计算出的哈希值进行加密。加密后的哈希值即为数字签名。

3. 将数字签名附加到证书：最后，CA将生成的数字签名附加到证书中，并将签名后的证书发给申请者。

在客户端（例如浏览器）验证证书时，会执行以下步骤：

1. 验证CA的公钥：客户端首先验证CA的公钥是否受信任。大多数操作系统和浏览器都内置了一组受信任的CA公钥。

2. 解密数字签名：客户端使用CA的公钥解密证书中的数字签名，以获得原始的哈希值。

3. 计算证书的哈希值：客户端对证书内容（不包括数字签名部分）使用相同的哈希算法计算哈希值。

4. 比较哈希值：客户端比较从数字签名中解密得到的哈希值和自己计算的哈希值。如果两个哈希值相同，则证书被视为有效且未被篡改。如果哈希值不同，则证书被认为是伪造的或被篡改，客户端会拒绝建立连接。

证书的验证

那么客户端又是如何效验证书的呢？

1. 检查证书颁发者：客户端会验证证书颁发者（CA）是否受信任。操作系统和浏览器通常内置了一组受信任的CA列表。如果证书颁发者不在受信任列表中，客户端可能会发出警告或拒绝建立连接。

2. 验证证书有效期：客户端会检查证书的有效期（Not Before和Not After字段），以确保证书在当前时间内有效。如果证书已过期，客户端将拒绝建立连接。

3. 验证证书域名：客户端会检查证书的主体信息（如通用名称（CN）或主体备用名称（SANs）字段），确保证书中的域名与请求的域名匹配。如果域名不匹配，客户端将拒绝建立连接。

4. 验证证书链：如果服务器提供的证书是由中间CA签发的，客户端需要验证整个证书链，直到找到受信任的根CA。这意味着客户端需要检查每个中间证书的签名、颁发者和有效期等。

5. 验证数字签名：客户端使用证书颁发者的公钥（公钥为操作系统内置）解密证书中的数字签名，然后计算证书内容的哈希值。如果解密后的哈希值与计算出的哈希值相同，证书被认为是真实的且未被篡改。否则，证书将被视为无效。

6. 检查吊销状态：客户端可以通过证书吊销列表（CRL）或在线证书状态协议（OCSP）查询证书的吊销状态。如果证书被吊销，客户端将拒绝建立连接。

只有在证书通过所有这些验证步骤之后，客户端才会认为证书有效，并与服务器建立安全的HTTPS连接。如果验证失败，客户端会发出警告或拒绝建立连接，这也就是开头浏览器弹出红色告警的原因。

总结

所以整个工作流程为

1. 客户端请求服务器

2. 服务器返回数字证书

3. 客户端验证证书的有效性，验证通过则从证书提取公钥，并用公钥来加密 随机数C，将加密后的数据发往服务器

4. 服务器使用私钥解密数据得到 随机数C

5. 服务器和客户端都拥有了 随机数C,这个随机数C就作为对称加密算法的秘钥，后续都使用对称加密算法来加密数据。

这个过程中即使黑客使用自己生成的公钥来替换服务器的公钥发送给客户端，显然这个公钥和证书上的公钥是对不上的，且加上其他效验条件证书肯定是效验不通过的。这时浏览器便发出告警，但依然无法阻止你无视风险继续浏览。

可以看到，这个裁判也就是CA机构尤为关键，证书的颁发依靠人，但只要是人，都会犯错。就像google投诉赛门铁克乱发证书、谷歌和火狐浏览器都宣布不再信任中国CNNIC数字证书，各种闹剧总在上演。

后续又加入了证书透明度（Certificate Transparency，CT）机制，但仍存在或多或少的问题。

总之，技术在不断发展与进步，攻击方式与防御手段在不断地变化，矛与盾永远存在。