HTTP/HTTPS和TCP、TLS/SSL的那些关系

客户端验证证书是否合法,如果不合法则提示告警
(2)数据传输阶段
当证书验证合法后,在本地生成随机数(例如:生成abcde)
通过公钥加密随机数,并把加密后的随机数传输到服务端
服务端通过私钥对随机数进行解密(解密后服务端得到:abcde)
服务端通过客户端传入的随机数构造对称加密算法,对返回结果内容进行加密后传输
3、TCP——传输层
TCP(,传输控制协议)是一种面向连接的、可靠的、基于字节流的通信协议,数据在传输前要建立连接,传输完毕后还要断开连接 。
TCP的三次握手:
1、从最开始双方都处于状态 。然后服务端开始监听某个端口,进入了状态 。
2、然后客户端主动发起连接,这一过程由客户端执行来触发 。将标志位 SYN置为1,随机生成一个序号seq=x,自己变成了SYN-SENT状态 。
3、服务端接收到,将SYN和ACK(对应客户端发来的SYN)都置为1,随机生成一个序号seq=y , 还生成一个确认号ack=对方序号+1,自己变成了SYN-RCVD 。
4、客户端收到确认后,检查收到的ack是否为自己的序号+1,若没问题则将ACK置为1,将自己的序号值seq设为对方的确认号,将自己的确认号ack置为对方序号+1,发给服务端,将自己变成了状态;服务端收到数据包之后,检查ack是否为自己序号+1 , 如果没问题也变成了状态 。
两方可以开始传输数据了 。
用川航举例子:
①四川8633请求建立连接(SYN) , 并且发送出序号 。
②服务端接受到信号,即有确认号(ACK),此时并同样返回请求序号Seq
③客户端接受到信号,即有确认号(ACK),连接已经建立 。
(小结:三次握手的关键是要确认对方收到了自己的数据包,这个目标就是通过“确认号(Ack)”字段实现的 。计算机会记录下自己发送的数据包序号Seq , 待收到对方的数据包后,检测“确认号(Ack)”字段,看Ack = Seq + 1是否成立,如果成立说明对方正确收到了自己的数据包 。)
为什么需要第三次通信 ?
1、在第一次通信过程中,A向B发送信息之后 , B收到信息后可以确认自己的收信能力和A的发信能力没有问题 。
2、在第二次通信中,B向A发送信息之后,A可以确认自己的发信能力和B的收信能力没有问题 , 但是B不知道自己的发信能力到底如何,所以就需要第三次通信 。
3、在第三次通信中 , A向B发送信息之后,B就可以确认自己的发信能力没有问题 。
小结:3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好) , 也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认 。
TCP的四次挥手:
四次挥手 指断开一个TCP连接时,需要客户端和服务端总共发送4个包以确认连接的断开 。在编程中 , 这一过程由客户端或服务端任一方执行close来触发 。
由于TCP连接时全双工的,因此,每个方向都必须要单独进行关闭,这一原则是当一方完成数据发送任务后 , 发送一个FIN来终止这一方向的连接,收到一个FIN只是意味着这一方向上没有数据流动了,即不会再收到数据了,但是在这个TCP连接上仍然能够发送数据,直到这一方向也发送了FIN 。首先进行关闭的一方将执行主动关闭,而另一方则执行被动关闭 。
(1)第一次挥手:发送一个FIN,ACK , 确认号和序号,用来关闭到的数据传送,进入状态 。
(2)第二次挥手:收到FIN后,发送一个ACK给,确认号为对方序号+1,进入状态 。

HTTP/HTTPS和TCP、TLS/SSL的那些关系

