码迷,mamicode.com
首页 > 其他好文 > 详细

SSL握手流程

时间:2015-01-07 16:41:22      阅读:271      评论:0      收藏:0      [点我收藏+]

标签:

一、SSL是什么?

   安全套接字(SSL)协议是Web浏览器和Web服务器之间安全交换信息的协议。

   SSL介于应用层和TCP层之间,应用层数据不再直接传递给传输层,而是传递给SSL层,SSL层对从应用层收到的数据进行加密,并增加自己的SSL头。

 技术分享

History:
1994年,NetScape公司设计了SSL协议(Secure Sockets Layer)的1.0版,但是未发布。
1995年,NetScape公司发布SSL 2.0版,很快发现有严重漏洞。
1996年,SSL 3.0版问世,得到大规模应用。
1999年,互联网标准化组织ISOC接替NetScape公司,发布了SSL的升级版TLS 1.0版。
2006年和2008年,TLS进行了两次升级,分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版。

 

技术分享

0x1:SSL记录协议:
1) 分组、组合
2) 压缩、解压缩
3) 以及消息认证  
4) 加密传输等

技术分享

0x2:SSL握手协议:
1). 客户机认证服务器 
2). 协商客户机与服务器选择双方都支持的密码算法  
3). 可选择的服务器认证客户 
4). 使用公钥加密技术生成共享密钥 
5). 建立加密SSL连接(过程都是明文的,握手完成之后才开始加密数据。)
0x3:SSL告警协议:SSL告警协议报文由严重级别和警告代码两部分组成
  
1. 严重级别(AlertLevel )
    1) Fatal
    Fatal级报警即致命级报警,它要求通信双方都要采取紧急措施,并终止会话,同时消除自己缓冲区相应的会话记录 
    2) Waming
    Warning级报警即警告级报警的处理,通常是通信双方都只进行日志记录,它对通信过程不造成影响
2. 警告代码 
    1) bad_record_mac:收到了不正确的MAC 
  2) unexpected_message:接收了不合适的报文 
    3) decompression_failure:解压缩函数收到不适当的输入。
    4) illegal_parameter:握手报文中的一个字段超出范围或与其他字段不兼容。
    5) certificate_revoked:证书已经被废弃。
    6) bad_certificate:收到的证书是错误的。
    7) certificate_expired:证书已经过期。
    8) handshake_failer:握手过程失败。
    9) no_certificate: 未提供证书
    10) unsupported_certificate: 未支持的证书格式
    11) certificate_unknown: 未知证书

二、SSL有什么用?

1. 秘密性: SSL客户机和服务器之间传送的数据都经过了加密处理,网络中的非法窃听者所获取的信息都将是无意义的密文信息

2. 完整性: SSL利用密码算法和散列(HASH)函数,通过对传输信息特征值的提取来保证信息的完整性,确保要传输的信息全部到达目的地,可以避免服务器和客户机之间的信息受到破坏。

3. 认证性:利用证书技术和可信的第三方认证,可以让客户机和服务器相互识别对方的身份。为了验证证书持有者是其合法用户(而不是冒名用户),SSL要求证书持有者在握手时相互交换数字证
书,通过验证来保证对方身份的合法性。

三、SSLTLS的差异:

1. 版本号:TLS记录格式与SSL记录格式相同,但版本号的值不同,TLS的版本1.0使用的版本号为SSLv3.12. 报文鉴别码:SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用了RFC-2104定义的HMAC算法。SSLv3.0使用了相似的算法,两者差别在于SSLv3.0中,填充字节与密钥之间采用的是连接运算,而HMAC算法采用的是异或运算。但是两者的安全程度是相同的。
3. 伪随机函数:TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块,是更安全的方式。
4. 报警代码:TLS支持几乎所有的SSLv3.0报警代码,而且TLS还补充定义了很多报警代码,如
    1) 解密失败(decryption_failed)
    2) 记录溢出(record_overflow)
    3) 未知CA(unknown_ca)
    4) 拒绝访问(access_denied)等。
5. 密文族和客户证书:SSLv3.0和TLS存在少量差别,即TLS"不支持":
    1) Fortezza密钥交换
    2) 加密算法
    3) 客户证书。
6. certificate_verify和finished消息:SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时,计算的输入有少许差别,但安全性相当。
7. 加密计算:TLS与SSLv3.0在计算主密值(master secret)时采用的方式不同。但都是以客户端和服务端各自产生的随机数Ramdom作为输入
8. 填充:用户数据加密之前需要增加的填充字节。在SSL中,填充后的数据长度要达到密文块长度的最小整数倍。而在TLS中,填充后的数据长度可以是密文块长度的任意整数倍(但填充的最大长度为255字节),这种方式可以防止基于对报文长度进行分析的攻击。

 

四、SSL过程

0x1: 流程  前两部称为“握手阶段”

