全部博文（695）
分类： 网络与安全
2016-06-07 16:56:16
TSL的身份认证和密钥协商大致过程如下（下面只考虑新建会话的情况，而不考虑重启存在会话的情况）：
Step1：客户端往服务器端发ClientHello消息
消息特点：该消息是客户端连接服务器端时发送的第一个消息。
消息构成：
(1). 使用的TLS协议版本。
(2). 随机数；用于计算对称加密时的“主密码”。
(3). 会话ID；重连时有用，可为空。
(4). 加密算法列表；客户端支持的加密算法列表，并按照客户端的偏好从前往后排。
(5). 压缩算法列表；客户端支持的压缩算法列表，并按照客户端的偏好从前往后排。
(6). 扩展信息。
消息作用：用于发起会话、交换随机数、协商加密算法、压缩算法等。
Step2：服务器端验证ClientHello消息，主要验证：
(1) 消息格式是否合法；
(2) 能否至少支持客户端所列举的一个加密算法和一个压缩算法等。
验证不通过则发送消息断开会话，验证通过则执行下一步。
Step3：服务器往客户端发送ServerHello消息。
消息特点：该消息是服务器收到ClientHello后返回给客户端的第一个消息。
消息构成：
(1). 使用的TLS协议版本。
(2). 随机数；用于计算对称加密时的“主密码”(这个随机数是服务器发送给客户端的,跟第一步骤的随机数不同,第一个是客户端发送给服务的)
(3). 一个加密算法；服务器从客户端的加密算法列表中选中的一个加密算法。
(4). 一个压缩算法；服务器从客户端的压缩算法列表中选中的一个压缩算法。
(5). 会话ID；新建的唯一的会话ID。
(6). 扩展信息。
消息作用：用于交换随机数、确定加密算法、压缩算法等。
Step4：服务器往客户端发送Certificate消息。
消息特点：该消息必须在ServerHello发送完后立即发送。如果是匿名协商，则无须发该消息。
消息构成：
(1). 证书列表；服务器的证书必须为证书列表的第一个，其后为签发服务器证书的证书，依次类推，最后一个证书为根证书签署的证书。根证书不在证书列表中，它是通过其他途径给到客户端的。(好多时候是浏览器预装好的)
消息作用：发送服务器证书，或者证书链。
Step5：服务器往客户端发送ServerKeyExchange消息。
消息特点：
(1). 该消息必须在Certificate发送完后立即发送（如果是匿名协商，则该消息紧跟在ServerHello后）。
(2). 该消息只有当Certificate消息无法提供足够信息让客户端完成“预主密码”交换时才需要。
消息构成：
(1). 密钥交换算法
消息作用：该消息用于发送密钥交换算法给客户端。客户端可利用这些算法和服务器端完成“预主密码”的交换。
Step6：服务器往客户端发送CertificateRequest消息。
消息特点：
(1). 非匿名的服务器可通过该消息来要求客户端发送证书验证其身份。
(2). 如果发送该消息则该消息在ServerKeyExchange发送完后立即发送(如果该次交互不发送ServerKeyExchange，则该消息紧跟Certificate消息)
消息构成：
(1). 证书类型列表；客户端的证书类型必须是证书类型列表中一种。
(2). 签名和哈希算法列表；列举服务器所支持的签名算法和哈希算法。
(3). CA名字列表；服务器只接受的列表中所列出的CA所发行的证书，其他证书无法验证。
消息作用：请求客户端发送证书验证其身份。(只有双向认证才需要,即服务器也需要认证客户端)
Step7：服务器往客户端发送ServerHelloDone消息。
消息特点：
消息构成：
(1). 无消息内容。
消息作用：该消息用来告诉客户端ServerHello以及附属消息都已发送完毕。发完该消息后服务器等待客户端消息。
Step8：客户端往服务器端发送ClientCertificate消息。
消息特点：
(1). 该消息仅当收到服务器CertificateRequest时才发送，即服务器要求验证客户端。
(2). 如果发送该消息，则该消息必须是客户端收到ServerHelloDone消息后发往服务器的第一个消息。
消息构成：
(1). 证书列表。
消息作用：发送客户端证书让服务器认证。(只有双向认证才需要,即服务器也需要认证客户端)
Step9：客户端往服务器端发送ClientKeyExchange消息。
消息特点：
(1). 如果有ClientCertificate消息，则该消息必须紧跟其后发送；如果无ClientCertificate消息，则该消息是收到ServerHelloDone消息后发往服务器的第一个消息。
(2). 消息用RSA算法或者 Diffie-Hellman参数来协商预主密码。
(3). 采用RAS加密的协商预主密码时，先生成一个长的随机数，由该随机数和客户端的TSL版本号构成一个结构体，用服务器证书的公钥（从服务器证书获得）对结构体进行加密，并把加密后的数据发给服务器。
(4). Diffie-Hellman参数协商比较复杂，暂不讨论。
消息构成：因加密算法而异。
消息作用：协商预主密码
Step10：客户端往服务器端发送CertificateVerify消息。
消息特点：
(1). 该消息只有当客户端证书有签名能力时(Tenfy:即有客户端证书，且证书是公钥和私钥都有的)发送，其它情况不发送（不含固定Diffie-Hellman参数的证书都有签名能力）。
(2). 该消息必须在ClientKeyExchange发送完后立即发送。
(3). 该消息采用客户端证书中的私钥信息进行加密。
消息构成：
(1). 把该消息之前的所有消息作为参数，用私钥对其进行签名得出一份数据，该数据即为消息体。
消息作用：通过签名方式，验证客户端身份。
Step 11：服务器用服务器私钥解密ClientKeyExchange消息得 “预主密码”。服务器和客户端用相同的算法计算“主密码”。主密码计算是根据预主密码、ClientHello中的随机数、ServerHello中的随机数得到的。计算好主密码后双方各向对方发送一个ChangeCipherSpec消息：
消息特点：
(1). 该消息必须在所有握手消息发送完之后，在Finished消息发送之前发送。
(2). 该消息必须在接收完所有握手消息之后，在接收Finished消息之前收到。
消息构成：
(1). 确认消息。
消息作用：确认采用刚才协商好的压缩算法、加密算法、主密码等来传输后继数据。
Step12：任意一方收到ChangeCipherSpec消息后告诉自己的Record Layer由读等待状态转为读状态，并采用新方式来传递数据。并往另外一端往发送Finished消息。
消息特点：
(1). 该消息是收到ChangeCipherSpec后立即发送的。
(2). 该消息是首次采用刚才协商好的压缩算法、加密算法、主密码等来传输的数据。
消息构成：
(1). 把前面大部分的握手消息作为参数，用相同的算法计算得到的一个值。
消息作用：完成压缩算法、加密算法等的协商，开始转入应用层数据传输。
Step13：双方验证收到的消息，验证通过则开始应用层数据传输，否则断开。
TSL通讯时分为单向认证和双向认证。单向认证时只需要服务器端拥有证书（公钥是证书的一部分）和私钥，其中证书公开，私钥自己保管；双向加密时需要服务器和客户端都提供证书和私钥，证书都公开，私钥都自己保管。这两个对证书、私钥对无必然联系，实际编程时把它们作为两对独立的证书、私钥对来处理。
单向认证时，服务器端不会验证客户证书。故服务器无须发送CertificateRequest消息请求客户端证书，客户端无须发与证书相关的ClientCertificate和CertificateVerify消息。
通讯过程中必须严格按上述说明来发送和接收消息。接收方接收消息后一旦发现：(1)消息遗漏，(2) 消息次序不对，(3) 消息格式（如加密格式）有误，(4) 消息内容有误，(5) 自身致命错误等，接收方立即通过Alert Protocol往发送方发送ErrorAlert消息，告诉对方终止此次会话。如果是能容忍的错误，则不发任何消息，以免对方主动断开会话。
若干重要验证说明：
1. 客户端验证服务器的Certificate消息。主要验证内容为：
(1). 服务器证书使用日期是否有效。
(2). 发行服务器证书的CA是否可靠。
(3). 发行者的公钥能否解开服务器证书上的“发行者数字签名”。
(4). 服务器证书上的名称（如域名）是否和服务器实际名称匹配等（PHP中可以选择是否验证该选项）。
(Tenfy: 这里可以看出,客户端验证服务的时候,只需要验证对应服务器证书的有效性即可,无需验证对应服务器是否拥有跟该证书一致的私钥)
2. 服务器验证客户端的CertificateVerify消息。主要验证内容为：
(1). 用客户端公钥能否解开客户端私钥加密的消息。
(Tenfy:服务器验证客户端时候，还需要验证是否拥有跟证书对应的私钥)
3. 服务器验证客户端的ClientCertificate消息。主要验证内容为：
(1). 客户的证书使用日期是否有效。
(2). 为客户提供证书的CA 是否可靠。
(3). 发行CA 的公钥能否正确解开客户证书的发行CA的数字签名。
(4). 检查客户的证书是否在证书废止列表（CRL）中。
Openssl使用PEM(RFC 1421－1424)文档格式。PEM全称是PrivacyEnhanced Mail，该标准定义了加密一个准备要发送邮件的标准。它的基本流程是这样的：
1、信息转换为ASCII码或其它编码方式；
2、使用对称算法加密转换了的邮件信息；
3、使用BASE64对加密后的邮件信息进行编码；
4、使用一些头定义对信息进行封装，这些头信息格式如下（不一定都需要，可选的）：
Proc-Type,4:ENCRYPTED
DEK-Info:cipher-name, ivec
其中，第一个头信息标注了该文件是否进行了加密，该头信息可能的值包括ENCRYPTED(信息已经加密和签名)、MIC-ONLY(信息经过数字 签名但没有加密)、MIC-CLEAR(信息经过数字签名但是没有加密、也没有进行编码，可使用非PEM格式阅读)以及CLEAR(信息没有签名和加密并 且没有进行编码，该项好象是openssl自身的扩展，但是并没有真正实现)；；第二个头信息标注了加密的算法以及使用的ivec参量，ivec其实在这 儿提供的应该是一个随机产生的数据序列，与块加密算法中要使用到的初始化变量（IV）不一样。
5、在这些信息的前面加上如下形式头标注信息：
-----BEGINPRIVACY-ENHANCED MESSAGE-----
在这些信息的后面加上如下形式尾标注信息：
-----ENDPRIVACY-ENHANCED MESSAGE-----
上面是openssl的PEM文件的基本结构，需要注意的是，Openssl并没有实现PEM的全部标准，它只是对openssl中需要使用的一些选项做了实现，详细的PEM格式，请参考RFC1421－1424。
The Public-KeyCryptography Standards (PKCS)是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签 名、数字信封的格式等方面的一系列相关协议。
PFX（Personal Information Exchange）证书文件是采用PKCS(The Public-KeyCryptography Standards)标准生成的证书。PKCS是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废 表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。
PFX文件通常包含一个证书和与之对应的私钥，现阶段证书采用PKCS #12 标准[14]。这类文件是高度敏感的，在导出密钥对时，Windows 提供用密码加密 .pfx 文件；而在导入密钥对时，您必须再次提供此密码方可导入。
扩展名为 .cer 的文件采用 X.509v3 格式ASN.1 ，并由CA签名。这些文件中包含着一个公钥和额外的信息。这些文件一般用来提供给业务合作伙伴，以便他们能够使用公钥加密数据。
Java Key Store（JKS）是Java语言中给出的一种密码保护的文件，可存储密钥和证书。JKS文件好比一个仓库，为防范别人随便乱拿，仓库可以设置一把锁， 即JKS文件的密码（storepass）。仓库里可存放多种密钥，如公钥、私钥和密钥对（由配对公钥和私钥组成）。每个密钥都有一个名字，称为别名 （alias）。仓库里的公钥只要你能进入仓库你就可以随便查看拿走，私钥则是有密码的（keypass），只允许有权限的人查看拿走。所以从JKS文件 中读取公钥只需要知道JKS文件（仓库）的密码即可，但读取私钥时则还必须有私钥的密码[1]。
