HTTPS工作原理及报文讲解

1 HTTPS

1.1 HTTPS简介

HTTPS (Secure Hypertext Transfer Protocol)安全超文本传输协议，是一个安全通信通道，它基于HTTP开发用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版,是使用TLS/SSL加密的HTTP协议。 

SSL (Secure Sockets Layer）安全套接层。是由Netscape公司于1990年开发，用于保障Word Wide Web（WWW）通讯的安全。主要任务是提供私密性，信息完整性和身份认证。1994年改版为SSLv2,1995年改版为SSLv3。

TLS(Transport Layer Security）安全传输层协议。用于在两个通信应用程序之间提供保密性和数据完整性。该标准协议是由IETF于1999年颁布，整体来说TLS非常类似SSLv3，只是对SSLv3做了些增加和修改。

TLS/SSL全称安全传输层协议Transport Layer Security, 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。

                                        

                                                   

 

 

1.2 HTTP和HTTPS区别

1、https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。

2、http是超文本传输协议，采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险。https则是具有安全性的ssl/tls加密传输协议。而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能，可以避免此类问题发生。

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443；使用的URL也不一样，前者为http//:URL，后者为https//:URL。

4、http的连接很简单，是无状态的；HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

1.3 TLS/SSL协议工作原理

1.3.1 TLS/SSL协议结构

SSL是一个不依赖于平台和运用程序的协议，位于TCP/IP协议与各种应用层协议之间，为数据通信提高安全支持。SSL协议结构如下图：

                                                          

 

图：SSL协议结构图

 

SSL的体系结构中包含两个协议子层，其中底层是SSL记录协议层（SSL Record Protocol Layer）；高层是SSL握手协议层（SSL HandShake Protocol Layer）。

 

SSL协议主要分为两层：

SSL记录协议层的作用是为高层协议提供基本的安全服务。SSL纪录协议针对HTTP协议进行了特别的设计，使得超文本的传输协议HTTP能够在SSL运行。纪录封装各种高层协议，具体实施压缩解压缩、加密解密、计算和校验MAC等与安全有关的操作。

SSL握手协议层包括SSL握手协议（SSL HandShake Protocol）、SSL密码参数修改协议（SSL Change Cipher Spec Protocol）和SSL告警协议（SSL Alert Protocol）。握手层的这些协议用于SSL管理信息的交换，允许应用协议传送数据之间相互验证，协商加密算法和生成密钥等。

SSL握手协议的作用是协调客户和服务器的状态，使双方能够达到状态的同步。

其中最重要的是记录协议和握手协议：

SSL记录协议：它建立在可靠的传输（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能。

SSL握手协议：它建立在SSL记录协议之上，用于在实际的数据传输开始之前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

注：本文主要介绍SSL握手协议，省略SSL记录协议

1.3.2 SSL/TLS握手协议建立连接过程

SSL 握手协议是SSL 协议中最重要同时也是最复杂的协议。

SSL 握手协议主要负责如下工作：

1、算法协商 

2、身份验证

  3、确定密钥

SSL握手过程分为四种:

1、Full Handshake : 全流程握手，C/S双方从无到有建立SSL连接；

2、Resum session Handshake : C/S双方曾经建立过连接，但中途断了，SSL会话信息还有保留，只需要执行部分握手流程就可建立SSL连接；

3、Server Re-negotiation Handshake : 已经建立了SSL连接，但server端为了某些原因(比如安全性)要求重新对密钥进行协商，也只需要执行部分握手流程；

4、Client Re-negotiation Handshake : 已经建立SSL连接，但client端为了某些原因要求重新协商，只需执行部分握手流程。

 

下文将介绍全流程握手的流程：

                               

 

图：SSL/TLS握手协议建立连接过程图

 

 

1、client_hello

    客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息，相关信息如下：

    • 支持的最高TSL协议版本version，从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，当前基本不再使用低于 TLSv1 的版本;

    • 客户端支持的加密套件 cipher suites 列表， 每个加密套件对应前面 TLS 原理中的四个功能的组合：认证算法 Au (身份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验);

    • 支持的压缩算法 compression methods 列表，用于后续的信息压缩传输;

    • 随机数 random_C，用于后续的密钥的生成;

• 扩展字段 extensions，支持协议与算法的相关参数以及其它辅助信息等，常见的 SNI 就属于扩展字段，后续单独讨论该字段作用。

2、server_hello+server_certificate+sever_hello_done

• server_hello, 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 等，其中随机数用于后续的密钥协商;

• server_certificates, 服务器端配置对应的证书链，用于身份验证与密钥交换;

 

    • server_hello_done，通知客户端 server_hello 信息发送结束;

 

3、证书校验

    客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证包括如下：

    • [证书链]的可信性 trusted certificate path，方法如前文所述;

    • 证书是否吊销 revocation，有两类方式离线 CRL 与在线 OCSP，不同的客户端行为会不同;

    • 有效期 expiry date，证书是否在有效时间范围;

    • 域名 domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析;

4、client_key_exchange+change_cipher_spec+encrypted_handshake_message

1. client_key_exchange，合法性验证通过之后，客户端计算产生随机数字 Pre-master，并用证书公钥加密，发送给服务器;

    (b) 此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，计算得到协商密钥;

enc_key=Fuc(random_C, random_S, Pre-Master)

    (c) change_cipher_spec，客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;

    (d) encrypted_handshake_message，结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证;

5、change_cipher_spec+encrypted_handshake_message

    (a) 服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);

    (b) 计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;

    (c) change_cipher_spec, 验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;

    (d) encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端;

6、握手结束

    客户端计算所有接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握手完成;

7、加密通信

    开始使用协商密钥与算法进行加密通信。

注意：

    (a) 服务器也可以要求验证客户端，即双向认证，可以在过程2要发送 client_certificate_request 信息，客户端在过程4中先发送 client_certificate与certificate_verify_message 信息，证书的验证方式基本相同，certificate_verify_message 是采用client的私钥加密的一段基于已经协商的通信信息得到数据，服务器可以采用对应的公钥解密并验证;

    (b) 根据使用的密钥交换算法的不同，如 ECC 等，协商细节略有不同，总体相似;

    (c) sever key exchange 的作用是 server certificate 没有携带足够的信息时，发送给客户端以计算 pre-master，如基于 DH 的证书，公钥不被证书中包含，需要单独发送;

    (d) change cipher spec 实际可用于通知对端改版当前使用的加密通信方式，当前没有深入解析;

    (e) alter message 用于指明在握手或通信过程中的状态改变或错误信息，一般告警信息触发条件是连接关闭，收到不合法的信息，信息解密失败，用户取消操作等，收到告警信息之后，通信会被断开或者由接收方决定是否断开连接。

1.2.3 SSL/TLS报文分析

                                                        

 

图：SSL建立总过程

 

在用SSL进行通信之前，首先要使用SSL的Handshake协议在通信两端握手，协商数据传输中要用到的相关安全参数（如加密算法、共享密钥、产生密钥所要的材料等），并对对端的身份进行验证。

                           

SSL的建立过程总共有13个包，第一次建立至少需要9个包。

 

 

图：TLS握手协议过程报文

SSL建立第一阶段：Client Hello，Server Hello

客户端首先发送Client Hello消息到服务端，服务端收到ClientHello消息后，再发送ServerHello消息回应客户端。

                                                    

 

图：SSL建立第一阶段报文交换示意图

 

Client Hello

握手第一步是客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数Random1、客户端支持的加密套件（Support Ciphers）和 SSL Version 等信息。通过 Wireshark 抓包，我们可以看到如下信息：

                                      

 

图：ClinetHello报文抓包示例

ClientHello中涉及到的消息具体如下：

1. 客户端版本

按优先级列出客户端支持的协议版本，首选客户端希望支持的最新协议版本。

1. 客户端随机数Random
2. 会话ID（Session id）

如果客户端第一次连接到服务器，那么这个字段就会保持为空。上图中该字段为空，说明这是第一次连接到服务器。

如果该字段不为空，说明以前是与服务器有连接的，在此期间，服务器将使用Session ID映射对称密钥，并将Session ID存储在客户端浏览器中，为映射设置一个时间限。如果浏览器将来连接到同一台服务器（在时间到期之前），它将发送Session ID，服务器将对映射的Session ID进行验证，并使用以前用过的对称密钥来恢复Session，这种情况下不需要完全握手。也叫作SSL会话恢复。后面会有介绍。

1. 加密套件

客户端会给服务器发送自己已经知道的密码套件列表，这是由客户按优先级排列的，但完全由服务器来决定发送与否。TLS中使用的密码套件有一种标准格式。上面的报文中，客户端发送了17套加密套件。服务端会从中选出一种来作为双方共同的加密套件。

1. 压缩方法

为了减少带宽，可以进行压缩。但从成功攻击TLS的事例中来看，其中使用压缩时的攻击可以捕获到用HTTP头发送的参数，这个攻击可以劫持Cookie，这个漏洞我们称为CRIME。从TLS 1.3开始，协议就禁用了TLS压缩。

1. 扩展包

其他参数（如服务器名称，填充，支持的签名算法等）可以作为扩展名使用。

这些是客户端问候的一部分，如果已收到客户端问候，接下来就是服务器的确认，服务器将发送服务器问候。

 

每一条消息都会包含有ContentType,Version,HandshakeType等信息。

Conten Type：指SSL通信处于那个阶段

*Handshake：握手

*Change cipher Spec：开始加密传输

*Application Data：正常通信

*Alert：告警

 

Version：SSL/TLS的版本如下表：

                                                   

 

Handshake Type是表示在handshanke阶段中的具体哪一步，见下表

 

                                     

                  

 

Server Hello

服务端向客户端发送 Server Hello 消息，这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用哪些算法，另外还会生成一份随机数 Random2。注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。

                     

 

图：ServerHello报文抓包

ServerHello中涉及到的具体参数：

1.服务器版本Version

服务器会选择客户端支持的最新版本。

2.服务器随机数Random

服务器和客户端都会生成32字节的随机数。用来创建加密密钥。

3.加密套件

服务器会从客户端发送的加密套件列表中选出一个加密套件。

4.会话ID（Session ID）

服务器将约定的Session参数存储在TLS缓存中，并生成与其对应的Session id。它与Server Hello一起发送到客户端。客户端可以写入约定的参数到此Session id，并给定到期时间。客户端将在Client Hello中包含此id。如果客户端在此到期时间之前再次连接到服务器，则服务器可以检查与Session id对应的缓存参数，并重用它们而无需完全握手。这非常有用，因为服务器和客户端都可以节省大量的计算成本。

在涉及亚马逊和谷歌等流量巨大的应用程序时，这种方法存在缺点。每天都有数百万人连接到服务器，服务器必须使用Session密钥保留所有Session参数的TLS缓存。这是一个巨大的开销。

为了解决这个问题，在扩展包里加入了Session Tickets, 在这里，客户端可以在client hello中指定它是否支持Session Ticket。然后，服务器将创建一个新的会话票证(Session Ticket)，并使用只有服务器知道的经过私钥加密的Session参数。它将存储在客户端上，因此所有Session数据仅存储在客户端计算机上，但Ticket仍然是安全的，因为该密钥只有服务器知道。

此数据可以作为名为Session Ticket的扩展包含在Client Hello中。

5.压缩算法

如果支持，服务器将同意客户端的首选压缩方法。

6.扩展包

 

在第一个阶段完成之后，客户端服务端知道了下列内容：

1. SSL版本
2. 密钥交换、信息验证和加密算法
3. 压缩方法
4. 有关密钥生成的两个随机数。

 

SSL建立第二阶段：Certificate，Server Hello Done

服务器向客户端发送消息。

                             

 

图：SSL建立第二阶段报文交换示意图

服务器启动SSL握手第2阶段，是本阶段所有消息的唯一发送方，客户机是所有消息的唯一接收方。该阶段分为4步：

1. 证书（可选）：服务器将数字证书和到根CA整个链发给客户端，使客户端能用服务器证书中的服务器公钥认证服务器。
2. 服务器密钥交换（可选）：这里视密钥交换算法而定
3. 证书请求（可选）：服务端可能会要求客户自身进行验证。
4. 服务器握手完成：第二阶段的结束，第三阶段开始的信号

Certificate（可选）第一次建立必须要有证书

服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证通过后取出证书中的公钥。

图：Certificate报文

Server Key Exchange（可选）

根据之前在ClientHello消息中包含的CipherSuite信息，决定了密钥交换方式（例如RSA或者DH），因此在Server Key Exchange消息中便会包含完成密钥交换所需的一系列参数。省略报文。

Certificate Request（可选）------可以是单向的身份认证，也可以双向认证

这一步是可选的，如果在对安全性要求高的常见可能用到。服务器用来验证客户端。服务器端发出Certificate Request消息，要求客户端发他自己的证书过来进行验证。该消息中包含服务器端支持的证书类型（RSA、DSA、ECDSA等）和服务器端所信任的所有证书发行机构的CA列表，客户端会用这些信息来筛选证书。省略报文。

Server Hello Done

Server Hello Done 通知客户端 Server Hello 过程结束，表示服务器已经将所有信息发送完毕，接下来等待客户端的消息。

图：Server Hello Done报文

SSL建立第三阶段：Client Key Exchange

客户端收到服务器发送的一系列消息并解析后，将本端相应的消息发送给服务器。

                                          

图：SSL建立第三阶段报文交换示意图

客户端启动SSL握手第3阶段，是本阶段所有消息的唯一发送方，服务器是所有消息的唯一接收方。该阶段分为3步：

1.证书（可选）：为了对服务器证明自身，客户要发送一个证书信息，这是可选的，在IIS中可以配置强制客户端证书认证。

2.客户机密钥交换（Pre-master-secret）：这里客户端将预备主密钥发送给服务端，注意这里会使用服务端的公钥进行加密。

3.证书验证（可选），对预备秘钥和随机数进行签名，证明拥有（a）证书的公钥。

                        

Certificate（可选）

如果在第二阶段服务器端要求发送客户端证书，客户端便会在该阶段将自己的证书发送过去。服务器端在之前发送的Certificate Request消息中包含了服务器端所支持的证书类型和CA列表，因此客户端会在自己的证书中选择满足这两个条件的第一个证书发送过去。若客户端没有证书，则发送一个no_certificate警告。

Client Key Exchange

上面客户端根据服务器传来的公钥生成了 PreMaster Key，Client Key Exchange 就是将这个 key 传给服务端，服务端再用自己的私钥解出这个 PreMaster Key 得到客户端生成的 Random3。至此，客户端和服务端都拥有 Random1 + Random2 + Random3，两边再根据同样的算法就可以生成一份秘钥，握手结束后的应用层数据都是使用这个秘钥进行对称加密。为什么要使用三个随机数呢？这是因为 SSL/TLS 握手过程的数据都是明文传输的，并且多个随机数种子来生成秘钥不容易被暴力破解出来。客户端将 PreMaster Key 传给服务端的过程如下图所示：

                                                           

图：Clinet Key exchange报文

客户端收到服务器所有响应消息后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥，即server 消息中携带的public key值。然后，根据已经收到的三个随机数计算出加密密钥，对握手信息进行加密通信，然后向服务器发送上面抓包中三项信息内容。

该步骤中的随机数，是整个握手阶段出现的第三个随机数，又称”pre-master key”。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把”会话密钥”。

Certificate verify（可选）

只有在客户端发送了自己证书到服务器端，这个消息才需要发送。其中包含一个签名，对从第一条消息以来的所有握手消息的HMAC值（用master_secret）进行签名。

SSL建立第四阶段：Client/Server 发送Change Cipher Spec报文，Client/Server 发送Encrypted Handshake Message报文

完成握手协议，建立SSL连接。

                                              

图：SSL建立第四阶段报文交换示意图

客户端启动SSL握手第4阶段，使服务器结束。该阶段分为4步，前2个消息来自客户机，后2个消息来自服务器。

1.建立起一个安全的连接，客户端发送一个Change Cipher Spec消息，并且把协商得到的CipherSuite拷贝到当前连接的状态之中

2.客户端用新的算法、密钥参数发送一个Finished消息，这条消息可以检查密钥交换和认证过程是否已经成功。其中包括一个校验值，对客户端整个握手过程的消息进行校验。

3.服务器发送Change Cipher Spec消息，检查密钥交换和认证过程是否已经成功，验证通过后，server告知client从现在开始发送的消息都是加密过的。

4.服务器发送Finished消息，客户端和服务器可以交换应用层数据进行通信。

Clinet发送Change Cipher Spec

客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了，是一条事件消息。

                             

图：Client发送Change Cipher Spec报文

client指示Server从现在开始发送的消息都是加密过的。

 

Client发送Encrypted Handshake Message

这一步对应的是 Client Finish 消息，客户端握手结束通知, 表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验（使用HMAC算法计算收到和发送的所有握手消息的摘要，然后通过RFC5246中定义的一个伪函数PRF计算出结果，加密后发送。此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。）

                                     

图：Client发送Encrypted Handshake Message

 

Server发送Change Cipher Spec

服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;

验证通过后，Server告知client从现在开始发送的消息都是加密过的。

这次Sever一个报文共发送的2个消息：Change Cipher Spec和Finish。

                          

图：Server发送Change Cipher Spec报文

Server发送Encrypted Handshake Message

这一步对应的是 Server Finish 消息，服务端握手结束通知。

1.使用私钥解密加密的Pre-master数据，基于之前(Client Hello 和 Server Hello)交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);

2.计算之前所有接收信息的 hash 值，然后解密客户端发送的encrypted_handshake_message，验证数据和密钥正确性;

3.发送一个 ChangeCipherSpec（告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了）

4.服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。

 

根据之前的握手信息，如果客户端和服务端都能对Finish信息进行正常加解密且消息正确的被验证，则说明握手通道已经建立成功，接下来，双方可以使用上面产生的Session Secret对数据进行加密传输了。

                                

图：Server发送Encrypted Handshake Message报文

SSL传输数据：Application Data

Application Data

到这里，双方已安全地协商出了同一份秘钥，所有的应用层数据都会用这个秘钥加密后再通过 TCP 进行可靠传输。

                           

图：SSL 传输数据Application Data报文

通过上述报文对https的讲解，可以将https的通信图总结如下：

                      

图:https的通信过程