SSL/TLS单向认证和双向认证介绍

川长思鸟来 2023-02-19 06:30 987阅读 0赞

为了便于理解SSL/TLS的单向认证和双向认证执行流程，这里先介绍一些术语。

1. **散列函数**(Hash function)：又称散列算法、哈希函数，是一种从任何一种数据中创建小的数字”指纹”的方法。**散列函数把消息或数据压缩成摘要**，使得数据量变小，将数据的格式固定下来。该函数将数据打乱混合，重新创建一个叫做散列值(hash values, hash codes, hash sums)的指纹。**散列值通常用一个短的随机字母和数字组成的字符串代表**。好的散列函数在输入域中很少出现散列冲突。

散列函数的工作原理如下图所示：把输入(消息、文件等)看成n比特块的序列。对输入用迭代方式每次处理一块，生成n比特的散列函数。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg_size_16_color_FFFFFF_t_70][]

所有散列函数都有如下一个基本特性：如果两个散列值是不相同的(根据同一函数)，那么这两个散列值的原始输入也是不相同的。这个特性是散列函数具有确定性的结果，具有这种性质的散列函数称为单向散列函数。但另一方面，散列函数的输入和输出不是唯一对应关系的，如果两个散列值相同，两个输入值很可能是相同的，但也可能不同，这种情况称为”散列碰撞(collision)”，这通常是两个不同长度的输入值，刻意计算出相同的输出值。输入一些数据计算出散列值，然后部分改变输入值，一个具有强混淆特性的散列函数会产生一个完全不同的散列值。典型的散列函数都有非常大的定义域，比如SHA-2最高接受(2^64-1)/8长度的字节字符串。同时散列函数一定有着有限的值域，比如固定长度的比特串。在某些情况下，散列函数可以设计成具有相同大小的定义域和值域间的单射。在密码学中，散列函数必须具有不可逆性。

为满足在消息认证中的应用，散列函数H必须具有下列性质：

(1).H可适用于任意长度的数据块。

(2).H能生成固定长度的输出。

(3).对于任意给定的x，计算H(x)相对容易，并且可以用软/硬件方式实现。

(4).对于任意给定值h，找到满足H(x)=h的x在计算上不可行。满足这一特性的散列函数称为具有单向性，或具有抗原像攻击性。

(5).对于任意给定的数据块x，找到满足H(y)=H(x)的y!=x在计算上是不可行的。满足这一特性的散列函数被称为具有抗第二原像攻击性，有时也称为具有抗弱碰撞攻击性。

(6).找到满足H(x)=H(y)的任意一对(x,y)在计算上是不可行的。满足这一特性的散列函数被称为抗碰撞性，有时也被称为抗强碰撞性。

前三个性质是使用散列函数进行消息认证的实际可行要求。第四个属性，抗原像攻击，是单向性：给定消息容易产生它的散列码，但是给定散列码几乎不可能恢复出消息。抗第二原像攻击性质保证了对于给定的消息，不可能找到具有相同散列值的可替换消息。满足上面前5个性质的散列函数称为弱散列函数。如果还满足第6个性质则称其为强散列函数。除提供认证之外，消息摘要还能验证数据的完整性。

应用最为广泛的散列函数是安全散列算法(SHA)。SHA是基于散列函数MD4，按照消息摘要大小，可分为SHA-1、SHA-224、SHA-256、SHA-384、SHA-512，后4种又被称为SHA-2，它们输出摘要大小依次为160bits、224bits、256bits、384bits、512bits。SHA-1不再认可。

2. **HMAC**(Hash-based Message Authentication Code)：基于Hash的消息认证码，又称散列消息认证码，**是一种通过特别计算方式之后产生的消息认证码****(MAC)****，使用密码散列函数，同时结合一个加密密钥**。它可以用来保证数据的完整性，同时可以用来作某个消息的身份验证。HMAC运算利用哈希算法，**以一个密钥和一个消息作为输入，生成一个消息摘要作为输出**。使用消息摘要算法MD2、MD4、MD5、SHA-1、SHA-224、SHA-256、SHA-384、SHA-512所构造的HMAC，分别称为HMAC-MD2、HMAC-MD4、HMAC-MD5、HMAC-SHA1、HMAC-SHA-224、HMAC-SHA-384、HMAC-SHA-512。

