HTTPS通讯全过程
不得不说,https比http通讯更加复杂惹。在第一次接触https代码的时候,不知道为什么要用用证书,公钥是什么?私钥是什么?他们作用是什么?非对称加密和对称加密是啥?天,这些似懂非懂的概念,大大增加了我写代码的困难(本人就是不理解原理就浑身难受那种人惹,代码写着写着就想为什么要这样写,牛角尖一枚罢噜)。如果你也有这样的疑问,那么就让我们一起来看看这篇文章吧~~啾咪
文章目录
一、https握手阶段
1、按双方的操作步骤分
(1)客户端开始握手
客户端通过发送一个 “ClientHello” 消息开始 TLS 握手。此消息包含客户端支持的 TLS 版本、一个客户端生成的随机数(client_random)、加密套件列表(cipher suites)、压缩算法列表,以及其他 TLS 扩展。
(2)服务器响应
服务器接收 “ClientHello” 消息后,回复一个 “ServerHello” 消息。此消息包含选定的 TLS 版本、一个服务器生成的随机数(server_random)、加密套件和压缩算法以及数字证书、证书链,证书链包括服务器的公钥证书和任何中间 CA 证书(但不含根 CA 证书)。服务器还可能发送一个 “ServerKeyExchange” 消息(如果需要),包含服务器的公钥或 Diffie-Hellman 参数。
(3)客户端验证证书
客户端验证服务器证书的有效性,包括证书链的完整性、证书是否过期、是否被受信任的 CA 签发、证书的域名是否与服务器域名匹配等
(4)客户端生成 premaster-secret
客户端使用算法生成premaster-secret,premaster-secret的生成有几种算法,具体使用那种算法,由前面的加密套件确定。
(5)客户端将发送预主密钥
客户端将premaster-secret使用ServerHello的证书中的公钥对premaster-secret进行加密得到的密文就是预主密钥。客户端将预主密钥发送给服务端。
(6)服务端获取premaster-secret
服务器使用私钥将预主密钥解密,得到premaster-secret。
(7)双方生成对称加密用的密钥key
双方根据ClientHello和ServerHello以及premaster-secret作为参数,使用相同的算法生成相同的密钥KEY,这样生成的KEY就是安全的。具体使用什么算法,也是由前面的加密套件协商选择的。
(8)客户端finish
客户端使用刚刚得到的KEY将握手结束信息加密,发送给服务端。
(9)服务端finish
服务端收到客户端的信息后使用KEY解密,并将客户端的握手结束信息使用KEY加密,发送给客户端。
(10)握手结束
客户端收到服务端发来的信息,使用KEY解密得到服务端的结束信息,随即结束握手阶段。
2、按消息发送分
(1)客户端ClientHello
客户端通过发送一个 “ClientHello” 消息开始 TLS 握手。此消息包含客户端支持的 TLS 版本、一个客户端生成的随机数(client_random)、加密套件列表(cipher suites)、压缩算法列表,以及其他 TLS 扩展。
(2)服务器ServerHello
服务器接收 “ClientHello” 消息后,回复一个 “ServerHello” 消息。此消息包含选定的 TLS 版本、一个服务器生成的随机数(server_random)、加密套件和压缩算法以及数字证书、证书链,证书链包括服务器的公钥证书和任何中间 CA 证书(但不含根 CA 证书)。服务器还可能发送一个 “ServerKeyExchange” 消息(如果需要),包含服务器的公钥或 Diffie-Hellman 参数。
(3)客户端将发送预主密钥
客户端收到ServerHello后。
【1】验证证书
客户端先验证服务器证书的有效性,包括证书链的完整性、证书是否过期、是否被受信任的 CA 签发、证书的域名是否与服务器域名匹配等
【2】生成permaster-secret
客户端使用算法生成premaster-secret,premaster-secret的生成有几种算法,具体使用那种算法,由前面的加密套件确定。
【3】对permaster-secret加密
客户端将premaster-secret使用ServerHello的证书中的公钥对premaster-secret进行加密得到的密文就是预主密钥。客户端将预主密钥发送给服务端
(4)客户端finish
【1】服务器对预主密钥进行解密
服务器使用私钥将预主密钥解密,得到premaster-secret。
【2】双方生成对称加密密钥KEY
双方根据ClientHello和ServerHello以及premaster-secret作为参数,使用相同的算法生成相同的密钥KEY,这样生成的KEY就是安全的。具体使用什么算法,也是由前面的加密套件协商选择的。
【3】发送finish信息
客户端使用刚刚得到的KEY将握手结束信息加密,发送给服务端。
(5)服务器finish
服务端收到客户端的信息后使用KEY解密,并将客户端的握手结束信息使用KEY加密,发送给客户端。握手结束。
给宝贝们偷来一张流程图惹(除了我还有谁把你们当小孩)
这位作者写的很不错,推荐大家看一下:
https://segmentfault.com/a/1190000021559557
二、通讯阶段
通讯阶段过程与Http通讯差别不大,唯一的差别是双方发送的数据包都会使用共享密钥KEY进行加密后再发给对方。
三、其他概念
1、信任链
信任链是网络安全和公钥基础设施(PKI)中的一个核心概念,它代表了一种验证和信任传递的机制。信任链确保了数字证书的可信度,允许用户确定一个实体(如网站、个人或组织)的身份是否真实,以及它是否有权执行特定的安全操作。
信任锚点:
信任链始于一个信任锚点,通常是根CA证书。这个证书被认为是可信的,因为它被预先安装在用户的设备或软件中,或者由操作系统或应用程序明确信任。
信任链断裂:
如果证书链中的任何环节出现问题,如证书未被正确签名、证书已过期或证书被吊销,信任链就会断裂,客户端将不信任该证书。
2、证书链
证书链是一系列数字证书的集合,它们彼此相连,形成一个信任路径,从某个特定的证书(通常是终端实体证书)一直追溯到一个根证书。起点:证书链的起点通常是终端实体证书,即直接颁发给个人、组织或服务器的证书。
(1)中间证书:
如果终端实体证书不是由根CA直接签发的,那么证书链中会包含一个或多个中间CA证书。这些中间证书由更高级别的CA签发。
(2)根证书:
证书链的终点是根CA证书,这是一个自签名的证书,作为信任锚点。
(3)信任模型:
证书链基于信任模型,即如果客户端信任根CA证书,那么它也会信任由该根CA或其下属CA签发的所有证书。
(4)验证过程:
在验证证书链时,客户端会逐个验证每个证书的签名,确保每个证书都是由前一个证书有效签发的。
(5)证书吊销检查:
在验证证书链的过程中,客户端可能还会检查证书是否被吊销,通过CRL或OCSP等机制。
(6)证书属性:
证书链中的每个证书都有自己的属性,如有效期、证书持有者信息、签发者信息等。客户端会检查这些属性以确保证书链的有效性。
(7)证书路径长度:
证书链的长度可能会受到某些客户端或应用程序的限制。例如,某些系统可能只允许最多有两到三个证书的链。
(8)交叉认证证书:
在某些情况下,证书链中可能包含交叉认证证书,即由不同CA签发的证书,这些CA之间相互认可对方的证书。
(9)信任决策:
客户端根据证书链中的证书和内置的受信任根证书列表来做出信任决策.
3、CA、根CA证书、中间CA证书
(1)CA:
是颁发证书的机构。
(2)根CA证书:
根CA证书是证书层次结构的顶层证书,它由CA机构自签名。这意味着根CA证书的签发者和主体是同一个实体。
根CA证书是信任锚点,用户或系统的受信任证书存储区中包含根CA证书,表示对该CA的信任。
(3)中间CA证书
中间CA证书是由根CA证书签发的证书,用于进一步扩展证书层次结构。
中间CA证书可以签发更多的中间CA证书或终端实体证书(如服务器证书或客户端证书)。类似于子子孙孙无穷尽也,后面会解释为什么要这样,这样的优点在哪里。
(4)在证书中理解信任链
通过使用中间CA证书,可以形成一个信任链,从终端实体证书开始,通过中间CA证书逐级向上追溯到根CA证书。
信任链确保了终端实体证书的信任可以追溯到一个受信任的根CA。
(5)使用类似派生的方法形成一级一级的证书的优势
1、区分根证书和中间证书的一个主要原因是为了管理方便。根CA证书的私钥需要非常严格的保护,因为如果根CA私钥泄露,整个信任体系会受到威胁。
2、使用中间CA可以分担根CA的证书签发工作,减少对根CA私钥的使用频率,从而降低风险
3、中间CA可以针对特定的用途或地区进行配置,提供更灵活的证书管理策略。
4、如果一个中间CA的私钥泄露或证书被滥用,影响范围限于该中间CA签发的证书,而不会影响到整个信任体系。
5、中间CA可以更灵活地管理证书的撤销,例如,中间CA可以维护自己的CRL或OCSP响应,而不必由根CA来处理。
6、不同的中间CA可能遵循不同的法律和政策,这使得它们能够更好地适应不同国家或地区的合规要求。
7、某些情况下,中间CA的使用可以解决技术限制,例如,某些系统或应用程序可能对证书链的长度有限制。
4、数字签名
数字签名是数字证书中一种加密机制,用于验证证书的真实性和完整性,并确保证书在传输过程中未被篡改。以下是数字签名在证书中的几个关键点:
1、签发机构(CA)的私钥:
数字签名是由证书的签发机构(CA)使用其私钥创建的。
2、证书内容的哈希值:
首先,证书的内容(如公钥、证书持有者信息、有效期、签发者信息等)会被转换成一个哈希值。这个哈希值是对证书内容的摘要,任何对证书内容的微小改变都会导致哈希值发生显著变化。
3、加密哈希值:
CA使用其私钥对证书内容的哈希值进行加密,生成数字签名。
4、附加到证书:
生成的数字签名会被附加到证书中,通常位于证书的尾部。
5、验证过程:
当需要验证证书的有效性时,接收方会使用CA的公钥来解密数字签名,得到原始的哈希值。同时,接收方也会对证书内容重新计算哈希值。如果两个哈希值相同,说明证书未被篡改,且数字签名验证成功。
6、信任链:
数字签名还确保了信任链的建立。如果证书链中的每个证书都由上一级的CA正确签名,那么整个证书链都是可信的。
5、数字证书
数字证书就是我们上面握手过程中介绍到的服务器发送给客户端的证书实体。
数字证书是一种电子文档,用于在互联网或其他网络通信中验证个人、组织或服务器的身份。它通过使用公钥基础设施(Public Key Infrastructure, PKI)来实现安全的身份验证和数据加密。以下是数字证书的一些关键特点:
1、身份验证:
数字证书用于验证证书持有者的身份,确保网络上的通信双方是他们所声称的实体。
2、公钥和私钥:
数字证书包含了证书持有者的公钥,而私钥则由持有者保密。公钥可以安全地分发给任何人,用于加密数据,而只有对应的私钥才能解密。
3、证书内容:
证书包含了证书持有者的基本信息(如姓名、组织、地理位置等)、公钥、有效期、序列号、签发者信息以及数字签名等。
4、数字签名:
CA使用其私钥对证书内容进行数字签名,以确保证书的真实性和完整性。
5、信任链:
数字证书的验证通常涉及一个信任链,即从证书持有者的证书开始,通过一系列中间CA证书,最终追溯到一个根CA证书。
6、证书吊销:
CA维护一个证书吊销列表(Certificate Revocation List, CRL)或使用在线证书状态协议(Online Certificate Status Protocol, OCSP),以跟踪和吊销不再有效或被泄露的证书。
7、证书类型:
有多种类型的数字证书,包括服务器证书(用于HTTPS网站)、客户端证书(用于用户身份验证)、电子邮件证书(用于安全电子邮件)等。
8、用途:
数字证书广泛应用于SSL/TLS安全通信、电子邮件加密、代码签名、安全访问控制等多种场景。
9、有效期:
数字证书有明确的有效期,有效期结束后需要更新或重新签发。
大家看完这一篇文章如果已经对https有80%理解的宝子,强烈建议大家看我下一篇文章《https握手过程详解》。为什么呢?因为在握手过程,为了大家第一次理解,我对握手过程进行了省略,实际上有的操作并不是在一步内完成的。《https握手过程详解》进一步讲解了https握手的全过程,让大家更进一步理解https全过程,这样在写代码或者进行输出的时候就不会有问题啦,冲冲冲。(如果还没有《https握手过程详解》就证明我还没有写完f发布惹)
点个赞赞么么哒~~