一、常用网络协议介绍
1.1 TCP协议
传输控制协议（TCP，Transmission ControlProtocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793 定义。TCP协议建立的是一种点到点的，一对一的可靠连接，与UDP相比以牺牲效率为代价换取高可靠性的服务。
socket是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。抽象并形成了几个最基本的函数接口。
一个 TCP 连接由四要素【源IP、源Port、目标IP、目标Port】唯一标识，也即 socket 由这四要素唯一确定；
一个 TCP 连接的建立也就是客户端、服务端创建了相对应的一对 socket，客户端和服务端之间的通信也就是这对 socket 间的通信。
1.2 TLS/SSL协议
SSL握手协议(SSL Handshake Protocol) :它建立在SSL记录协议之上,用于在实际的数据传输开始前,通讯双方进行身份认证、协商加密算法、交换加密密钥等。
TLS: (Transport Layer Security,传输层安全协议),用于两个应用程序之间提供保密性和数据完整性。组成:该协议由TLS记录协议和TLS握手协议两层组成。TLS是在SSL的基础上标准化的产物,目前SSL3.0与TLS1.0保持一致的,二者是并列关系,只是习惯称呼SSL。
此处解说是基于tcp实现的openssl库中的tls1.2协议。
1.3 HTTPS协议
HTTPS 协议是由 HTTP 加上 TLS/SSL 协议构建的可进行加密传输、身份认证的网络协议，主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护。
Https可理解为http+TLS/SSL。
二、通讯原理分析
2.1 通讯原理
该图详细介绍了Tcp三次握手过程及SSL四次握手数据包传输。
2.1.1数字证书
2.1.1.1证书基本格式
证书格式分类分为2大类:密钥库(含私钥,也可能有公钥)和公银证书(仅含公钥),
2.1.1.2证书文件格式
常用证书文件格式
CA中心普遍采用的规范是X.509系列和PKCS系列,其中主要应用到了以下规范
2.1.1.2.1 X.509 (1993)
X.509是由国际电信联盟(ITU-T)制定的数字证书标准。在X.500确保用户名称惟一性的基础上,X.509为X.500用户名称提供了通信实体的鉴别机制,并规定了实体鉴别过程中广泛适用的证书语法和数据接口。
X.509的最初版本公布于1988年。X.509证书由用户公共密钥和用户标识符组成。此外还包括版本号、证书序列号、CA标识符、签名算法标识、签发看名称、证书有效期等信息。这一标准的最新版本是X.509 v3,它定义了包含扩展信息的数字证书。该版数字证书提供了一个扩展信息字段,用来提供更多的灵活性及特殊应用环境下所需的信息传送。
一个标准的X.509数字证书包含以下一些内容
证书的版本信息：
证书的序列号,每个证书都有一个唯一的证书序列号:
证书所使用的签名算法:
证书的发行机构名称,命名规则一般采用X.500格式:
证书的有效期,通用的证书一般采用UTC时间格式,它的计时范围为1950-2049:
证书所有人的名称,命名规则一般采用X.500格式:
证书所有人的公开:
证书发行看对证书的签名。
2.1.1.2.2 PKCS系列标准
PKCS是由美国RSA数据安全公司及其合作伙伴制定的一组公销密码学标准,其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。到1999年底,PKCS已经公布了以下标准:
PKCS#1:定义RSA公开密销算法加密和签名机制,主要用于组织PKCS#7中所描述的数字签名和数字信封。
PKCS#3:定义Diffie-Hellman密ิ交换协议。
PKCS#5:描述一种利用从口令派生出来的安全密钥加密字符串的方法。使用MD2或MD5从口令中派生密钥,并采用DES-CBC模式加密。主要用于加密从一个计算机传送到另一个计算机的私人密钥,不能用于加密消息。
PKCS#6:描述了公钥证书的标准语法,主要描述X.509证书的扩展格式。
PKCS#7:定义一种通用的消息语法,包括数字签名和加密等用于增强的加密机制,PKCS#7与PEM兼容,所以不需其他密码操作,就可以将加密的消息转换成PEM消息。
PKCS#8:描述私有密钥信息格式,该信息包括公开密钥算法的私有密钥以及可选的属性集等。
PKCS#9:定义一些用于PKCS#6证书扩展、PKCS#7数字签名和PKCS#8私钥加密信息的属性类型。
PKCS#10:描述证书请求语法。
PKCS#11:称为Cyptoki,定义了一套独立于技术的程序设计接口,用于智能卡和PCMCIA卡之类的加密设备。
PKCS#12:描述个人信息交换语法标准。描述了将用户公钥、私钥、证书和其他相关信息打包的语法。PKCS#13:圆曲线密码体制标准。PKCS#14:伪随机数生成标准。
PKCS#15:密码令牌信息格式标准。
2.1.1.2.3 数字证书文件格式(cer和pfx)的区别
1.带有私钥的证书
由Public Key Cryptography Standards #12（公钥密码学标准#12），PKCS#12标准定义，包含了公钥和私钥的二进制格式的证书形式，以pfx作为证书文件后缀名。
2.二进制编码的证书
证书中没有私钥，DER 编码二进制格式的证书文件，以cer作为证书文件后缀名。
3.Base64编码的证书
证书中没有私钥，BASE64 编码格式的证书文件，也是以cer作为证书文件后缀名。
由定义可以看出，只有pfx格式的数字证书是包含有私钥的，cer格式的数字证书里面只有公钥没有私钥。
2.1.1.3 数字证书认证的 具体流程
1.向第三方机构 CA 提交服务器公钥、组织信息、个人信息(域名)等信息并申请认证。（实际操作中，往往需要提供私钥，它会自动从私钥中提取公钥）
2.CA 通过多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等。如信息审核通过，CA 会向申请者签发认证文件-证书。
3.证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。 其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名。
4.客户端向服务端发出请求时，服务端返回证书文件。
5.客户端读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性。
6.客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任 CA 的证书信息(包含公钥)，如果 CA 不被信任，则找不到对应 CA 的证书，证书也会被判定非法。
2.1.2 TCP三次握手
2.1.2.1流程图分析
2.1.2.2报文解析
ACK(Acknowledgement Field Signigicant):确认号字段表示响应，该字段为1时表示应答字段有效，即TCP应答号将包含在TCP报文中。
SYN(Synchronize sequence numbers):同步序列号表示建立连接，用来发起一个连接请求。
URG(Urgent Pointer Field Significant):紧急指针标志，用来保证TCP连接不被中断，并且督促中间设备尽快处理这些数据。
PSH(Push Function): 推送功能表示有DATA数据传输，所谓推送功能指的是接收端在接收到数据后立即推送给应用程序，而不是在缓冲区中排队。
RST(Reset the connection): 重置连接，不过一般表示断开一个连接。
FIN(No more data from sender):表示发送端发送任务已经完成（既断开连接）。
*第一次握手数据包：*
客户端发送一个TCP，标志位为SYN，序列号为0， 代表客户端请求建立连接。
*第二次握手数据包：*
服务器发回确认包, 标志位为 SYN,ACK. 将确认序号(Acknowledgement Number)设置为客户的ISN加1
*第三次握手数据包：*
客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1
2.1.3 TLS/SSL四次握手
2.1.3.1流程图分析
2.1.3.2报文解析
*1.Client Hello*
握手第一步是客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件（Support Ciphers）和 SSL Version 等信息。
*加密套件构成*
由4个属性组成：
密钥交换算法：
RSA或Diffie-Hellman算法的各种变种
认证算法：
RSA, Diffie-Hellman, DSS 或none
加密算法：
AES, DES, Triple-DES, RC4, RC2, IDEA 或none
摘要算法：
MD5, SHA 或SHA1
如图：
*ssl版本迭代算法变动*
Tls1.3下SHA—1、SHA-224 、RC4、MD5、DES、3DES等算法均被剔除，取而代之的是ChaCha20, Poly1305, Ed25519, x25519, and x448等更为安全的算法。
*2.Server Hello*
第二步是服务端向客户端发送 Server Hello 消息，这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用哪些算法，另外还会生成一份随机数 Random2。注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。
*3.服务端证书Certificate*
这一步是服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证通过后取出证书中的公钥。
*4.Server Key Exchange*
服务器会在 server Certificate 消息之后发送 Server Key Exchange 消息，提供用于 ECDH 秘钥交换的信息。
*5.Certificate Request*
要求客户端提供证书，包括
（1） 客户端可以提供的证书类型
（2）服务器接受的证书distinguished name列表，可以是root CA或者subordinate CA。如果服务器配置了trust keystore, 这里会列出所有在trust keystore中的证书的distinguished name。
*6.Server Hello Done*
server hello结束
*7.客户端Certificate*
这一步是服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证通过后取出证书中的公钥。
*8.Client Key Exchange*
客户端收到服务端传来的证书后，先从 CA 验证该证书的合法性，验证通过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密 Random3 生成 PreMaster Key。
*9.Certificate Verify*
客户端收到服务端传来的证书后，先从 CA 验证该证书的合法性，验证通过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密 Random3 生成 PreMaster Key。
*10.Change Cipher Spec*
告诉服务器客户端已经计算好了共享秘钥，并且后续客户端发送给服务器的数据都将使用共享秘钥进行加密。在下一个版本的 TLS 中该数据包类型将会被移除，因为加密数据是可以通过数据类型推断的。
*11.Encrypted Handshake Message*
客户端将前面的握手消息生成摘要再用协商好的秘钥加密，这是客户端发出的第一条加密消息。服务端接收后会用秘钥解密，能解出来说明前面协商出来的秘钥是一致的。
*12.New Session Ticket*
新建会话凭证
*13.Change Cipher Spec*
进行验证，服务端使用相同的方式计算出共享秘钥 Pre Master Secret，由 ECDH 的特性以及前文的计算可以看到，服务端和客户端计算出的 PMS 是相同的，因衍生出来的对称加密秘钥、IV、MAC 秘钥也是相同的。
*14.Encrypted Handshake Message*
这个包表明握手已经完成,并且对之前发过的数据进行加密发送给对方做校验,防止被复改。同时也验证一下,加密算法、密钥工作是否正常。客户端使用之前握手过程中获得的服务器随机数、客户端随机数、Premaster secret计算生成会话密钥,然后使用该会话密钥加密之前所有收发握手消息的Hash和MAC值,发送给服务器。服务器将相同的会话密钥(使用相同方法生成)解密此消息,校验其中的Hash和MAC值。若客户端服务器都校验成功,握手阶段完成,双方将按照SSL记录协议的规范使用协商生成的会话密销加密发送数据。
*15.Encrypted Alert*
SSL 警告消息。通常只是用来提示服务端SSL 传输结束。
2.1.4单双向TLS报文区别
2.1.4.1单向TLS服务端、客户端
阶段列举：
Client Hello
Server Hello, Certificate, Server Key Exchange, Server Hello Done
Client Key Exchange,Change Cipher Spec, Encrypted Handshake Message
New Session Ticket, Change Cipher Spec, Encrypted Handshake Message
Application Data(加密数据)
Encrypted Alert
介绍：
1.客户端通过 HTTPS 协议向服务器请求一些受保护的数据。这将启动 SSL/TLS 握手过程。
2.服务器将其公共证书连同服务器问候消息一起返回给客户端。
3.客户端验证/验证收到的证书。客户端通过 CA 签名证书的证书颁发机构 (CA) 验证证书。
4.SSL/TLS 客户端发送随机字节串，使客户端和服务器都能计算出用于加密后续消息数据的密钥。随机字节串本身是用服务器的公钥加密的。
5.在同意此密钥后，客户端和服务器通过使用此密钥加密/解密数据进一步通信以进行实际数据传输。
2.1.4.2双向TLS服务端、客户端
阶段列举：
Client Hello
Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
New Session Ticket, Change Cipher Spec, Encrypted Handshake Message
Application Data(加密数据)
Encrypted Alert
介绍：
1.客户端通过HTTPS协议请求一个受保护的资源，SSL/TSL握手过程开始。
2.服务器将其公共证书与服务器问候一起返回给客户端。
3.客户端验证/验证收到的证书。客户端通过 CA 签名证书的证书颁发机构 (CA) 验证证书。
4.如果服务器证书验证成功，客户端将向服务器提供其公共证书。
5.服务器验证/验证收到的证书。服务器通过 CA 签名证书的证书颁发机构 (CA) 验证证书。
6.握手过程完成后，客户端和服务器相互通信并传输数据，并在握手过程中使用两者之间
共享的密钥加密。
2.3 B/S双向认证分析
2.3.1 Nginx双向认证
2.3.1.1 证书配置
Nginx.conf文件截图
*单向认证*
*双向认证-使用根证书签发客户端证书提供服务端验证*
*双向认证-客户端使用自签名证书供服务端验证*
ssl_verify_client 服务器验证客户端
ssl_client_certificate 制定一个受信任的CA证书用于验证客户端证书。会发送客户端。
ssl_trusted_certificate 信任的根证书，不会发送给客户端
访问IP或域名加端口号
选择证书
访问结果
2.3.2 Tomcat双向认证
2.3.2.1环境准备
修改tomcat中conf文件下的server.xml配置。
2.3.2.2证书配置
详细过程见3.2
2.3.2.3报文分析
双向SSL通信流程数据包分析如下。
服务器向客户端发送证书信息
将客户端证书cer安装至受信任的根证书颁发机构后
三、附录
3.1 Nignx证书生成流程
*建立自己的CA*
在openssl安装目录的misc目录下（或者在apps目录下），运行脚本：./CA.sh -newca（Windows环境下运行：perl ca.pl –newca），出现提示符时，直接回车。 运行完毕后会生成一个demonCA的目录，里面包含了ca证书及其私钥。
*生成客户端和服务端证书申请*
openssl req -newkey rsa:1024 -out req1.pem -keyout sslclientkey.pem
openssl req -newkey rsa:1024 -out req2.
SSL记录协议(SSL Record Protocol) :它建立在可靠的传输协议(如TCP)之上,为高层协议提供数据封装、压缩、加密等基本功能的支持。 pem -keyout sslserverkey.pem
*签发客户端和服务端证书*
openssl ca -in req1.pem -out sslclientcert.pem
openssl ca -in req2.pem -out sslservercert.pem
*Server端证书处理*
l 生成请求文件：openssl req -new -key sslserver.key -out sslserver.csr -subj “/C=CN/ST=HuBei/L=WuHan/O=dev/OU=dev/CN=192.168.61.178”
l 生成服务端带有CA签名的证书：openssl x509 -req -days 730 -CA ca.crt -CAkey cakey.key -CAcreateserial -in sslserver.csr -out sslserver.crt；
*Client端证书**处理-客户端自签*
l openssl req -x509 -new -nodes -key client.key -subj “/CN=client” -days 365 -out client.crt
l openssl pkcs12 -export -clcerts -in sslclient.crt -inkey client.key -out sslclient.pfx
*Client端证书**处理-Ca签发*
l openssl req -new -key sslclient.key -out sslclient.csr -subj “/C=CN/ST=HuBei/L=WuHan/O=dev/OU=dev/CN=client”
l openssl x509 -req -days 730 -CA ca.crt -CAkey cakey.key -CAcreateserial -in sslclient.csr -out sslclient.crt；
l openssl pkcs12 -export -clcerts -in sslclient.crt -inkey client.key -out sslclient.pfx
3.2 Tomcat证书生成流程
创建一个客户端密钥库、服务端密钥库、CA密钥库
需指定加密算法为RSA，默认不指定为DSA后续会导致证书错误
修改加密算法为RSA
[client.keystore]
生成口令：
keytool -genkeypair -alias client -keyalg RSA -keystore d:_code\cert\client.keystore -storepass 123456
[server.keystore]
生成口令：
keytool -genkeypair -alias server -keyalg RSA -keystore d:_code\cert\server.keystore -storepass 123456
[ca.keystore]
生成口令：
keytool -genkeypair -alias ca -keyalg RSA -keystore d:_code\cert\ca.keystore -storepass 123456
keytool -list -keystore d:_code\cert\client.keystore -storepass 123456 -v
此时查看三个密钥库都是自签名证书
tls单向认证，是服务端需要到CA去进行签名认证。
SSl双向认证，即需要客户端也需要到CA进行签名认证。
服务器需要通过自己的证书密钥库，来生成证书签名请求文件csr，给到CA
keytool -certreq -alias server -keystore d:_code\cert\server.keystore -storepass 123456 -file d:_code\cert\server.csr
客户端也需要通过自己的证书密钥库，来生成证书签名请求文件csr，给到ca
keytool -certreq -alias client -keystore d:_code\cert\client.keystore -storepass 123456 -file d:_code\cert\client.csr
CA收到客户端证书请求文件、服务端证书请求文件，用自己的密钥库中的密钥对csr文件进行签发，输出ca签发的服务端证书文件server.cer
Ca使用密钥库中别名为ca的证书中的密钥对 来签发服务端证书请求文件
keytool -gencert -alias ca -keystore d:_code\cert\ca.keystore -storepass 123456 -infile d:_code\cert\server.csr -outfile d:_code\cert\server.cer
Ca使用密钥库中别名为ca的证书中的密钥对 来签发客户端证书请求文件,输出ca签发的客户端证书文件client.cer
keytool -gencert -alias ca -keystore d:_code\cert\ca.keystore -storepass 123456 -infile d:_code\cert\client.csr -outfile d:_code\cert\client.cer
签发完成之后生成的证书cer文件，需要添加到服务器证书密钥库、客户端证书密钥库中
*此时ca不被信任，不能直接将server.cer文件直接导入证书密钥库server.keystore中*
需要优先生成ca自签名证书文件cer，即用ca.keystore来生成
keytool -exportcert -alias ca -keystore d:_code\cert\ca.keystore -storepass 123456 -file d:_code\cert\ca.cer
服务端、客户端都需要将ca.cer自签名证书导入自己的证书密钥库keystore中
Ca.cer—>server.keystore
Ca.cer—>client.keystore
keytool -importcert -alias ca -keystore d:_code\cert\server.keystore -storepass 123456 -file d:_code\cert\ca.cer
keytool -importcert -alias ca -keystore d:_code\cert\client.keystore -storepass 123456 -file d:_code\cert\ca.cer
keytool -importcert -alias server -keystore d:_code\cert\server.keystore -storepass 123456 -file d:_code\cert\server.cer
keytool -importcert -alias client -keystore d:_code\cert\client.keystore -storepass 123456 -file d:_code\cert\client.cer
此时因为ca已先对双端证书请求文件csr签发完成，并生成双端cer签名证书文件，双端证书密钥库也对ca已授信（优先条件），最后才能将cer签名完成的证书导入证书密钥库中。
keytool -list -keystore d:_code\cert\server.keystore -storepass 123456 -v
keytool -list -keystore d:_code\cert\client.keystore -storepass 123456 -v
将客户端证书库文件转换为p12文件
keytool -importkeystore -srckeystore D:_code\cert\client.keystore -destkeystore D:_code\cert\client.key.p12 -deststoretype pkcs12
由于是双向SSL认证，服务器必须要信任客户端证书，因此，必须把客户端证书添加为服务器的信任认证
keytool -importcert -file client.cer -keystore server.keystore -storepass 123456
]
此时因为ca已先对双端证书请求文件csr签发完成，并生成双端cer签名证书文件，双端证书密钥库也对ca已授信（优先条件），最后才能将cer签名完成的证书导入证书密钥库中。
keytool -list -keystore d:_code\cert\server.keystore -storepass 123456 -v
keytool -list -keystore d:_code\cert\client.keystore -storepass 123456 -v
![[外链图片转存中...(img-nku01x1q-1724746915654)]](https://i-blog.csdnimg.cn/direct/813b6ba5542d46218f4d1e240858a968.png)
将客户端证书库文件转换为p12文件
keytool -importkeystore -srckeystore D:_code\cert\client.keystore -destkeystore D:_code\cert\client.key.p12 -deststoretype pkcs12
由于是双向SSL认证，服务器必须要信任客户端证书，因此，必须把客户端证书添加为服务器的信任认证
keytool -importcert -file client.cer -keystore server.keystore -storepass 123456
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