3. **数字签名**(digital signature)：又称公钥数字签名，是一种功能类似写在纸上的普通签名，但是使用了公钥加密领域的技术，以用于鉴别数字信息的方法。**一套数字签名通常会定义两种互补的运算，一个用于签名，另一个用于验证**。数字签名是非对称密钥加密技术与数字摘要技术的应用。数字签名了的文件的完整性是很容易验证的，而且数字签名具有不可抵赖性(即不可否认性)，其过程如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg_size_16_color_FFFFFF_t_70 1][]

每个人都有一对”钥匙”(数字身份)，其中一个只有本人知道(私钥)，另一个公开的(公钥)。签名的时候用私钥，验证签名的时候用公钥。又因为任何人都可以落款申称他就是使用者本人，因此公钥必须向接受者信任的人(身份认证机构)来注册。注册后身份认证机构给使用者发一数字证书。对文件签名后，使用者把此数字证书连同文件及签名一起发给接受者，接受者向身份认证机构求证是否真地是用使用者的密钥签发的文件。

信息发布者可以使用数字签名，信息发布的目的是让人们知道信息，虽然没必要对消息进行加密，但是必须排除有人伪装信息发布者发布假消息的风险，这时信息发布者就可以使用数字签名。而对明文消息施加的签名，称为明文签名(clearsign)。软件的作者可以加上数字签名，以便用户下载后对签名进行验证。**认证机构****(CA)****也可以为用户的公钥加上数字签名生成证书，以便人们确认用户公钥的合法性**。SSL/TLS使用服务器证书(加上了数字签名的服务器公钥)认证服务器身份是否合法。

通常我们使用公钥加密，用私钥解密。而在数字签名中，我们使用私钥加密(相当于生成签名)，公钥解密(相当于验证签名)。我们可以直接对消息进行签名(即使用私钥加密，此时加密的目的是为了签名，而不是保密)，验证者用公钥正确解密消息，如果和原消息一致，则验证签名成功。但通常我们会对消息的散列值签名，因为通常散列值的长度远小于消息原文，使得签名(非对称加密)的效率大大提高。注意，计算消息的散列值不是数字签名的必要步骤。在实际使用中，我们既想加密消息，又想签名，所以要对加密和签名组合使用，比如TLS就组合了加密和签名。数字签名应用了公钥密码领域使用的单向函数原理。单向函数指的是正向操作非常简单，而逆向操作非常困难的函数，比如大整数乘法。**一般签名对象为消息的散列值**。

4. **公开密钥认证(public key certificate****，或公钥证书)****，又称数字证书(digital certificate)****或身份证书(identity certificate)**：是用于公开密钥基础建设的电子文件，**用来证明公开密钥拥有者的身份**。此文件包含了公钥信息、拥有者身份信息(主体)、以及数字证书认证机构(发行者)对这份文件的数字签名，以保证这个文件的整体内容正确无误。拥有者凭着此文件，可向电脑系统或其他用户表明身份，从而对方获得信任并授权访问或使用某些敏感的电脑服务。电脑系统或其他用户可以透过一定的程序核实证书上的内容，包括证书有否过期、数字签名是否有效，如果你信任签发的机构，就可以信任证书上的密钥，凭公钥加密与拥有者进行可靠的通信。简而言之，认证机构用自己的私钥对需要认证的人(或组织机构)的公钥施加数字签名并生成证书，即**证书的本质就是对公钥施加数字签名**。数字证书的其中一个最主要好处是在认证拥有者身份期间，拥有者的敏感个人数据(如出生日期、身份证号码等)并不会传输至索取数据者的电脑系统上。透过这种数据交换模式，拥有者既可证实自己的身份，亦不用过度披露个人数据，对保障电脑服务访问双方皆有好处。人们透过信任数字证书认证机构的根证书、及其使用公开密钥加密作数字签名核发的公开密钥认证，形成信任链架构，已在TLS实现并在万维网的HTTPS、在电子邮件的SMTPS和STARTTLS广泛应用。业界现行的标准是国际电信联盟电信标准化部门制定的X.509，并由IETF发行的RFC 5280详细述明。