1)客户端向服务器端索要并验证公钥    
2)双方协商生成“对话密钥”(不用通信方的公钥进行加密<耗时>,只用对方的公钥来加密本端生成的“密钥”)
3)双方采用“对话密钥”进行加密通信。

0x2:具体过程  只关注单向认证

1. Client Hello:首先,客户端(浏览器)先向服务器发出加密通信请求,这被叫做ClientHello请求。

1) 支持的协议版本,比如TLS 1.0版。
2) 一个客户端生成的随机数A,稍后用于生成"对话密钥"3) 加密方法:支持的多种非对称加密方法、多种对称加密方法、多种MAC算法
4)  支持的压缩方法。

2.Server Hello

1) 确认使用的加密通信协议版本,比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致,服务器关闭加密通信。
2) 一个服务器生成的随机数B,稍后用于生成"对话密钥"3) 确认使用的加密方法:从客户端提供的选出一个集合出来:{对称加密算法,非对称加密算法,MAC校验算法}

3. Certificate: server将“携带自己公钥信息的数字证书”和到根CA整个链通过Certificate消息发送给SSL客户端(整个公钥文件都发送过去)

1)客户端可以使用该公钥来验证服务器的身份

  证书中的消息包括:

           技术分享

    一般情况下客户端收到的是一个证书链,第一个是服务器的证书,之后是服务器证书签发者,最后是自签名的根证书。如下图,在实际解析中先要验证根CA的证书,然后是直接证书签发者证书,最后是服务器终端证书。

                    技术分享

证书合法性的判断方法:

~颁布者的合法性(hash值)
~有效期
~签名值是否合法:首先对证书中除签名值部分的内容按照证书中的签名算法进行签名,把得到的签名按照asn.1编码方式进行编码:OBJECT格式的签名算法+ ASN_OCTET_STRING格式的签名值A;把证书中的签名值按照证书中的主体公钥算法进行解密得到B;当A和B完全相同时认为证书有效(证书制作过程中的签名值计算方法:计算得到A,和客户端计算方法相同,用服务器私钥对A进行加密,得到证书中的签名值)

 

2)公钥加密pre-naster secret Client Key Exchange

    假设上面的证书验证通过了,这就意味着client相信server发过来的证书了,也就意味着client同意用server发过来的public key开始通讯了。注意,非对称加密的过程在这里开始了client生成了一个pre-master secret(通常也是一个随机数)P,使用server提供的public key加密P之后生成P‘,将P‘发给了server

server收到P‘后,用自己的private key解密还原出了P。注意这个P和之前A的最大不同是加密传输过来的哦。而且理论上在server没有泄露自己private key的情况下, 只有server能够从P‘还原出PSo,此时,clientserver双方已经具备了生成双方后面通讯时对称加密需要使用的master secret的条件:双方都有的一个确定的伪随机函数、3个彼此都知道的随机数ABP于是,双方在自己一方,通过共同的伪随机数和共同的素材,生成出来了master secret

--------------

为什么要使用三个随机数?

1)"不管是客户端还是服务器,都需要随机数,这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的,因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
2)对于RSA密钥交换算法来说,pre-master-key本身就是一个随机数,再加上hello消息中的随机,三个随机数通过一个密钥导出器最终导出一个对称密钥。
3)pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数,如果随机数不随机,那么pre master secret就有可能被猜出来,那么仅适用pre master secret
作为密钥就不合适了,因此必须引入新的随机因素,那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了,一个伪随机可能完全不随机,可是
是三个伪随机就十分接近随机了,每增加一个自由度,随机性增加的 可不是一。
"

 

4. Change cipher Spec:通信双方协商好了对称加密的密钥和对称加密的算法之后,用这个消息进行测试

1)client用双方同意的MAC(message authentication code)算法,比如MD5加密一段明文Q,生成MAC,然后用双方都同意的对称加密算法(比如AES)加密Q和MAC之后,
生成一段Change Cipher Spec(content type:20). 2)Server收到这条TLS record之后,会先尝试解密密文,再用约定的MAC算法验证内容是否被篡改。这个如果这两个任何一项工作失败了,就前功尽弃了。这里假设都成功了,
于是server做了上一步client同样的事情:生成一份content type为20的Change cipher Spec发给client,至此,整个握手过程正式结束。

5. 下面的通讯就是双方直接使用对称加密算法直接加解密message的过程了,每次交互过程中,还会包括上面描述的MAC验证的过程。

参考资料:大部分资料来自网络,我只是稍加整理。风格是抄袭Little Hann大神的~勿喷

http://www.cnblogs.com/LittleHann/p/3733469.html
http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
http://www.2cto.com/Article/201404/291859.html
http://blog.csdn.net/sealyao/article/details/5901510

 

SSL握手流程

标签:

原文地址:http://www.cnblogs.com/xiaoxiaoxin-love-ping/p/4208627.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!