分享

SSL协议详解

 牛人的尾巴 2023-03-15 发布于安徽

https

HTTP 一般是明文传输,很容易被攻击者窃取重要信息。所以诞生了HTTPS。

HTTPS 的全称为 (Hyper Text Transfer Protocol over SecureSocket Layer),全称有点长,HTTPS 和 HTTP 有很大的不同在于 HTTPS 是以安全为目标的 HTTP 通道,在 HTTP 的基础上通过传输加密和身份认证保证了传输过程的安全性。

HTTPS 在 HTTP 的基础上增加了 SSL 层,也就是说 HTTPS = HTTP + SSL。

HTTPS工作在443端口,而HTTP默认工作在80端口。

SSL 是“Secure Sockets Layer”的缩写,中文叫做“安全套接层”。它是在上世纪90年代中期,由网景公司设计的。到了1999年,SSL 应用广泛,已经成为互联网上的事实标准。IETF 就把SSL 标准化。标准化之后SSL被改为 TLS(Transport Layer Security传输层安全协议)。SSL/ TLS

SSL原理详解

SSL协议结构:

在这里插入图片描述

SSL协议分为两层,下层为SSL记录协议,上层为SSL握手协议、SSL密码变化协议和SSL警告协议。

1.下层为SSL记录协议,主要作用是为高层协议提供基本的安全服务

建立在可靠的传输之上,负责对上层的数据进行分块、压缩、计算并添加MAC(消息验证码) 、加密,最后把记录块传输给对方。

2.上层为SSL握手协议、SSL密码变化协议和SSL报警协议

1> SSL握手协议:SSL握手协议被封装在SSL记录协议中,该协议允许服务器与客户端在应用程序传输和接收数据之前互相认证、协商加密算法和密钥。在初次建立SSL连接时,服务器与客户机交换一系列消息。

2> SSL修改密文协议:保障SSL传输过程中的安全性,客户端和服务器双方应该每隔一段时间改变加密规范

3> SSL报警协议:用来为对等体传递SSL的相关警告。如果在通信过程中某一方发现任何异常,就需要给对方发送一条警示消息通告。

SSL工作大致可以分为两个阶段

1.第一阶段:Handshake phase(握手阶段)

  • 协商加密算法

  • 认证服务器

  • 建立用于加密和MAC(Message Authentication Code)的会话密钥

2.第二阶段:Secure data transfer phase(安全数据传输阶段)

  • 在已经建立的SSL数据通道里安全的传输数据

SSL协议提供的服务:

1)认证用户和服务器,确保数据发送到正确的 客户机和服务器
2)加密数据以防止数据中途被窃取
3)维护数据的完整性,确保数据在传输过程中不被改变。
当你在浏览器的地址栏上输入https开头的网址后,浏览器和服务器之间会在接下来的几百毫秒内进行大量的通信:

认证服务器:浏览器内置一个受信任的CA机构列表,并保存了这些CA机构的证书。第一阶段服务器会提供经CA机构认证颁发的服务器证书,如果认证该服务器证书的CA机构,存在于浏览器的受信任CA机构列表中,并且服务器证书中的信息与当前正在访问的网站(域名等)一致,那么浏览器就认为服务端是可信的,并从服务器证书中取得服务器公钥,用于后续流程。否则,浏览器将提示用户,根据用户的选择,决定是否继续。当然,我们可以管理这个受信任CA机构列表,添加我们想要信任的CA机构,或者移除我们不信任的CA机构。

SSL原理

在这里插入图片描述

在用SSL进行通信之前,首先要使用SSL的Handshake协议在通信两端握手,协商数据传输中要用到的相关安全参数(如加密算法、共享密钥、产生密钥所要的材料等),并对对端的身份进行验证。

SSL第一阶段

客户端首先发送ClientHello消息到服务端,服务端收到ClientHello消息后,再发送ServerHello消息回应客户端。

在这里插入图片描述

ClientHello

客户端浏览器向服务器端发送如下信息:

  • Version 版本号(客户端支持的SSL /TLS协议的版本号。)

  • Random 客户端产生的#随机数#

  • Session id 会话ID

  • Cipher Suite(密钥算法套件):加密套件里面包含三部分:


    • 1、加密算法;


    • 2、完整性校验算法(MD5,哈希算法);

    • 3:密钥协商算法;主要看客户端和服务端支持哪一个算法,客户端会把自己支持的加密算法发送给服务端。

  • Compression Methods(压缩算法)

  • 预留

