网站响应样式,wordpress能自己编码么,可以直接用php做网站吗,苏州做网站价格目录
1. TLS协议概述
2. 为什么要握手
2.1 Hello
2.2 协商
2.3 同意
3.总共握了几次手#xff1f; 1. TLS协议概述
车内各ECU间基于CAN的安全通讯--SecOC#xff0c;想必现目前多数通信工程师们都已经搞的差不多了#xff08;不要再问FvM了#xff09;#xff1b;…目录
1. TLS协议概述
2. 为什么要握手
2.1 Hello
2.2 协商
2.3 同意
3.总共握了几次手 1. TLS协议概述
车内各ECU间基于CAN的安全通讯--SecOC想必现目前多数通信工程师们都已经搞的差不多了不要再问FvM了但是在车云通信时保证数据的信息安全则常用TLS搞懂它加深加深运管端各自的网络安全机制理解。
TLS(Transport Layer Security)前身叫做SSL(Secure Sockets Layer)位于TCP之上但仍旧属于传输层作用很明确就是为了保证车云通信时数据的CIA。
目前TLS协议版本已经来到了1.3具体可以搜版本号RFC 8446在标准中详细描述了握手协议如下图 RFC 5246 : TLS v1.2RFC 4346 : TLS v1.1 RFC 2246 TLS v1.0
那么就从最基础的通信双方如何建立连接开始入门TLS。
2. 为什么要握手
握手这个词很形象就像相亲双方之前互不认识但因为家里要求见面那首先肯定是先握手握手成功双方来电接下来对话才有戏握手失败闲聊两句就各回各家。
握手期间的对话就很讲究了对话如能找到共同话题那相亲双方就可以围绕这个话题继续进行加密通信这也就是TLS要先握手的本质协商出一个密钥共同话题让双方基于这个密钥进行加密通信。
这个协议中定义握手消息名字也很有意思“Hello”包括了Client Hello和Server Hello等。
我们以TLS1.2流程为例因为抓包只抓到TLSV1.2总结流程如下 我用Wireshark抓了一个和https网页沟通的包过程和上图很像有么有 以这个为例来具体分析分析
2.1 Hello
第一条消息Client(我)向Server(知乎某专栏)发送Hello请求得到数据包如下 该消息体现了当前TLS版本协议、会话ID、随机数1很重要记住它、能够使用的密码套件、压缩算法还有很多扩展内容特别是有个server_name就像相亲两人见面第一句一定是你就是xxx吧
Client打了招呼那Server应该要进行回复不然就没得聊了它话很多打一声招呼Server Hello紧接着陆陆续续发送了自己的证书、密钥交换参数最终以Hello Done结尾
Server Hello
格式如下 Server首先会进行响应并且从Client能够使用的密码套件中选择一种在这里它选择了0xc02f满足第一条消息中提供的密码套件这条消息确认了TLS版本1.2选择了套件并且承诺不会压缩后续对话注意这里Server还传递了一个随机数2。
密码套件名字很长TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256但其实得拆开来看
ECDHE指的是密钥交换算法 Elliptic Curve Diffie-Hellman Ephemeral签名就使用RSA算法
AES_128_GCM是指后续加密通信使用AES128-GCM既定义了密钥长度也定义了密码工作模式SHA256就很简单了做Hash都用它。
Server Certificate
还是以相亲为例两人见面后的第二句话一定是我是某某阿姨(中间人)介绍的xxx。
这句话很关键因为相亲双方都是基于中间人的介绍ta的介绍就像是一个证书是相亲双方能够继续往下聊的一个前提。
但这个中间人只是双方认可的如果需要再进一步确认信息身份证就是最好的证明这是最权威的机构颁发的证书。
因此Server Certificate提供证书的目的也很明确就是证明自己的合法身份这条消息格式如下 证书主要包含了如下信息 证书里包含了一个非常关键的内容Server的公钥其他关于证书的问题我们后面单独再谈。
有兴趣的可以搜一搜中国电子银行网的《六问六答》。
Server Key Exchange
前面我们已经知道了双方要写上一个密钥使用算法为ECDHE这个算法要求双方首先交换公钥因此需要这条消息 Key Exchange格式如下 这里面包括了握手类型、算法所选曲线采用x25519、用于协商密钥的公钥以及用上述证书中公钥对应的私钥进行的签名算法为RSA-PSS-SHA256这些算法填充格式之前已经聊过了。
Server Hello Done
Hello Done的信息量很少如下 就是Server告诉Client自我介绍完毕看你怎么回应。
事实上通过Wireshark抓包我们可以看到Server回应的消息实际是在一个包内如下图所示 2.2 协商
在第一步里Client收到了Server发来的证书、密钥交换的参数等等就需要对一步一步来验证Server的身份和数据完整性并向Server发送密钥协商的参数同样一包中可以封装了不同的消息如下图 Client Key Exchange
首先Client使用CA的公钥对证书进行验签过程暂不讲通过后取出Server的公钥备用。
这时候Client就拥有了四个参数自己的协商公钥、Server的协商公钥、随机数1、随机数2。
那么神奇的就来了预协商密钥 c_priv * s_pub c_priv * (s_priv * G)
G是椭圆曲线的基点G是公开的唯有私钥是各自保护所以Client也要把协商公钥发给Server Server拿到后计算预协商密钥 s_priv * c_pub s_priv * c_priv * G。
这不就妥了吗两边预协商密钥都一样了这个密钥一般叫预主密钥。
还记得之前两个随机数吗Client和Server会使用相同算法对这三个参数进行操作得到最终会话密钥 Algo(随机数1 随机数2 预主密钥)
Change Cipher Spec
这个消息就是告诉Server咱们密钥都已经协商好了那就用它开始进行对话吧截图如下 Encrypted Handshake Message
这个时候就使用了协商好的对称密钥对握手消息进行加密传输如下 之后就是加密后的应用数据了。
2.3 同意
当Client发送经过对称加密的消息后Server当然也需要进行确认因此会回复三个消息 New Session Ticket
该消息主要是为了快速恢复会话防止重复握手
Change Cipher Spec
表示Server接收到了使用协商好的共享密钥并且确认后续都使用该密钥进行加密通话。
Encrypted Handshake Message 3.总共握了几次手
最后总结一下 TLS建立连接时总共进行了几次握手
第一次Client向Server发送 Client Hello包括协议的版本信息、密码套件、随机数(Client Random)等
第二次Server向Client发送 Server Hello包括所选密码套件、协议版本、数字证书、随机数(Server Random)
第三次Client向Server发送协商密钥的参数、更新加密协议、发送密文等
第四次Server向Client发送新建会话Tickets、发送密文以验证对称加解密通道
这就是TLS的四次握手成功。