**证书种类**：根证书(自签证书)、中介证书和终端实体(TLS服务器/客户端)证书的关系，如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg_size_16_color_FFFFFF_t_70 2][]

(1).自签证书：在用于小范围测试等目的的时候，用户也可以自己生成数字证书，但没有任何可信赖的人签名，这种自签名证书通常不会被广泛信任，使用时可能会遇到电脑软件的安全警告。

(2).**根证书：获得广泛认可，通常已预先安装在各种软件**(包括操作系统、浏览器、电邮软件等)，**作为信任链的起点**，来自于公认可靠的政府机关、软件公司、证书颁发机构公司等，与各大软件商透过严谨的核认程序才在不同的软件广泛部署。由于部署程序复杂费时，需要行政人员的授权及机构法人身份的核认，一张根证书有效期可能长达十年以上。在某些企业，也可能会在内部电脑自行安装企业自签的根证书，以支持内部网的企业级软件；但是这些证书可能未被广泛认可，只在企业内部适用。

(3).中介证书(或中间证书)：认证机构的一个重要任务就是为客户签发证书，虽然广泛认可的认证机构都已拥有根证书，相对应的私钥可用以签署其他证书，但因为密钥管理和行政考虑，一般会先行签发中介证书，才为客户作数字签署。中介证书的有效期会较根证书为短，并可能对不同类别的客户有不同的中介证书作分工。

(4).授权证书：又称属性证书，本身没有公钥，必须依附在一张有效的数字证书上才有意义，其用处是赋予相关拥有人签发终端实体证书的权力；某些情况下，如果只在短期内授予证书机构签发权力，便可以不改变(缩短)该机构本身持有的证书的有效期。这种情况，类似于某人持有长达十年期的护照，而只透过签发短期入境签证，来个别赋予护照持有人额外权力。

(5).终端实体证书(或叶子证书)：其他不会用作签发其他证书的，都可称为终端实体证书，在实际的软件中部署，以便创建加密通道时应用。

(6).TLS服务器证书：服务器通常以域名形式在互联网上提供服务，服务器证书上主体的通用名称就会是相应的域名，相关机构名称则写在组织或单位一栏上。服务器证书(包括公钥)和私钥会安装于服务器，等待客户端连接时协议加密细节。客户端的软件(如浏览器)会运行认证路径验证算法以确保安全，如果未能肯定加密通道是否安全(例如证书上的主体名称不对应网站域名、服务器使用了自签证书、或加密算法不够强)，可能会警告用户。

(7).通配符证书：如果服务器证书上主体的通用名称(或主体别名)一栏以通配符前缀，则该证书可以用于旗下的所有子域名，特别适合较具规模、或设有多个子网站的机构一次过申领，套用于多个服务器上；即使未来创建新的子域名，也可以套用。但通配符不可用于扩展认证证书上。

(8).TLS客户端证书：有时候，某些TLS服务器可能会在创建加密通道时，要求客户端提供客户端证书，以验证身份及控制访问权限。客户端证书包含电子邮件地址或个人姓名，而不是主机名。但客户端证书比较不常见，因为考虑到技术门槛及成本因素，通常都是由服务提供者验证客户身份，而不是依赖第三方认证机构。通常，需要使用到客户端证书的服务都是内部网的企业级软件，他们会设立自己的内部根证书，由企业的技术人员在企业内部的电脑安装相关客户端证书以便使用。在公开的互联网，大多数网站都是使用登录密码和Cookie来验证用户，而不是客户端证书。客户端证书在RPC系统中更常见，用于验证连接设备的许可授权。

**证书申领**：(1).鲍伯在自己的机器上使用密码学安全伪随机数生成器产生一对足够强的密钥，鲍伯的私钥不会向任何人发送。(2).鲍伯把他的公钥，连同主体消息、使用目的等组成证书签署请求，发送给认证机构伊凡。(3).伊凡(用另外一些渠道)核实鲍伯的身份。(4).如果伊凡信任这个请求，他便使用鲍伯的公钥和主体消息，加上证书有效期、用途等限制条件，组成证书的基本数据。(5).伊凡用自己的私钥对鲍勃的公钥加上数字签名并生成证书。(6).伊凡把生成的证书发送给鲍伯(伊凡也可以透过证书透明度公布他签发了新的证书)。

