2020-08-10 https理解

Posted 2023-05-09

参考技术A

TLS/SSL的功能实现主要依赖于 三类基本算法 ： 散列（哈希）函数 Hash 、 对称加密 和 非对称加密 ，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列（哈希）函数验证信息的完整性。

TCP握手建立链接后，客户端向服务端发送https请求前要握手一次，主要是认证服务端是否可信，与服务端协商后续传输数据的加密方式，以及校验完整性的签名方式（HASH）

解决上述身份验证问题的关键是确保获取的公钥途径是合法的，能够验证服务器的身份信息，为此需要引入权威的第三方机构CA。简单的说，PKI就是浏览器和CA，CA是整个安全机制的重要保障，我们平时用的证书就是由CA机构颁发，其实就是 用CA的私钥给用户的证书签名 ，然后在证书的签名字段中填充这个签名值，浏览器在验证这个证书的时候就是使用CA的公钥进行验签。

在这个过程注意几点：
a.申请证书不需要提供私钥， 确保私钥永远只能服务器掌握 ;
b.证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名;
c.内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书（为什么说"部署自签SSL证书非常不安全"）
d. 证书=公钥（服务方生成密码对中的公钥）+申请者与颁发者信息+签名（用CA机构生成的密码对的私钥进行签名） ;

即便有人截取服务器A证书，再发给客户端，想冒充服务器A，也无法实现。因为证书和url的域名是绑定的。

1）颁发证书，颁发证书其实就是使用CA的私钥对证书请求签名文件进行签名；

2）颁发的证书浏览器要信任，浏览器只需要用CA的公钥进行验签成功就表示这个证书是合法可信的，这就需要浏览器内置CA的公钥，也就是内置CA的证书。一般来说，操作系统都会内置权威CA的证书，有的浏览器会使用操作系统内置的CA证书列表，有的浏览器则自己维护的CA证书列表，比如Firefox。

如 CA根证书和服务器证书中间增加一级证书机构，即中间证书，证书的产生和验证原理不变，只是增加一层验证，只要最后能够被任何信任的CA根证书验证合法即可。
a.服务器证书 server.pem 的签发者为中间证书机构 inter，inter 根据证书 inter.pem 验证 server.pem 确实为自己签发的有效证书;
b.中间证书 inter.pem 的签发 CA 为 root，root 根据证书 root.pem 验证 inter.pem 为自己签发的合法证书;
c.客户端内置信任 CA 的 root.pem 证书，因此服务器证书 server.pem 的被信任。

服务器证书、中间证书与根证书在一起组合成一条合法的证书链，证书链的验证是自下而上的信任传递的过程。
二级证书结构存在的优势：
a.减少根证书结构的管理工作量，可以更高效的进行证书的审核与签发;
b .根证书一般内置在客户端（浏览器或操作系统）中 ，私钥一般离线存储，一旦私钥泄露，则吊销过程非常困难，无法及时补救;
c.中间证书结构的私钥泄露，则可以快速在线吊销，并重新为用户签发新的证书;
d.证书链四级以内一般不会对 HTTPS 的性能造成明显影响。

证书链有以下特点：
a.同一本服务器证书可能存在多条合法的证书链。
因为证书的生成和验证基础是公钥和私钥对，如果采用相同的公钥和私钥生成不同的中间证书，针对被签发者而言，该签发机构都是合法的 CA，不同的是中间证书的签发机构不同;
b.不同证书链的层级不一定相同，可能二级、三级或四级证书链。
中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构，所以证书链层级不一定相同。

交叉证书的应用场景是这样的：假如现在阿里云成为一个新的根CA机构，那阿里云签发的证书想要浏览器信任的话，阿里云的根证书就需要内置在各大操作系统和浏览器中，这需要较长时间的部署，那在没有完全部署完成之前，阿里云签发的证书怎么才能让浏览器信任呢，这就需要用到交叉证书了。

