ImageVerifierCode 换一换
格式:DOCX , 页数:10 ,大小:225.90KB ,
资源ID:8996635      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/8996635.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(完整word证书的应用之一TCPSSL通信实例及协议分析中.docx)为本站会员(b****8)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

完整word证书的应用之一TCPSSL通信实例及协议分析中.docx

1、完整word证书的应用之一TCPSSL通信实例及协议分析中证书的应用之一 TCP&SSL通信实例及协议分析(中) SSL建立握手连接目的:1.身份的验证,client与server确认对方是它相连接的,而不是第三方冒充的,通过证书实现2.client与server交换session key,用于连接后数据的传输加密和hash校验简单的SSL握手连接过程(仅Server端交换证书给client):1.client发送ClientHello,指定版本,随机数(RN),所有支持的密码套件(CipherSuites)2.server回应ServerHello,指定版本,RN,选择CipherSuite

2、s,会话ID(Session ID)3.server发送Certificate4.Server发送ServerHelloDone5.Client发送ClientKeyExchange,用于与server交换session key6.Client发送ChangeCipherSpec,指示Server从现在开始发送的消息都是加密过的7.Client发送Finishd,包含了前面所有握手消息的hash,可以让server验证握手过程是否被第三方篡改8.Server发送ChangeCipherSpec,指示Client从现在开始发送的消息都是加密过的9.Server发送Finishd,包含了前面所有握

3、手消息的hash,可以让client验证握手过程是否被第三方篡改,并且证明自己是Certificate密钥的拥有者,即证明自己的身份下面从抓包数据来具体分析这一过程并说明各部分数据的作用以及如实现前面列出的握手的目标,当然了,最重要的还是说明为何这一过程是安全可靠的,第三方无法截获,篡改或者假冒1.client发送ClientHello每一条消息都会包含有ContentType,Version,HandshakeType等信息。ContentType指示SSL通信处于哪个阶段,是握手(Handshake),开始加密传输(ChangeCipherSpec)还是正常通信(Application)等

4、,见下表HexDecType0x1420ChangeCipherSpec0x1521Alert0x1622Handshake0x1723ApplicationVersion是TLS的版本,见下表Major VersionMinor VersionVersion Type30SSLv331TLS 1.032TLS 1.133TLS 1.2Handshake Type是在handshanke阶段中的具体哪一步,见下表CodeDescription0HelloRequest1ClientHello2ServerHello11Certificate12ServerKeyExchange13Certif

5、icateRequest14ServerHelloDone15CertificateVerify16ClientKeyExchange20FinishedClientHello附带的数据随机数据RN,会在生成session key时使用,Cipher suite列出了client支持的所有加密算法组合,可以看出每一组包含3种算法,一个是非对称算法,如RSA,一个是对称算法如DES,3DES,RC4等,一个是Hash算法,如MD5,SHA等,server会从这些算法组合中选取一组,作为本次SSL连接中使用。2.server回应ServerHello这里多了个session id,如果SSL连接断

6、开,再次连接时,可以使用该属性重新建立连接,在双方都有缓存的情况下可以省略握手的步骤。server端也会生成随机的RN,用于生成session key使用server会从client发送的Cipher suite列表中跳出一个,这里挑选的是RSA+RC4+MD5这次server共发送的3个handshake 消息:Serverhello,Certificate和ServerHelloDone,共用一个ContentType:Handshake3.server发送Certificateserver的证书信息,只包含public key,server将该public key对应的private k

7、ey保存好,用于证明server是该证书的实际拥有者,那么如何验证呢?原理很简单:client随机生成一串数,用server这里的public key加密(显然是RSA算法),发给server,server用private key解密后返回给client,client与原文比较,如果一致,则说明server拥有private key,也就说明与client通信的正是证书的拥有者,因为public key加密的数据,只有private key才能解密,目前的技术还没发破解。利用这个原理,也能实现session key的交换,加密前的那串随机数就可用作session key,因为除了client和

8、server,没有第三方能获得该数据了。原理很简单,实际使用时会复杂很多,数据经过多次hash,伪随机等的运算,前面提到的client和server端得RN都会参与计算。4.Server发送ServerHelloDone5.Client发送ClientKeyExchangeclient拿到server的certificate后,就可以开始利用certificate里的public key进行session key的交换了。从图中可以看出,client发送的是130字节的字节流,显然是加过密的。client随机生成48字节的Pre-master secret,padding后用public ke

9、y加密就得到这130字节的数据发送给server,server解密也能得到Pre-master secret。双方使用pre-master secret, master secret常量字节流,前期交换的server端RN和client的RN作为参数,使用一个伪随机函数PRF,其实就是hash之后再hash,最后得到48字节的master secret。master secret再与key expansion常量,双方RN经过伪随机函数运算得到key_block,PRF伪随机函数可以可以仿佛循环输出数据,因此我们想得到多少字节都可以,就如Random伪随机函数,给它一个种子,后续用hash计算

10、能得到无数个随机数,如果每次种子相同,得到的序列是一样的,但是这里的输入时48字节的master secret,2个28字节的RN和一个字符串常量,碰撞的可能性是很小的。得到key block后,算法,就从中取出session key,IV(对称算法中使用的初始化向量)等。client和server使用的session key是不一样的,但只要双方都知道对方使用的是什么就行了。这里会取出4个:client/server加密正文的key,client/server计算handshake数据hash的key。6.Client发送ChangeCipherSpecclient指示Server从现在开始

11、发送的消息都是加密过的7.Client发送Finishedclient发送的加密数据,这个消息非常关键,一是能证明握手数据没有被篡改过,二也能证明自己确实是密钥的拥有者(这里是单边验证,只有server有certificate,server发送的Finished能证明自己含有private key,原理是一样的)。client将之前发送的所有握手消息存入handshake messages缓存,进行MD5和SHA-1两种hash运算,再与前面的master secret和一串常量client finished进行PRF伪随机运算得到12字节的verify data,还要经过改进的MD5计算得到

12、加密信息。为什么能证明上述两点呢,前面说了只有密钥的拥有者才能解密得到pre-master key,master key,最后得到key block后,进行hash运算得到的结果才与发送方的一致。8.Server发送ChangeCipherSpecServer指示client从现在开始发送的消息都是加密过的9.Server发送Finishd与client发送Finished计算方法一致。server发送的Finished里包含hash给client,client会进行校验,如果通过,说明握手过程中的数据没有被第三方篡改过,也说明server是之前交换证书的拥有者。现在双方就可以开始后续通信,进入Application context了。

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1