证书使用：(1).鲍伯可以随便把证书向外发布。(2).鲍伯与爱丽丝事先可能互不认识，但鲍伯与爱丽丝都信任伊凡，爱丽丝使用认证机构伊凡的公钥验证数字签名，如果验证成功，便可以信任鲍勃的公钥是真正属于鲍伯的。(3).爱丽丝可以使用证书上的鲍勃的公钥加密明文，得到密文并发送给鲍伯。(4).鲍伯可以可以用自己的私钥把密文解密，得到明文。

电子证书可以二进制或Base64形式存储，常见的文件扩展名有.cer、.crt、.der和.pem。如果把证书和私钥一起存储，则可以使用PKCS\#12(.p12)格式。

5. **X.509**：ITU-T推荐标准X.509是X.500推荐标准系列的一部分，X.500系列推荐标准定义了一套目录服务。所谓目录服务，实际上是指用于维护用户信息数据库的一个或一组分布式服务器。这些信息包括从用户名到网络地址的映射关系，以及其他关于用户的属性和信息。**X.509****定义了一个使用X.500****目录向用户提供认证服务的框架**。该目录可以作为公钥证书存储库。每个证书都包括用户的公钥，并由一个可信任的认证中心用私钥签名。除此之外，X.509定义了另一个基于使用公钥证书的认证协议。

**X.509****是密码学里公钥证书的格式标准**。X.509证书已应用在包括TLS/SSL在内的众多网络协议里。X.509证书里含有公钥、身份信息(比如网络主机名，组织的名称或个体名称等)和签名信息(可以是证书签发机构CA的签名，也可以是自签名)。对于一份经由可信的证书签发机构签名或者可以通过其它方式验证的证书，证书的拥有者就可以用证书及相应的私钥来创建安全的通信，对文档进行数字签名。除了证书本身功能，X.509还附带了证书吊销列表和用于从最终对证书进行签名的证书签发机构直到最终可信点为止的证书合法性验证算法。X.509是ITU-T标准化部门基于他们之前的ASN.1定义的一套证书标准。

X.509基于公钥加密体制和数字签名的使用。这个标准并没有强制使用某个特定的算法，但是推荐使用RSA。数字签名方案假定需要使用散列函数。同样，这个标准也没有强制使用某种特定的散列算法。

X.509方案的核心是与每个用户相关联的公钥证书。这些用户证书是由可信任的认证中心(CA)创建的，并由CA或用户放在目录中。目录服务器本身不负责公钥的产生和认证功能，它只为用户获取证书提供一个容易访问的场所。

**浏览器(****如Firefox****、Internet Explorer****、Microsoft Edge****、Safari****以及Google Chrome)****和操作系统都预装有可信任的根证书列表，所以主流CA****发布的TLS****证书都直接可以正常使用**。

**证书文件扩展名**：X.509有多种常用的扩展名，不过其中的一些还用于其它用途，就是说具有这个扩展名的文件可能并不是证书，比如说可能只是保存了私钥。

(1).pem：DER编码的证书再进行Base64编码的数据存放在"-----BEGIN CERTIFICATE-----"和"-----END CERTIFICATE-----"之中。

(2).cer, .crt, .der：通常是DER二进制格式的，但Base64编码后也很常见。

(3).p7b, .p7c：PKCS\#7 SignedData structure without data, just certificate(s) or CRL(s)。

(4).p12：PKCS\#12格式，包含证书的同时可能还有带密码保护的私钥。

(5).pfx：PFX，PKCS\#12之前的格式(通常用PKCS\#12格式，比如那些由IIS产生的PFX文件)。

PKCS\#7是签名或加密数据的格式标准，官方称之为容器。由于证书是可验真的签名数据，所以可以用SignedData结构表述。.P7C文件是退化的SignedData结构，没有包括签名的数据。

PKCS\#12由PFX进化而来的用于交换公共的和私有的对象的标准格式。

**证书的一般结构**包含以下要素，如下图所示：一般遵从X.509格式规范的证书，会有以下的内容，它们以字段的方式表示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg_size_16_color_FFFFFF_t_70 3][]