上图中，根证书A是一个所有浏览器都内置了的根证书，B是一个新的根证书，用户证书D是由根证书 B的二级CA B1来签发的，但是根证书B并没有在浏览器中内置，所以浏览器不会信任用户证书D，这是因为浏览器在验签时只验证到B1这一层然后找不到根证书B就无法验证下去了。

如果二级CA B1证书是由根证书A来签名，那这个问题就解了，所以新的根证书机构B会将二级CA证书（准确地讲是二级CA的证书签名请求文件）给老的根证书A来签名，然后得到一个新的中间证书就是交叉证书。

浏览器在验证的时侯用了新的信任链，这样就可以解决用户证书的信任问题。

当B的根证书全部部署完成后，再替换成自己的二级CA就可以了。

证书分有三类：DV、OV、EV

DV证书只校验域名的所有权，所以我们在申请DV证书的时候CA会提供几种验证域名所有权的方法：比如文件校验、DNS校验、邮件校验，DV证书支持单域名、多域名和泛域名，但不支持多个泛域名，只支持一个泛域名，一般价格比较便宜，具体价格跟域名的数量有关，域名越多价格越高。

OV证书要验证组织机构，在申请证书时CA会打电话确认这个域名是否真的属于相应的公司或者机构，OV证书是单域名、多域名、泛域名和多个泛域名都支持，价格一般比DV证书要贵。

EV证书的校验就更细了，比如组织机构的地址之类的，EV证书会在地址栏上显示组织机构的名称，EV证书只支持单域名或者多个域名，不支持泛域名，而且更贵，所以普通用户一般不会用EV证书。

证书是有生命周期的，如果证书的私钥泄漏了那这个证书就得吊销，一般有两种吊销方式：CRL和OCSP。

CRL（ Certificate Revocation List）是CA机构维护的一个已经被吊销的证书序列号列表，浏览器需要定时更新这个列表，浏览器在验证证书合法性的时候也会在证书吊销列表中查询是否已经被吊销，如果被吊销了那这个证书也是不可信的。可以看出，这个列表随着被吊销证书的增加而增加，列表会越来越大，浏览器还需要定时更新，实时性也比较差。

所以，后来就有了 OCSP （Online Certificate Status Protocol）在线证书状态协议，这个协议就是解决了 CRL 列表越来越大和实时性差的问题而生的。有了这个协议，浏览器就可以不用定期更新CRL了，在验证证书的时候直接去CA服务器实时校验一下证书有没有被吊销就可以，是解决了CRL的问题，但是每次都要去CA服务器上校验也会很慢，在网络环境较差的时候或者跨国访问的时候，体验就非常差了，OCSP虽然解决了CRL的问题但是性能却很差。

主要摘自

http://www.360doc.com/content/18/0606/20/13644263_760231690.shtml

https://blog.csdn.net/hherima/article/details/52469360

https://blog.csdn.net/hherima/article/details/52469488

理解 HTTPS 的工作原理

目标读者：理解HTTP协议，对称和非对称加密，想要了解HTTPS协议的工作原理。

读完本文，你能明白

• 什么是HTTPS，TLS(SSL)，TLS和HTTPS是什么关系？

• 什么是证书和数字签名，它们是如何传递信任的？

• HTTPS有什么样的功能，它是如何实现这样的功能的？

简介

HTTPS，也称作HTTP over TLS。，TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。本文着重描述TLS协议的1.2版本。