文章插图
(3)第三次挥手:发送一个FIN和ACK,序号用对方的确认号 , 确认号为对方序号+1,关闭到的数据传送,进入状态 。
(4)第四次挥手:收到FIN后,进入状态,接着发送一个ACK给 , 确认号为对方序号+1,进入状态,完成四次挥手 。
川航图举例:
①客户端申请断开连接即FIN (我这边准备断开连接了)
②服务端接收信息返回,表示我已经接收到 (收到,请稍等,我这边准备一下)
③服务端发送信息表示可以断开连接 (我准备好了,你可以断开连接了)
④客户端接受信息,同时返回信息通知服务端自己收到信息 , 开始断开 连接(好的 , 拜拜?。?
上面是一方主动关闭,另一方被动关闭的情况,实际中还会出现同时发起主动关闭的情况:
应用层的进程,同时发出关闭命令 , 两端均从变为了状态,同时发送 FIN 段给对方 。
然而发送完 FIN 段后,并未收到对端的 ack 而是对方发来的一个 FIN 段 , 于是直接进入状态 ,  状态是一个新状态 , 之前我们没有遇到过 , 只在 TCP 状态机图里看到过 。现在你要记住,状态是由于同时关闭导致的 。
又过了一会儿,TCP 接收到 ack 后,进入状态 。
**提问:**为什么连接的时候是三次握手,关闭的时候却是四次握手?
①因为当端收到端的SYN连接请求报文后,可以直接发送SYN+ACK报文 。其中ACK报文是用来应答的,SYN报文是用来同步的 。
②但是关闭连接时,当端收到FIN报文时,很可能并不会立即关闭,所以只能先回复一个ACK报文,告诉端,“你发的FIN报文我收到了” 。
③只有等到我端所有的报文都发送完了,我才能发送FIN报文 , 因此不能一起发送 。故需要四步握手 。
4、 TLS/SSL——传输层
TLS/SSL 的功能实现主要依赖于三类基本算法:散列函数 Hash、对称加密和非对称加密,其利用非对称加密实现身份认证和密钥协商,对称加密算法采用协商的密钥对数据加密,基于散列函数验证信息的完整性 。
散列函数 Hash:常见的有 MD5、SHA1、 , 该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定 , 针对数据的任何修改都会改变散列函数的结果,用于防止信息篡改并验证数据的完整性 。在信息传输过程中,散列函数不能单独实现信息防篡改,因为明文传输,中间人可以修改信息之后重新计算信息摘要 , 因此需要对传输的信息以及信息摘要进行加密 。
对称加密:常见的有 AES-CBC、DES、3DES、AES-GCM 等,信息的加密和解密用相同的密钥,掌握密钥才能获取信息 。在对称加密中,信息安全的基础是保证密钥的安全 。
非对称加密:即常见的 RSA 算法,还包括 ECC、DH 等算法,算法特点是,密钥成对出现 , 一般称为公钥(公开)和私钥(保密) 。因此掌握公钥的不同客户端之间不能互相解密信息,只能和掌握私钥的服务器进行加密通信 。服务器持有私钥可以实现一对多的通信,而客户端可以用公钥来验证服务器发送的数字签名 。服务器只需要维持一个私钥就能够和多个客户端进行加密通信,但该算法的计算复杂,加密速度慢 。
结合三类算法的特点,TLS/SSL 的基本工作方式是,客户端使用非对称加密与服务器进行通信,实现身份验证并协商对称加密使用的密钥,然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信,不同的节点之间采用的对称密钥不同,从而可以保证信息只能通信双方获取 。
SSL / TLS 握手详细过程
1、“ hello” 消息:客户端通过发送 “ hello” 消息向服务器发起握手请求,该消息包含了客户端所支持的 TLS 版本,支持的算法列表和密码组合以供服务器进行选择,还有一个 “ ” 随机字符串 。
2、“ hello” 消息:服务器发送 “ hello” 消息对客户端进行回应 , 该消息包含了服务器选择的加密算法,服务器选择的密码组合,数字证书和 “ ” 随机字符串 。
验证:客户端对服务器发来的证书进行验证,确保对方的合法身份,验证过程可以细化为以下几个步骤:
(1)检查数字签名
(2)验证证书链
(3)检查证书的有效期
(4)检查证书的撤回状态 (撤回代表证书已失效)
4、" "字符串:客户端向服务器发送另一个随机字符串 “(预主密钥)”,这个字符串是经过服务器的公钥加密过的,只有对应的私钥才能解密 。
5、使用私钥:服务器使用私钥解密 “ ” 。
6、生成共享密钥:客户端和服务器均使用,和,并通过相同的算法生成相同的共享密钥 KEY 。
7、客户端就绪:客户端发送经过共享密钥 KEY 加密过的 “” 信号,为了防止握手过程遭到篡改 , 该消息的内容是前一阶段所有握手消息的MAC值 。
8、服务器就绪:服务器发送经过共享密钥 KEY 加密过的 “” 信号,该消息的内容是前一阶段所有握手消息的 MAC 值 。
9、达成安全通信:握手完成,双方使用对称加密进行安全通信 。
第 8 与第 9 步用以防止握手本身遭受篡改 。设想一个攻击者想要控制客户端与服务器所使用的算法 。客户端提供多种算法的情况相当常见,某些强度弱而某些强度强,以便能够与仅支持弱强度算法的服务器进行通信 。攻击者可以删除客户端在第 1 步所提供的所有高强度算法 , 于是就迫使服务器选择一种弱强度的算法 。第 8 步与第 9 步的 MAC 交换就能阻止这种攻击,因为客户端的 MAC 是根据原始消息计算得出的,而服务器的 MAC 是根据攻击者修改过的消息计算得出的,这样经过检查就会发现不匹配 。
5、证书校验
记录一个个人引发的问题 , 为什么窃听者不能有两个公钥和私钥去进行信息截取呢,这样不就完美获取信息了吗 。
以下是解答:
1、什么是证书?是用来干嘛的?
证书就是数字化的文件,里面有一个实体(网站,个人等)的公共密钥和其他的属性 , 如名称、CA信息、加密算法等 。该公共密钥只属于某一个特定的实体 , 它的作用是防止一个实体假装成另外一个实体 。
证书主要有两个作用,一个是加密通信,一个是数字签名 。
加密通信是保证数据不被别人截获并且不被知道通信内容的,主要是两个层次,一个是通信双方身份确认 , 避免对方是冒充的,另一个是数据通过公钥加密传输和使用私钥解密 。这方面常见的具体应用就是SSL和HTTPS 。
数字签名是用于识别签名者身份的,这个从字面就可以理解 。你使用你的私钥进行签名 , 然后用户看到你的签名后用公钥检查,发现的确是你的数字签名,就可以了 。这个常见的应用有代码发行商签名 , 就是签名控件的那种,邮件数字签名,电子公章等 。
2、什么是CA,证书只有CA能发吗,我自己不能发证书吗?
CA是 的缩写,即证书颂发机构,他是一个负责发放和维护证书的实体,一般是第三方的 。
CA的组织结构跟域名有些相似 , 有一个根CA,然后它派生了一些子的,子又生孙 , 孙又生子,子子孙孙无穷匮也 。但是给人家当孙子的滋味是不好受的,要交年费的 , 而且一个证书一年上万块 。于是乎,你可以自己当老大,就是自己当根,然后再发放证书,有一个缺陷是要取得别人的认可才行 。自己做根CA要有一个根证书,然后自己给自己签名,就行了 。然后再用这个根证书和根私钥给你的子机构签发证书就可以了 。用户使用你签名的证书之前必须要把你的根证书给用户,让用户安装在受信任的根区域就算认可了 。
3、证书校验的过程
证书链 ( chain):也称为证书路径,是用于认证实体合法身份的证书列表,具体到 HTTPS 通信中,就是为了验证服务器的合法身份 。之所以使用证书链 , 是为了保证根证书 (root CA ) 的安全,中间层可以看做根证书的代理,起到了缓冲的作用 , 如下图所示:
证书链从根证书开始 , 并且证书链中的每一级证书所标识的实体都要为其下一级证书签名,而根证书自身则由证书颁发机构签名 。客户端在验证证书链时,必须对链中所有证书的数字签名进行验证,直到达到根证书为止 。
4、根证书是CA认证中心给自己颁发的证书,是信任链的起始点 。安装根证书意味着对这个CA认证中心的信任 。
从技术上讲,证书其实包含三部分,用户的信息,用户的公钥,还有CA中心对该证书里面的信息的签名 。验证一份证书的真伪(即验证CA中心对该证书信息的签名是否有效),需要用CA 中心的公钥验证 , 而CA中心的公钥存在于对这份证书进行签名的证书内 , 故需要下载该证书 , 但使用该证书验证又需先验证该证书本身的真伪,故又要用签发该证书的证书来验证,这样一来就构成一条证书链的关系,这条证书链在哪里终结呢?答案就是根证书,根证书是一份特殊的证书,它的签发者是它本身,下载根证书就表明您对该根证书以下所签发的证书都表示信任,而技术上则是建立起一个验证证书信息的链条,证书的验证追溯至根证书即为结束 。所以说用户在使用自己的数字证书之前必须先下载根证书 。
小结:
正如链接5、6、7所看到的,证书的校验需要预先在自己的客户端上安装根证书,用来校验证书的真实性,如果是窃听者自己制作的证书 , 他的根证书没有安装在我们的客户端上 , 那么他加密的信息是无法在我们的客户端上进行根证书校验,是无法通过的 。而我们自己主动安装窃听者的根证书的话,是默认我们已经信任了窃听者的这种行为了 。
【HTTP/HTTPS和TCP、TLS/SSL的那些关系】以上是各个协议中的握手过程的一些个人记录 , 他们并不是说有固定的先后顺序,只是所在的协议不同,所产生的不同看法 。从不同协议去解释了整个握手的过程,什么是握手 , 怎么握手,怎么挥手,为什么三次、为什么四次、怎么加密、为什么选择这种捂手的方式、以及证书的一个信任传递的问题 。