(1).版本：区别连续版本中的证书格式，默认为版本1；如果证书中有发放者唯一标识符或者主体唯一标识符，则说明此值一定为2；如果存在一个或多个扩展，则此值一定为3。现行通用版本是3。

(2).序号：一个整数值，此值在发放证书的CA中唯一，且明确与此证书相关联。

(3).签名算法标识符：用于进行签名证书的算法和一切有关的参数。由于此信息在证书末尾的签名域中被重复，此域基本没有用处。

(4).发放者名称：创建和签发该证书的CA的X.500名称。

(5).有效期：包括两个日期：证书有效的最初日期和最晚日期。

(6).主体名称：此证书指向用户的名称。也就是说，此证书核实拥有相关私钥的主体的公钥。

(7).主体公钥信息：主体的公钥，加上一个表明此公钥用于何种加密算法的标识和任何相关参数。

(8).发放者唯一标识符：一个可选的比特串域，在X.500名称被重用于不同实体中的情况下，它用来唯一地确定发放证书的CA。

(9).主体唯一标识符：一个可选的比特串域，在X.500名称被重用于不同实体中的情况下，它用来唯一地确定主体。

(10).扩展：一个和多个扩展域组成的集合。在版本3中加入扩展。

(11).签名：包括此证书的一切其他的域。它包含用CA的私钥加密过的其他域的散列码。此域包含签名算法标识符。

6. **认证中心**(Certificate Authority , CA)：数字证书认证机构，也称为电子商务认证中心、电子商务认证授权机构，是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

CA中心为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。CA机构的数字签名使得攻击者不能伪造和篡改证书。它负责产生、分配并管理所有参与网上交易的个体所需的数字证书，因此是安全电子交易的核心环节。在SET交易中，CA不仅对持卡人、商户发放证书，还要对获款的银行、网关发放证书。CA是证书的签发机构，它是PKI(Public Key Infrastructure)的核心。CA是负责签发证书、认证证书、管理已颁发证书的机关。它要制定政策和具体步骤来验证、识别用户身份，并对用户证书进行签名，以确保证书持有者的身份和公钥的拥有权。用户若欲获取证书，应先向CA提出申请，CA判明申请者的身份后，为之分配一个公钥，并将该公钥与其身份信息绑定，为该整体签名，签名后的整体即为证书，发还给申请者。如果一个用户想鉴别另一个证书的真伪，他就用CA的公钥对那个证书上的签字进行验证，一旦验证通过，该证书就被认为是有效的。

7. **SSL/TLS**：Secure Sockets Layer/ Transport Layer Security(安全套接层/传输层安全性协议)，是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。TLS的前身是SSL。网景公司(Netscape)在1994年推出HTTPS协议，以SSL进行加密，这是SSL的起源。IETF将SSL进行标准化，1999年公布TLS 1.0标准文件(RFC 2246)。随后又公布TLS 1.1(RFC 4346, 2006年)、TLS 1.2(RFC 5246, 2008年)和TLS 1.3(RFC 8446, 2018年)。目前已成为互联网上保密通信的工业标准。

SSL包含记录层(Record Layer)和传输层，记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证，之后利用非对称加密演算来对通信方做身份认证，之后交换对称密钥作为会谈密钥(Session key)。这个会谈密钥是用来将通信两方交换的数据做加密，保证两个应用间通信的保密性和可靠性，使客户与服务器应用之间的通信不被攻击者窃听。

TLS协议采用主从式架构模型，用于在两个应用程序间透过网络创建起安全的连线，防止在交换数据时受到窃听及篡改。TLS协议的优势是与高层的应用层协议(如HTTP、FTP、Telnet等)无耦合。应用层协议能透明地运行在TLS协议之上，由TLS协议进行创建加密信道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密，从而保证通信的私密性。

TLS协议是可选的，必须配置客户端和服务器才能使用。主要有两种方式实现这一目标：一个是使用统一的TLS协议端口(例如：用于HTTPS的端口443)；另一个是客户端请求服务器连接到TLS时使用特定的协议机制(例如：电子邮件常用的STARTTLS)。一旦客户端和服务器都同意使用TLS协议，他们通过使用一个握手过程协商出一个有状态的连接以传输数据。**通过握手，客户端和服务器协商各种参数用于创建安全连接**。