ServerHello

服务器端向客户端发送如下信息:

  • 服务器把自己支持的版本列出来,然后和客户端进行比较,拿出客户端支持的最新版本

  • 服务器端产生#随机数#

  • 服务端也列出加密套件,协商后使用统一的 加密套件

  • 客户端产生的会话ID写进服务器里面

  • 如果支持客户端的压缩算法,则使用

  • 扩展包

在此阶段之后通信双方分别确定了:

1、SSL的版本;2、加密套件;3、压缩算法;4、俩个随机数

SSL第二阶段

服务器向客户端发送消息,本阶段服务器是唯一发送方,客户端是唯一接收方。

在这里插入图片描述

本阶段共有四个消息,如下:

  1. 证书:服务器将数字证书和到根CA整个链发给客户端,使客户端能用服务器证书中的服务器公钥认证服务器。

  2. 服务器密钥交换(可选):这里视密钥交换算法而定。

  3. 证书请求:服务端可能会要求客户自身进行验证。

  4. 服务器握手完成:第二阶段的结束,第三阶段开始的信号

Certificate(可选)——第一次建立必须要有证书

一般情况下,除了会话恢复时不需要发送该消息,在SSL握手的全过程中都需要该消息。消息中包含一个X.509证书,证书中包含公钥,发给客户端用来验证签名或者在密钥交换时给消息加密。
这一步是服务端将自己的证书下发给客户端,让客户端验证自己的身份,客户端验证通过后取出证书中的公钥,以便后面的使用。

Server Key Exchange(可选)

根据之前的client hello消息中的cipther suite信息决定了,密钥交换的方法(例如RSA和DH),因此在此消息中便会完成密钥交换所需的一系列参数。

Certificate Request(可选)——可以是单向身份认证,也可以是双向

这一步是可选的,在安全性要求高的场合可以看到;服务端发送Certificate Request消息,请求客户端发送他自己的证书来进行验证。该消息中包含服务器端支持的证书类型(RSA、DSA、ECDSA),和服务器所信任的所有证书的发行机构的CA列表,客户端会用这些信息来筛选证书。

ServerHello Done

表示服务器已将所有的信息发送完毕,等待客户端发送消息

SSL第三阶段

客户端收到服务器发送的一系列消息并解析后,将本端相应的消息发送给服务器。
在这里插入图片描述

客户机启动SSL握手第3阶段,是本阶段所有消息的唯一发送方,服务器是所有消息的唯一接收方。该阶段分为3步:

  1. 证书(可选):为了对服务器证明自身,客户要发送一个证书信息,这是可选的,在IIS中可以配置强制客户端证书认证。

  2. 客户机密钥交换(Pre-master-secret):这里客户端将预备主密钥发送给服务端,注意这里会使用服务端的公钥进行加密。

  3. 证书验证(可选):对从第一条消息以来的所有握手消息进行签名。

Certificate(可选)

如果在第二阶段服务器要求客户端发送证书,客户端便会发送自己的证书,服务器端之前在发送的Certificate Request消息中包含了服务器所支持的证书类型和CA列表,客户端会在证书中找到满足要求的一个发送给服务器。若客户端没有证书,则会发送一个no_certificate警告。

Client Key Exchange

  • 根据之前从服务端收到的随机数,按照不同的密钥交换算法,算出一个Pre-master,发送给服务器,服务器收到pre-master,算出一个main-master。而客户端也能通过Pre-master自己算出一个main-master。如此一来,双方就算出了对称密钥。

  • 如果是RSA算法,会生成一个48位的随机数,然后用server的公钥加密后放入报文中;如果是DH算法,发送的就是客户端的DH参数,之后客户端和服务端根据DH算法,计算出相同的Pre-master secret。

  • 本消息在发送过程中,使用了服务器的公钥加密,服务器在收到后需要用服务器的私钥解密才能得到Pre-master Key。

Certificate Verify(可选)

只有在客户端在发送了证书到服务端时,这个消息才需要发送,其中包含签名,对从握手第一条消息以来的所有握手消息的HMAC值(用master_secret)进行签名。

SSL第四阶段

完成握手协议,建立SSL连接。

在这里插入图片描述

该阶段有四个消息交互,前两个为客户端发送,后两个为服务器发送。