下图描述了在TCP/IP协议栈中TLS(各子协议）和HTTP的关系

Credit: From:

其中Handshake protocol，Change Ciper Spec protocol和Alert protocol组成了SSL Handshaking Protocols。

HTTPS和HTTP协议相比提供了

1. 数据完整性：内容传输经过完整性校验

2. 数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥

3. 身份认证：第三方无法伪造服务端（客户端）身份

其中，数据完整性和隐私性由TLS Record Protocol保证，身份认证由TLS Handshaking Protocols实现。

总览

使用RSA算法的SSL握手过程是这样的：

Source:

1. [明文] 客户端发送随机数client_random和支持的加密方式列表

2. [明文] 服务器返回随机数server_random，选择的加密方式和服务器证书链

3. [RSA] 客户端验证服务器证书，使用证书中的公钥加密premaster secret发送给服务端

4. 服务端使用私钥解密premaster secret

5. 两端分别通过client_random，server_random和premaster secret生成master secret，用于对称加密后续通信内容

证书Digital certificate

那么什么是证书呢？

证书中包含什么信息：

• 证书信息：过期时间和序列号

• 所有者信息：姓名等

• 所有者公钥

为什么服务端要发送证书给客户端？

互联网有太多的服务需要使用证书来验证身份，以至于客户端（操作系统或浏览器等）无法内置所有证书，需要通过服务端将证书发送给客户端。

客户端为什么要验证接收到的证书？

中间人攻击

客户端<------------攻击者<------------服务端
        伪造证书            拦截请求

客户端如何验证接收到的证书？

为了回答这个问题，需要引入数字签名Digital Signature。

+---------------------+
| A digital signature |
|(not to be confused  |
|with a digital       |
|certificate)         |            +---------+              +--------+
| is a mathematical   |----哈希--->| 消息摘要  |---私钥加密--->| 数字签名 |
|technique used       |            +---------+              +--------+
|to validate the      |
|authenticity and     |
|integrity of a       |
|message, software    |
|or digital document. |
+---------------------+

将一段文本通过哈希hash和私钥加密处理后生成数字签名。

假设消息传递在Bob，Susan和Pat三人之间发生。Susan将消息连同数字签名一起发送给Bob，Bob接收到消息后，可以这样验证接收到的消息就是Susan发送的

+---------------------+
| A digital signature |
|(not to be confused  |
|with a digital       |
|certificate)         |            +---------+
| is a mathematical   |----哈希--->|  消息摘要 |
|technique used       |            +---------+
|to validate the      |                 |
|authenticity and     |                 |
|integrity of a       |                 |
|message, software    |                 对
|or digital document. |                 比
+---------------------+                 |
                                        |
                                        |
          +--------+               +---------+ 
          | 数字签名 |---公钥解密--->|  消息摘要 | 
          +--------+               +---------+

当然，这个前提是Bob知道Susan的公钥。更重要的是，和消息本身一样，公钥不能在不安全的网络中直接发送给Bob。

此时就引入了Certificate Authority，CA，CA数量并不多，Bob客户端内置了所有受信任CA的证书。CA对Susan的公钥（和其他信息）数字签名后生成证书。

Susan将证书发送给Bob后，Bob通过CA证书的公钥验证证书签名。

Bob信任CA，CA信任Susan 使得 Bob信任Susan，Chain Of Trust就是这样形成的。

事实上，Bob客户端内置的是CA的根证书Root Certificate，HTTPS协议中服务器会发送证书链Certificate Chain给客户端。

TLS协议包括TLS Record Protocol和TLS Handshake Protocol。总览中的流程图仅涉及到TLS Handshake Protocol。

TLS Record Protocol

在TLS协议中，有四种子协议运行于Record protocol之上

• Handshake protocol

• Alert protocol

• Change cipher spec protocol

• Application data protocol

Record protocol起到了这样的作用

• 在发送端：将

  数据Record

  分段，压缩，增加(Message Authentication Code)和加密

• 在接收端：将

  数据Record

  解密，验证MAC，解压并重组

值得一提的是，Record protocol提供了数据完整性和隐私性保证，但Record类型type和长度length是公开传输的

Record Protocol有三个连接状态Connection State，连接状态定义了压缩，加密和MAC算法。所有的Record都是被当前状态Current State确定的算法处理的。

TLS Handshake Protocol和Change Ciper Spec Protocol会导致Record Protocol状态切换。

empty state -------------------> pending state ------------------> current state
             Handshake Protocol                Change Cipher Spec

初始当前状态Current State没有指定加密，压缩和MAC算法，因而在完成TLS Handshaking Protocols一系列动作之前，客户端和服务端的数据都是明文传输的；当TLS完成握手过程后，客户端和服务端确定了加密，压缩和MAC算法及其参数，数据Record会通过指定算法处理。

其中，Record首先被加密，然后添加MAC（message authentication code）以保证数据完整性。

TLS Handshaking Protocols

Handshakeing protocols包括Alert Protocol，Change Ciper Spec Protocol和Handshake protocol。本文不会详细介绍Alert Protocol和Change Ciper Spec Protocol。

使用RSA算法的握手过程是这样的（已在总览中提到）

Source:

客户端和服务端在握手hello消息中明文交换了client_random和server_random，使用RSA公钥加密传输premaster secret，最后通过，客户端和服务端分别计算master secret。其中，不直接使用premaster secret的原因是：保证secret的随机性不受任意一方的影响。

除了使用RSA算法在公共信道交换密钥，还可以通过Diffie–Hellman算法。Diffie–Hellman算法的原理是这样的：

By Original schema: A.J. Han Vinck, University of Duisburg-Essen SVG version: Flugaal [Public domain], via Wikimedia Commons

使用Diffie–Hellman算法交换premaster secret的流程

Source:

小结

TLS Handshaking Protocols协商了TLS Record Protocol使用的算法和所需参数，并验证了服务端身份；TLS Record Protocol在协商后保证应用层数据的完整性和隐私性。

TLS Handshaking Protocol的核心是在公开信道上传递premaster secret。

Q&A

为什么传输内容不直接使用非对称加密？

性能

HTTPS能保证正常连接？

no

There are a number of ways in which a man-in-the-middle attacker can attempt to make two entities drop down to the least secure method they support.

攻击者甚至可以直接丢弃双方的数据包。

服务端如何验证客户端身份？

通过Client Certificate

This message conveys the client's certificate chain to the server; the server will use it when verifying the CertificateVerify message (when the client authentication is based on signing) or calculating thepremaster secret (for non-ephemeral Diffie- Hellman). The certificate MUST be appropriate for the negotiated cipher suite's key exchange algorithm, and any negotiated extensions.

Alert protocol有什么作用？

Closure Alerts：防止Truncation Attack

In a truncation attack, an attacker inserts into a message a TCP code indicating the message has finished, thus preventing the recipient picking up the rest of the message. To prevent this, SSL from version v3 onward has a closing handshake, so the recipient knows the message has not ended until this has been performed.

Error Alerts：错误处理

master secret是如何计算的

  master_secret = PRF(pre_master_secret, "master secret",
                      ClientHello.random + ServerHello.random)
                      [0..47];

加密，压缩和MAC算法参数是如何计算的

Handshaking Protocols使得客户端和服务端交换了三个参数：client_random，server_random和master_secret，通过以下算法生成算法所需要的参数

To generate the key material, compute

  key_block = PRF(SecurityParameters.master_secret,
                  "key expansion",
                  SecurityParameters.`server_random ` +
                  SecurityParameters.`client_random`);

until enough output has been generated.  Then, the key_block is
partitioned as follows:

  client_write_MAC_key[SecurityParameters.mac_key_length]
  server_write_MAC_key[SecurityParameters.mac_key_length]
  client_write_key[SecurityParameters.enc_key_length]
  server_write_key[SecurityParameters.enc_key_length]
  client_write_IV[SecurityParameters.fixed_iv_length]
  server_write_IV[SecurityParameters.fixed_iv_length]

The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key

使用Diffie-Hellman算法的TLS握手细节

Source:

拓展阅读

• Session resume

• 证书Revoke

参考链接

1. TLS1.2规范：

2. 证书和数字签名：

3. TLS Handshake：