码迷,mamicode.com
首页 > Web开发 > 详细

HTTPS协议、TLS协议、证书认证过程解析

时间:2019-09-25 15:54:47      阅读:137      评论:0      收藏:0      [点我收藏+]

标签:三层   tip   加解密   cipher   extension   RKE   ons   tls   组织   

一、HTTPS 协议

HTTPS协议其实就是HTTP over TSL,TSL(Transport Layer Security) 传输层安全协议是https协议的核心。

TSL可以理解为SSL (Secure Socket Layer)安全套接字层的后续版本。

TSL握手协议如下图所示

技术图片

(注:图片来源于google图片)

在建立TCP连接后,开始建立TLS连接。下面抓包分析TLS握手过程,抓包图片来源于传输层安全协议抓包分析之SSL/TLS (自己没抓到这么完整的包,只能搬运过来了,摔)

(1) client端发起握手请求,会向服务器发送一个ClientHello消息,该消息包括其所支持的SSL/TLS版本、Cipher Suite加密算法列表(告知服务器自己支持哪些加密算法)、sessionID、随机数等内容。

技术图片

(2) 服务器收到请求后会向client端发送ServerHello消息,其中包括:

SSL/TLS版本;

session ID,因为是首次连接会新生成一个session id发给client;

Cipher Suite,sever端从Client Hello消息中的Cipher Suite加密算法列表中选择使用的加密算法;

Radmon 随机数。

技术图片

(3) 经过ServerHello消息确定TLS协议版本和选择加密算法之后,就可以开始发送证书给client端了。证书中包含公钥、签名、证书机构等信息。

技术图片

(4) 服务器向client发送ServerKeyExchange消息,消息中包含了服务器这边的EC Diffie-Hellman算法相关参数。此消息一般只在选择使用DHE 和DH_anon等加密算法组合时才会由服务器发出。

技术图片 

(5) server端发送ServerHelloDone消息,表明服务器端握手消息已经发送完成了。

技术图片

(6) client端收到server发来的证书,会去验证证书,当认为证书可信之后,会向server发送ClientKeyExchange消息,消息中包含客户端这边的EC Diffie-Hellman算法相关参数,然后服务器和客户端都可根据接收到的对方参数和自身参数运算出Premaster secret,为生成会话密钥做准备。

技术图片

(7) 此时client端和server端都可以根据之前通信内容计算出Master Secret(加密传输所使用的对称加密秘钥),client端通过发送此消息告知server端开始使用加密方式发送消息。

技术图片

(8) 客户端使用之前握手过程中获得的服务器随机数、客户端随机数、Premaster secret计算生成会话密钥master secret,然后使用该会话密钥加密之前所有收发握手消息的Hash和MAC值,发送给服务器,以验证加密通信是否可用。服务器将使用相同的方法生成相同的会话密钥以解密此消息,校验其中的Hash和MAC值。

技术图片

(9) 服务器发送ChangeCipherSpec消息,通知客户端此消息以后服务器会以加密方式发送数据。

技术图片

(10) sever端使用会话密钥加密(生成方式与客户端相同,使用握手过程中获得的服务器随机数、客户端随机数、Premaster secret计算生成)之前所有收发握手消息的Hash和MAC值,发送给客户端去校验。若客户端服务器都校验成功,握手阶段完成,双方将按照SSL记录协议的规范使用协商生成的会话密钥加密发送数据。

技术图片

 

二、session ID的复用

根据rfc5246,client和server建立TLS握手过程如下所示:

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

             Figure 1.  Message flow for a full handshake
* Indicates optional or situation-dependent messages that are not
   always sent.

client在向server发送ClientHello消息的时候,会传送Session ID给server端,server端收到session Id后会去session缓存中查找是否有相同值。如果找到相同值,则server直接发送一个具有相同session ID的ServerHello消息给client端(此时不必新建Session ID),然后双方各发一次ChangeCipherSpec消息后直接进入Finished消息互发阶段,具体如下图所示:

      Client                                                Server

      ClientHello                   -------->
                                                       ServerHello
                                                [ChangeCipherSpec]
                                    <--------             Finished
      [ChangeCipherSpec]
      Finished                      -------->
      Application Data              <------->     Application Data

          Figure 2.  Message flow for an abbreviated handshake