**在客户端和服务器开始交换TLS****所保护的加密信息之前，他们必须安全地交换或协定加密密钥和加密数据时要使用的密码**。用于密钥交换的方法包括：使用RSA算法生成公钥和私钥(在TLS握手协议中被称为TLS\_RSA)、Diffie-Hellman(在TLS握手协议中被称为TLS\_DH)、临时Diffie-Hellman(在TLS握手协议中被称为TLS\_DHE)、椭圆曲线迪菲-赫尔曼(在TLS握手协议中被称为TLS\_ECDH)、临时椭圆曲线Diffie-Hellman(在TLS握手协议中被称为TLS\_ECDHE)、匿名Diffie-Hellman(在TLS握手协议中被称为TLS\_DH\_anon)和预共享密钥(在TLS握手协议中被称为TLS\_PSK)。在交换过程中使用的公钥/私钥加密密钥的长度和在交换协议过程中使用的公钥证书也各不相同，因而提供强健性安全。

SSL使用TCP提供一种可靠的端对端的安全服务。SSL不是单个协议，它由两层协议组成，如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg_size_16_color_FFFFFF_t_70 4][]

SSL记录协议对各种更高层协议提供基本的安全服务。尤其是，超文本传输协议(Hypertext Transfer Protocol, HTTP)是为Web客户端/服务器的交互提供传输服务的协议，它可以在SSL的顶层运行。SSL中定义的三个较高层协议分别是：握手协议、修改密码规范协议和警报协议。这些SSL协议规范用来管理SSL的交换。

SSL协议中的两个重要概念是SSL会话和SSL连接，按照规范文件，它们的定义如下：

(1).连接：是一种能够提供合适服务类型(按照OSI分层模型定义)的传输。对SSL来说，这种连接是点对点的关系而且都是短暂的。每一条连接都与一个会话相关联。

(2).会话：SSL会话是客户与服务器之间的一种关联。**会话是通过握手协议来创建的**。所有会话都定义了密码安全参数集合，这些参数可以在多个安全连接之间共享。会话通常用来减少每次连接建立安全参数的昂贵协商费用。

会话状态由下列参数定义：

(1).会话标识符：由服务器产生的用于标识活动或可恢复的会话状态的一个任意字节序列。

(2).对等实体证书：对等实体的X.509v3证书。会话状态的这一元素可以为空。

(3).压缩方法：加密前用于压缩数据的算法。

(4).密码规格：包括大块数据加密算法(例如空算法、AES算法等)规格和用于计算MAC(消息认证码)的散列算法(如MD5或SHA-1算法等)规格。它还定义了一些密码属性，例如散列值长度等。

(5).主密钥：客户端和服务器共享的48字节的会话密钥。

(6).可恢复性：表明会话是否可被用于初始化新连接的标志。

连接状态由下列参数定义：

(1).服务器和客户端随机数：由服务器和客户端为每个连接选定的字节串。

(2).服务器写MAC密钥：服务器发送数据时用于计算MAC值的密钥。

(3).客户端写MAC密钥：客户端发送数据时用于计算MAC值的密钥。

(4).服务器写密钥：服务器用于加密数据、客户端用于解密数据的加密密钥。

(5).客户端写密钥：客户端用于加密数据、服务器用于解密数据的对称加密密钥。

(6).初始化向量：在CBC模式中，需要为每个密钥配置一个初始化向量(IV)。最初的IV值由SSL的握手协议初始化。之后，每个记录的最后一个密码块被保存，以作为后续记录的IV。

(7).序列号：建立连接的各方为每条连接发送和接收的消息维护单独的序列号。当一方发送或接收改变密码规格的消息时，相应的序列号应置零。序列号的值不能超过2^64-1。

**SSL****握手协议**：这一协议允许客户端和服务器相互认证，并协商加密和MAC算法，以及用于保护数据使用的密钥通过SSL记录传送。**握手协议在任何应用数据被传输之前使用。握手协议由客户端和服务器之间的一系列消息交换组成**。

下图说明了为建立客户端和服务器之间的逻辑连接需要进行的初始交换。这些交换可分为4个阶段：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg_size_16_color_FFFFFF_t_70 5][]