建立起一个安全的连接,客户端发送一个Change Cipher spec消息,并且把协商得到的Cipher suite拷贝到当前连接的状态之中。然后客户端使用新的算法和密钥参数发送一个Finished消息,这条消息可以检测密钥交换和认证过程是否已经成功,其中包括一个校验值,对客户端整个握手消息进行校验。服务器同样发送一个Change Cipher Spec消息和Finished消息。握手过程完成,客户端和服务器可以交换应用层数据进行通信。

Change Cipher Spec

编码改变通知,表示随后的信息将用双方商定的加密算法和和密钥发送(ChangeCipherSpec是一个独立的协议,体现在数据包中就是一个字节的数据,用于告知服务端,客户端已经切换到之前协商好的加密套件(Cipher Suite)的状态,准备使用之前协商好的加密套件加密数据并传输了)。

Client finished

客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时也是前面所有发送的内容的hash值,用来供服务器校验。(使用HMAC算法计算收到和发送的所有握手消息的摘要,加密后发送。此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。)

Server Finished

服务端握手结束通知。

使用私钥解密加密的Pre-master数据,基于之前(Client Hello 和 Server Hello)交换的两个明文随机数 random_C 和 random_S,计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);
计算之前所有接收信息的hash值,然后解密客户端发送的 encrypted_handshake_message,验证数据和密钥正确性;
发送一个Change Cipher Spec(告知客户端已经切换到协商过的加密套件状态,准备使用加密套件和 Session Secret加密数据了)
服务端也会使用Session Secret加密一段Finish消息发送给客户端,以验证之前通过握手建立起来的加解密通道是否成功。
根据之前的握手信息,如果客户端和服务端都能对Finish信息进行正常加解密且消息正确的被验证,则说明握手通道已经建立成功,接下来,双方可以使用上面产生的Session Secret对数据进行加密传输了。

SSL原理—会话恢复

会话恢复是指只要客户端和服务器已经通信过一次,它们就可以通过会话恢复的方式来跳过整个握手阶段而直接进行数据传输。SSL采用会话恢复的方式来减少SSL握手过程中造成的巨大开销。此功能从之前的13步减少到6步,大大减少了开销。
在这里插入图片描述

两种会话机制

  • 会话标识 session ID: 由服务器端支持,协议中的标准字段,因此基本所有服务器都支持,服务器端保存会话ID以及协商的通信信息,Nginx 中1M 内存约可以保存4000个 session ID 机器相关信息,占用服务器资源较多;

  • 会话记录 session ticket :需要服务器和客户端都支持,属于一个扩展字段,支持范围约60%(无可靠统计与来源),将协商的通信信息加密之后发送给客户端保存,密钥只有服务器知道,占用服务器资源很少。

二者对比,主要是保存协商信息的位置与方式不同,类似与 http 中的 session 与 cookie。二者都存在的情况下,(nginx 实现)优先使用 session_ticket。

恢复过程
如果服务器和客户端之间曾经建立过连接,服务器会在握手成功后返回一个session ID,并保存对应的参数在服务器中。如果客户端和服务器需要再次连接,则需要在Client hello消息中携带记录的信息,返回给服务器。服务器根据收的到的Session ID检索缓存记录,如果有缓存,则返回一个Change Cipher Spec消息和Finished消息,如果没有缓存则正常进行握手。如果客户端能够验证通过服务器加密数据,则同样回复一个Change Cipher Spec消息和Finished消息。服务器验证通过则握手建立成功,开始进行正常的加密数据通信。

SSL记录协议

SSL记录协议主要用于实现对数据的分块、加密解密、压缩解压缩、完整性检测和封装各种高层协议。

在这里插入图片描述

主要包括:

  • 内容类型

  • 协议版本号

  • 记录数据的长度

  • 数据有效载荷

  • 散列算法计算消息认证代码

在这里插入图片描述

  1. 将上层分下来的数据包分成合适的数据块,但是每个数据块不得超过214字节。

  2. 对每个数据块进行压缩,但是不能丢失数据信息。

  3. 计算压缩后的数据消息认证码MAC,并添加在压缩包后。添加后总长度不得超过2262字节。

  4. 对称密码加密。

  5. 给SSL添加一个首部。其中包括:内容类型、主要版本、次要版本、压缩长度等信息。通过以上过程把原始的数据加密为SSL协议的记录集。

参考:https://blog.csdn.net/weixin_43997530/article/details/108048388

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多