client和server通过缓存Session ID可以快速建立TLS握手,但是这么做也有一些弊端,例如:1)负载均衡中,多机之间往往没有同步 Session 信息,如果客户端两次请求没有落在同一台机器上就无法找到匹配的信息;2)服务端存储 Session ID 对应的信息不好控制失效时间,太短起不到作用,太长又占用服务端大量资源。而 Session Ticket(会话记录单)可以解决这些问题,Session Ticket 是用只有服务端知道的安全密钥加密过的会话信息,最终保存在浏览器端。浏览器如果在 ClientHello 时带上了 Session Ticket,只要服务器能成功解密就可以完成快速握手。

三、数字证书的验证

client端收到server端发过来的证书,首先必须要做的事验证证书是否可信。如何验证证书是否可信呢?为了解决这个问题,我们先来了解下证书的组成

技术图片

从这里面我们能看到证书包含以下内容:

(1) Validity也即有效期,有效期包含生效时间和失效时间,是一个时间区间;

(2) 公钥信息Subject Public Key Info,包括公钥的加密算法和公钥内容;

(3) Fingerprints信息,fingerprints用于验证证书的完整性,也就是说确保证书没有被修改过。 其原理就是在发布证书时,发布者根据指纹算法(此处证书使用了SHA-1和SHA-256算法)计算整个证书的hash值(指纹)并和证书放在一起,client在打开证书时,自己也根据指纹算法计算一下证书的hash值(指纹),如果和刚开始的值相同,则说明证书未被修改过;如果hash值不一致,则表明证书内容被篡改过;

(4) 证书的签名Certificate Signature Value和Certificate Signature Algorithm,对证书签名所使用的Hash算法和Hash值;

(5) 签发该证书的CA机构Issuer;

(6) 该证书是签发给哪个组织/公司信息Subject;

(7) 证书版本Version、证书序列号Serial Number以及Extensions扩展信息等。

技术图片

如上图所示,为签名过程和client端验证过程。中间方框为一个数字证书,在制作数字证书时,会将证书中的部分内容进行一次Hash得到一个Hash值,然后证书认证机构简称CA会使用私钥将该Hash值加密为Certificate Signature。

当证书发送给Client端之后,Client端首先会使用同样的Hash算法获得一个证书的hash值H1。通常浏览器和操作系统中集成了CA机构的公钥信息,浏览器收到证书后可以使用这些公钥解密Certificate Signature内容,得到一个hash值H2。

比较H1和H2,如果值相同,则为可信赖的证书,否则则认为证书不可信。

自己通过openssl生成的自签发证书只是使用自己的私钥去加密上图左侧计算出的Hash Value,这个时候client端得到server端发过来的证书之后,仍然会尝试使用浏览器或系统内置的CA机构的公钥去解密,解密出来的hash值H2当然不可能与H1相同,因此浏览器认为该证书不受信任。但是如果我们选择相信该证书并且继续访问该web,访问并不会出现任何问题,这是因为证书中的公钥并未加密,使用该公钥也确实能和server端的私钥进行TLS握手。

四、证书信任链

在证书认证过程中还存在一个证书信任链的问题,因为我们从CA机构申请到的证书基本不可能是根证书签发。还是以百度的证书为例,如下图所示,百度证书层级为三层,认证过程如下:

技术图片

(1) 当client端访问baidu.com的时候,baidu的server会将baidu.com证书发送给client端。

(2) client端的操作系统或者浏览器中内置了根证书,但是client端收到baidu.com这个证书后,发现这个证书不是根证书签发,无法根据本地已有的根证书中的公钥去验证baidu.com证书是否可信。

于是client端根据baidu.com证书中的Issuer找到该证书的颁发机构GlobalSign Organization Validation CA - SHA256 - G2,去CA请求baidu.com证书的颁发机构GlobalSign Organization Validation CA - SHA256 - G2的证书。