第一阶段：客户端发起建立连接请求：这一阶段主要是发起逻辑连接并建立与之关联的安全能力。交换首先由客户端通过发送下列client\_hello消息启动：

(1).版本：客户端的SSL最高版本。

(2).随机数：由客户端产生的随机序列，由32比特时间戳以及安全随机数生成器产生的28字节随机数组成。这些数没有任何意义，主要用于密钥交换过程中防止重放攻击。

(3).会话ID：可变长度的会话标识符。非零值表示客户端希望更新现有连接的参数，或为该会话创建一条新连接。零值表示客户端希望在新会话上建立一条新连接。

(4).密码套件：按优先级的降序排列的、客户端支持的密码算法列表。列表中的每一行(即每一个密码套件)同时定义了密钥交换算法和密码规格。

(5).压缩方法：客户端支持的压缩方法列表。

发送完client\_hello消息后，客户端将等待server\_hello消息，该消息所包含的参数与client\_hello消息包含的参数相同。同时server\_hello消息遵循以下的惯例。版本域包含客户端支持的较低版本和服务器支持的最高版本。服务器产生一个独立于客户端随机域的新随机数域。如果客户端会话ID域的值非零，那么服务器应采用相同的取值。否则，服务器的会话ID域将包括一个新会话值。密码套件域将包括服务器从客户端提供的可选方案中选定的唯一一组密码套件。压缩域包括服务器从客户端建议中选定的压缩方法。密码套件参数的第一项内容是密钥交换方法(如传统加密密钥和MAC交换方法)。

第二阶段：服务器认证和密钥交换：如果需要认证，则这一阶段的开始以服务器发送其证书为标志。发送的消息包括一个X.509证书或一个X.509证书链。之后，如果有必要，将发送一个服务器密钥交换(server\_key\_exchange)消息。接下来，服务器可以向客户端请求证书。certificate\_request(证书请求)消息包括两个参数：certificate\_type(证书类型)和certificate\_authorities(证书机构)。证书类型指出了公钥算法及其用法。第二阶段中的最后一条消息(也是始终需要存在的消息之一)是server\_done(服务器结束)消息。该消息由服务器发出并示意服务器的hello及相关消息已经结束。该消息没有参数，发送完这个消息后，服务器要等待客户的响应。

第三阶段：客户端认证和密钥交换：接收到server\_done(服务器结束)消息后，如果需要，客户端应该验证服务器提供的证书是否有效，同时还要检查server\_hello参数是否是可接受的。如果所有这些条件均满足，那么客户端将返回一条或更多消息给服务器。如果服务器已请求证书，则以客户端发送一条certificate消息为这一阶段的开始。如果没有合适的证书可用，那么客户端发送一个no\_ceritificate alert(无证书警报)。接下来是client\_key\_exchange(客户端密钥交换)消息。该消息必须在这一阶段发送，消息内容由密钥交换类型决定。最后，在这一阶段，客户端可以发送certificate\_verify(证书验证)消息，以便对客户端证书进行显示验证。仅当客户端证书具有签名功能时才会发送该消息。这个消息是对一个散列码的签名，该散列码基于前面的消息。

第四阶段：完成：这一阶段完成安全连接的建立。客户端发送一个change\_cipher\_spec(修改密码规格)消息，并把挂起的密码规格复制到当前密码规格中。值得注意的是，该消息不是握手协议的一部分，而是使用修改密码规格协议发送的。客户端在新算法、新密钥和新秘密值下立即发送finished(结束)消息。finished消息用于验证密钥交换和认证过程是否成功。作为对客户发送的这两条消息的响应，服务器发送自己的change\_cipher\_spec\_message(修改密码规格消息)，把未定的密码规格转变为当前的密码规格并发送其finished消息。到此为止握手过程已经完成，客户端与服务器可以开始交换应用层数据。

了解了上面一些术语后，接下来介绍下SSL/TLS的单向认证和双向认证过程，其实就是握手协议。单向认证如通过浏览器访问某个网站，双向认证如使用U盾登入网上银行，需客户端和服务器相互认证。除认证外，还要协商加密和MAC算法，以及用于保护数据使用的密钥。由客户端和服务器之间的一系列消息组成。