(3) 请求到证书后发现GlobalSign Organization Validation CA - SHA256 - G2证书是由根证书签发,而本地刚好有根证书,于是可以利用根证书中的公钥去验证(验证方法见上一节)GlobalSign Organization Validation CA - SHA256 - G2证书,发现验证通过,于是信任GlobalSign Organization Validation CA - SHA256 - G2证书。

(4) GlobalSign Organization Validation CA - SHA256 - G2证书被信任后,可以使用GlobalSign Organization Validation CA - SHA256 - G2证书中的公钥去验证baidu.com证书的可信性。验证通过,于是信任baidu.com证书。

在这四个步骤中,最开始client端只信任根证书GlobalSign Root CA证书的,然后GlobalSign Root CA证书信任GlobalSign Organization Validation CA - SHA256 - G2证书,而GlobalSign Organization Validation CA - SHA256 - G2证书又信任baidu.com证书,于是client端也信任baidu.com证书。这样的一个过程就构成了一条信任链路,整个证书信任链验证流程如下图所示。

技术图片

五、非对称加解密

非对称加密包含一个密钥对:公钥和私钥。公钥可以公开,私钥必须安全保存。

技术图片

如上图所示,数据可以被公钥加密,加密后的数据只有持有私钥才能进行解密。同理私钥加密的数据,也只有对应的公钥才能解密。

建立HTTPS连接以后,client(浏览器)已经获得server段的公钥,并且经过TLS协议在握手过程中协商出一个只有双方知道的对称密钥,在后续的数据传输过程中都将使用该密钥进行数据加密传输。因为公钥是公开的,可以下发给所有client端的,这个时候即使其他拥有公钥的client端截获到server端发给client端的消息,也无法仅仅凭借公钥去解密这个消息,因为这个消息加密密钥是由client和server通过相同算法计算出来,并且添加了随机数,理论上这个对称密钥只有client和server才能知道。

 

参考文档:

https://tools.ietf.org/html/rfc5246#page-6

http://www.freebuf.com/articles/network/116497.html

https://imququ.com/post/optimize-tls-handshake.html

http://blog.csdn.net/wzzvictory/article/details/9015155

 
分类: HTTPS
好文要顶 关注我 收藏该文 技术图片 技术图片
1
0
 
 
 
« 上一篇: java.lang基础数据类型boolean、char、byte、short、int、long、float、double (JDK1.8) 
» 下一篇: VisualVM 分析full GC问题记录

posted on 2017-11-08 22:52 snowater 阅读(11263) 评论(3) 编辑 收藏

 

评论

 

#1楼 2017-11-09 14:16 淡墨青云

 

mark
   回复 引用

 

#2楼 2018-12-21 12:06 合月

 

这篇文章写的很细致,以前不明白的问题现在解决了,如有这方面知识需求的小伙伴,可以参考这个这程,我觉得这个课把零散的知识点整理的很系统,使知识架构更清晰,希望能帮到大家!
一个系统、全面讲解传统加密通信SSL/TLS的课程 : http://edu.51cto.com/sd/89f15
一个系统、全面讲解量子通信课程 链接: http://edu.51cto.com/sd/1bf10
   回复 引用

 

#3楼 2019-03-20 15:24 一路人生

 

TLS协议有若干子协议,比如纪录协议,握手协议,警告协议等。这些子协议完成密钥交换,身份认证等工作,目前广泛用的是TLS1.2,https 就是引入了TLS这一层,使得非加密的http数据得到了保护,要想系统的全面的了解学习TLS,以及部署调优,以及使用openssl完成类似CA与证书的签发,推荐一个课程 ,在51CTO 平台上搜索 tls ,第一个就是,SSL/TLS深度解析——OpenSSL实战部署与网络安全策略 。

HTTPS协议、TLS协议、证书认证过程解析

标签:三层   tip   加解密   cipher   extension   RKE   ons   tls   组织   

原文地址:https://www.cnblogs.com/MR-Guo/p/11584730.html

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