假设ca.crt为CA的证书，server.crt为服务器证书，client.crt为客户端证书，server.key为服务器私钥，client.key为客户端私钥，server.pub为服务器公钥，client.pub为客户端公钥。ca.crt应该已默认存在于客户端。

1. SSL/TLS单向认证过程：

(1).客户端发起连接请求：请求消息包括客户端支持的最高SSL协议、客户端支持的密码套件列表、客户端支持的压缩算法列表、随机数、会话ID等信息。

(2).服务器返回消息：该消息所包含的参数与(1)中相同，包括客户端支持的SSL协议较低版本和服务器支持的最高版本；服务器从客户端提供的可选方案中选定的唯一一组密码套件(协议支持的密钥交换方法包括RSA，固定Diffie-Hellman等，密码规格包括密码算法如RC4等，MAC算法如MD5、SHA-1等)；服务器从客户端提供的可选方案中选定的压缩算法；随机数等信息；同时返回消息中还包括服务器证书server.crt，此证书里有服务器公钥和签名，它是一个X.509证书或一个X.509证书链。

(3).客户端通过本地的ca.crt验证server.crt的合法性：证书是否过期、通过ca.crt获取server.crt中的公钥、验证此公钥是否能正确解开server.crt中的数字签名、证书上的域名是否和服务器的实际域名相匹配。验证通过后继续通信，否则终止通信。

(4).客户端向服务发送自己支持的对称加密算法列表，供服务器进行选择。

(5).服务器在客户端提供的加密方案中选择加密程度最高的加密算法，并将选定好的加密方案通过明文方式返回给客户端。

(6).客户端接收到服务器端返回的加密方案后，生成随机码，用作通信过程中对称加密的密钥，使用服务器端的公钥进行加密，将加密后的随机码发送至服务器。

(7).服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥。

在接下来的数据传输中，服务器和客户端将会使用该密钥进行对称加密，保证通信过程中的信息安全。

2. SSL/TLS双向认证过程：

(1).客户端发起连接请求：请求消息包括客户端支持的最高SSL协议、客户端支持的密码套件列表、客户端支持的压缩算法列表、随机数、会话ID等信息。

(4).客户端向服务器发送client.crt，还包括客户端支持的对称加密算法列表，供服务器进行选择。

(5).服务器验证client.crt，验证通过后会获取到客户端公钥，否则拒绝连接；服务器在客户端提供的加密方案中选择加密程度最高的加密算法，并将选定好的加密方案通过客户端公钥加密后返回给客户端。

(6).客户端接收到服务器返回的加密方案后，使用客户端私钥进行解密，生成随机码，用作通信过程中对称加密的密钥，使用服务器的公钥进行加密，将加密后的随机码发送至服务器。

(7).服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥。

在接下来的数据传输中，服务器和客户端将会使用该密钥进行对称加密，保证通信过程中的信息安全。

注：以上内容来自网络整理，主要参考：

1. 《网络安全基础应用与标准》

2. 维基百科：[散列函数][Link 1]  [数字签名][Link 2]  [数字证书][Link 3]  [TLS][]

**GitHub**：[https://github.com//fengbingchun/OpenSSL\_Test][https_github.com_fengbingchun_OpenSSL_Test]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200619145415835.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200619145528965.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200619145626645.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/2020061914574011.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200619150037895.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20200619145846902.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlbmdiaW5nY2h1bg==,size_16,color_FFFFFF,t_70
[Link 1]: https://zh.wikipedia.org/wiki/%E6%95%A3%E5%88%97%E5%87%BD%E6%95%B8
[Link 2]: https://zh.wikipedia.org/wiki/%E6%95%B8%E4%BD%8D%E7%B0%BD%E7%AB%A0
[Link 3]: https://zh.wikipedia.org/wiki/%E5%85%AC%E9%96%8B%E9%87%91%E9%91%B0%E8%AA%8D%E8%AD%89
[TLS]: https://zh.wikipedia.org/wiki/%E5%82%B3%E8%BC%B8%E5%B1%A4%E5%AE%89%E5%85%A8%E6%80%A7%E5%8D%94%E5%AE%9A
[https_github.com_fengbingchun_OpenSSL_Test]: https://github.com//fengbingchun/OpenSSL_Test