SSL/TLS握手

已于 2023-03-22 11:02:29 修改
阅读量514 收藏 1
点赞数
分类专栏： # 密码学历程 文章标签： ssl
于 2021-09-02 09:56:14 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_42992876/article/details/119898086
版权

SSL握手

密码学基础概论

散列函数

散列函数的特点是单向不可逆、输入数据敏感（细微改动输出变化也很大）、输出长度固定，常用于校验数据的完整性；
常见的散列函数：

  • MD5
  • 输出散列值的长度固定为128bit
  • SHA-1/SHA-256/SHA-384/SHA-512
    SHA1输出散列值的长度固定为160bit；SHA256输出散列值的长度固定为256bit；SHA512输出散列值的长度固定为512bit；

散列函数术语：消息摘要、数据哈希

应用：检测文件是否被篡改、口令加密（将口令和盐混合后计算散列值作为密钥）、消息认证码（HMAC，通过在消息中加入共享密钥来生成可认证的散列值）、伪随机数生成器等；

密码学的6个重要工具分别是：对称加密，非对称加密、单向散列函数、消息认证码（与密钥关联单向散列函数）、数字签名（私钥生成签名，公钥验证签名）、伪随机数生成器

对称加密

对称加密算法的特点是使用相同的密钥对信息进行加密和解密，信息的传输模式是1对1，服务器和N个客户端通信，需要维持N个密钥，密钥的安全是信息安全的基础；

  • DES（短时间可破解）
    DES是一种将64bit的明文加密成64bit密文的对称加密算法，DES的密钥长度是64bit，但是由于每隔七位设置一位错误校验位，因此实质上其密钥长度是56bit；
    DES加密是分组加密的一种，加密时明文以64bit为一组；如果明文较长时，就需要对DES加密进行迭代（反复），迭代的方式又称为模式；

  • 3DES
    3DES是为了增强DES强度，将DES重复3次所得的一种加密算法，明文经过三重DES算法处理才能变为密文，3DES算法的密钥长度为192（3个密钥，每个密钥64bit，64x3）;如果使用的三个密钥都不相同，3DES又称3DES-EDE3；
    3DES并不是对明文进行三次DES加密，而是加密 -> 解密 - > 加密，其目的是为了兼容DES，当使用的三个密钥都相同时，3DES就相当于普通的DES加密了；

  • AES
    Rijndael加密算法，又称AES，是一种分组密码算法，其分组的长度为128bit（标准，同样也可以按后续规则选择，分组长度和密钥长度可以不相同），密钥的长度可以以32bit为单位，在128bit到256bit的范围内进行选择（规范的密钥长度只有128、192、256三种）；

非对称加密

非对称加密算法的特点是密钥是成对出现，一般称为公钥（公开）和私钥（保密），公钥加密的数据只能私钥解开，私钥加密的数据只能公钥解开，服务器只需要维持一个私钥就可以和多个客户端通信；该算法的加密计算复杂，加密速度较慢；

  • RSA
  • ECC
  • DH
分组密码模式

分组加密算法都只能加密固定长度的明文，如果明文的长度是任意的，那么只能通过分组迭代的方式反复加密，而分组迭代方法就称为分组密码的模式；一旦分组密码模式选择不恰当，攻击者很可能会根据密文中的规律来破解密文；

  • ECB模式（Electronic Code Book 电子密码本模式）
    将明文分组直接加密输出密文分组的方式就是ECB模式；
    在这里插入图片描述

  • CBC模式（Cipher Block Chaining密文分组链接模式）
    CBC模式是将前一个密文分组和当前明文分组的内容混合起来进行加密；
    CBC模式块与块之间耦合性很强，无法直接对中间某一块加解密，如果密文中某一块数据损坏了，那么后面的内容都无法正确解密；
    在这里插入图片描述

  • CFB模式（Cipher FeedBack密文反馈模式）
    CFB模式是将前一个密文分组再次加密后与本次明文分组内容异或产生本次的密文分组；
    由于明文分组和密文分组之间只是进行了一次异或操作，因此明文数据可以被逐比特位加密，我们可以将CFB模式看做是一种使用了分组密码来实现流密码的方式；
    CFB的数据块之间依然存在很大的耦合性；
    在这里插入图片描述

  • OFB模式（Output-Feedback，输出反馈模式）
    OFB模式通过对初始化向量多次加密，并且依次将加密输出与明文分组内容异或产生密文分组；
    在这里插入图片描述

  • CTR模式（CounTeR，计数器模式）
    CTR模式通过将逐次累加的计数器进行加密后与明文分组异或后生成密文分组；
    加密时会生成一个值来作为计数器的初始值，加密每组数据时该值会逐次累加；
    CTR的优点是通过组序号可以以任意顺序处理分组，这就意味着能够实现并行计算；
    在这里插入图片描述

分组密码是每次只能处理特定长度数据的一类密码算法，无需记录加解密的内部进度；流密码是对数据流进行连续处理的一类密码算法，流密码中一般以1bit、8bit或32bit为单位进行加密和解密，需要记录加解密的内部进度；

密钥配送

当对数据使用对称加密算法加密时，一定会遇到密钥配送的问题，解决密钥配送问题的方法有以下几种；

  • 事先共享密钥
    配送密钥最简单的一种方式，事先用安全的方法将密钥共享给对方；

  • 密钥中心分配
    通过密钥分配中心来获取通信密钥；

  • Diffie-Hellman密钥交换
    通信前，通信双方需要交换一些信息（各自随机生成的私钥使用相关算法后计算出的公钥），根据交换的信息，双方各自可以生成相同的密钥（离散对数原理）；

  • 公钥密钥
    使用非对称加密的方式配送密钥，持有加密密钥的一方将密钥加密后，只有持有解密密钥的一方才能解密；

证书

证书的作用和颁发

主要是确保公钥的合法性以解决服务器身份验证的问题。

证书的颁发需要引入第三方机构CA，CA负责核实公钥拥有者的相关信息，并颁发认证证书，同时能够为使用者提供证书认证服务，即PKI体系；其基本的原理是：CA负责审核信息，然后对关键信息利用私钥进行"签名"，公开对应的公钥，客户端可以利用公钥验证签名。CA也可以吊销已经签发的证书，基本的方式包括两类 CRL 文件（证书吊销列表文件）和 OCSP（证书状态在线查询协议）。

证书的颁发和使用流程：
（1）服务方S向第三方机构SA提供公钥、组织信息、个人信息（域名）等相关信息并申请认证；
（2）SA审核服务方相关信息，并颁发证书，证书包含如下明文信息：申请者的公钥、申请者相关信息、证书颁发机构、有效时间、证书序列号等；同时证书包含一个密文签名（使用散列函数计算公开明文信息的摘要，然后采用CA的私钥对摘要加密）；
（3）客户端向服务方申请证书，并读取证书的相关明文信息，采用相同的散列函数计算信息摘要，然后使用CA提供的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性；然后客户端会验证证书相关的域名信息和有效时间；
（4）客户端会内置信任CA的证书信息（包含CA公钥），如果CA不被信任，则找不到对应CA的证书，证书也被判定为非法（内置CA对应证书称为根证书，颁发者和申请者相同都为CA，自己为自己签名，即自签名证书，内置CA证书是为了验证CA公钥的合法性，以此来解密服务方证书的签名信息）；
（5）总结：证书=服务方公钥+申请者与颁发者信息+签名（CA签署的凭证）；

注：如果是在内部测试，或是测试https加密传输，可以使用openssl生成自签证书

流程图如下：

证书文件

csr文件：证书请求文件，用于申请证书。
crt文件：CA认证后的证书文件。
key文件：服务方使用的私钥

证书相关总结

在这里插入图片描述

TSL/SSL协议

TSL/SSL工作原理

TLS/SSL的功能实现主要依赖于三类基本的算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。
在这里插入图片描述

TSL/SSL握手

SSL握手流程图：
在这里插入图片描述
1.信息交互部分
< client_hello >
 客户都安发送明文请求信息，包含了版本信息（SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3）、加密套件选择列表（每个套件包含认证算法 Au [身份验证]、密钥交换算法 KeyExchange[密钥协商]、对称加密算法 Enc [信息加密]和信息摘要 Mac[完整性校验]）、压缩算法选择列表、随机数RandomC、扩展字段等信息；

< server_hello >
（1）返回服务端协商的结果（使用什么版本什么加密算法等等以及用于生成密钥的随机数RandomS）；
（2）服务端配置对应的证书链（获取本地证书信息，发送证书Certificate给客户端，用于身份验证与密钥交换;）；
（3）通知客户端hello结束；

< 证书校验 >
 客户端验证服务器提供证书的合法性，如果验证通过才会进行后续通信；

2.密钥协商部分（采用非对称加密交换密钥，TLS1.3前）
< client >
 client_key_exchange:客户端产生随机数Pre-master，采用公钥加密后发送给服务器；
 change_cipher_spec：生成加密密钥enc_key = Func(randomC,randomS,Pre-Master)；告知服务器后续通信采用刚生成密钥；
 encrypted_handshake_message：客户端根据之前获取的相关信息生成hash数据后采用协商的密钥加密，并发给服务器握手验证；

< server >
 change_cipher_spec：服务器使用私钥解密Pre-master，使用同样的算法生成加密密钥；验证客户端发送的握手数据后，告知后续通信都采用该密钥；
 encrypted_handshake_message：服务器根据之前获取的相关信息生成hash数据采用协商的密钥加密，发送给客户端握手验证

< client >
 当客户端验证成功后，握手成功；

3.会话缓存
会话缓存有两种模式，会话标识（Session ID）和会话记录（Session ticket）；
 Session ID由服务端支持，是协议中的标准字段，服务端可以保存会话ID以及协商的通信内容；
 Session ticket需要服务端和客户端都支持，属于一个扩展字段，将协议的协商通信内容加密后发送给客户端保存，服务端保存密钥；
 二者的差别主要再保存协商信息的位置与方式不同，类似于http的session（服务器保存）和cookie（浏览器保存），二者共存时优先使用ticket；
在这里插入图片描述

Session ID的过程：
（1）如果客户端和服务器之间曾经建立了连接，服务器会在握手成功后返回 session ID，并保存对应的通信参数在服务器中;
（2）如果客户端再次需要和该服务器建立连接，则在 client_hello 中 session ID 中携带记录的信息，发送给服务器;
（3）如果服务器未检索到对应的缓存记录，走正常握手流程，反之则返回 change_cipher_spec 与 encrypted_handshake_message 信息（当前的通信参数与 对称加密密钥的hash 值）；
（4）如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec 与 encrypted_handshake_message 信息;
（5）服务器验证，握手成功；

Session ticket的过程：
（1）如果客户端和服务器之间曾经建立了连接，服务器会在 new_session_ticket 数据中携带加密的 session_ticket 信息，客户端保存;
（2）如果客户端再次需要和该服务器建立连接，则在 client_hello 中扩展字段 session_ticket 中携带加密信息，一起发送给服务器;
（3）服务器解密 sesssion_ticket 数据，如果能够解密失败，则按照正常的握手过程进行;
（4）如果解密成功，则返回 change_cipher_spec 与 encrypted_handshake_message 信息，两个信息作用与 session ID 中类似;
（5）如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec与encrypted_handshake_message 信息;
（6）服务器验证，握手成功；

(ssl部分文字及图片摘录自http://www.wosign.com/faq/faq2016-0309-03.htm)

抱猫人
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
TSL握手过程
庸才
10-09 441
     Client Hello 由客户端发起，主要包含SSL version、Random1、Support Suites以及Session ID    Server Hello 服务器返回，主要包含Random2、Cipher Suite              Certificate 服务器下放给客户端的证书   Server Key Exch...
SSL握手过程
SeanWXQ的专栏
11-30 1462
一、SSL握手有三个目的：1. 客户端与服务器需要就一组用于保护数据的算法达成一致；2. 它们需要确立一组由那些算法所使用的加密密钥；3. 握手还可以选择对客户端进行认证。二、SSL握手过程：1. 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器；2. 服务器从算法列表中选择一种加密算法，并将它和一份包含服务器公用密钥的证书发送给客户端；该证书还包含了用于认证目的的服务器标识，
Netty传输链路中，使用TLSv1.3传输层安全协议进行加密如何实现
最新发布
panying941206的博客
07-18 426
netty中如何使用TLSv1.3协议进行加密
SSL/TLS 握手过程详解
weixin_34352005的博客
12-10 717
我们知道，HTTP 协议都是明文传输内容，在早期只展示静态内容时没有问题。伴随着互联网的快速发展，人们对于网络传输安全性的要求也越来越高，HTTPS 协议因此出现。如上图所示，在 HTTPS 加密中真正起作用的其实是 SSL/TLS 协议。SSL/TLS 协议作用在 HTTP 协议之下，对于上层应用来说，原来的发送接收数据流程不变，这就很好地兼容了老的 HTTP 协议，这也是软件开发中分层实现的...
SSL/TLS握手过程
CoderAldrich的专栏
11-13 3738
SSL（Secure Socket Layer）最初是由Netscape公司开发的一个协议，其目的在于为互联网提供一个安全的通信机制。
SSL/TLS协议详解(下)——TLS握手协议
m0_45079966的博客
09-19 2113
SSL/TLS协议详解(下)——TLS握手协议 本文翻译自：https://www.wst.space/ssl-part-4-tls-handshake-protocol/ 在博客系列的第2部分中,对证书颁发机构进行了深入的讨论.在这篇文章中，将会探索整个SSL/TLS握手过程，在此之前，先简述下最后这块内容的关键要点： TLS适用于对称密钥 对称密钥可以通过安全密钥交换算法共享 如果请求被截获，...
.net中为 SSL/TLS 安全通道建立信任关系
09-14
2. 使用 SSL/TLS 握手协议：客户端和服务器可以使用 SSL/TLS 握手协议来建立信任关系。在握手过程中，客户端和服务器将交换证书和密钥，以确保数据的安全传输。 常见的调试错误 在 .NET 中，常见的调试错误是未能...
XEP-0035: SSL/TLS Integration.pdf
08-19
1. **SSL/TLS握手**：在XMPP中，SSL/TLS的整合始于握手过程，这是客户端和服务器之间建立安全连接的第一步。在这个过程中，双方交换证书、协商加密算法和共享密钥，以确保后续的数据传输是加密的。 2. **身份验证**...
ssl_android.zip_TLS_android_android ssl_application_ssl/tls
09-20
SSL/TLS（Secure Sockets Layer/Transport Layer Security）是网络安全领域中的重要协议，主要用于保障互联网通信的安全性。在Android平台上，SSL/TLS被广泛应用于移动应用程序中，以确保用户数据的隐私和完整性。本...
带有SSL / TLS的SMTP客户端
04-08
8. 执行SSL/TLS握手：调用`SSL_connect()`启动SSL/TLS握手过程，这个过程包括证书交换、密钥协商等。 9. 发送SMTP命令：一旦握手成功，就可以使用`SSL_write()`发送SMTP命令，如HELO、AUTH、MAIL FROM、RCPT TO和...
netty实现SSL/TSL双向加密认证示例
09-21
- SSL/TLS 握手包括一系列消息交换，用于协商协议版本、加密算法、交换证书以及生成会话密钥。 - 双向认证中，服务器和客户端都会发送它们的证书，然后彼此验证。 5. **异常处理** - 如果在验证证书时出现问题，...
openssl握手过程
02-25
openssl握手过程
SSL/TLS协议四次握手
OdynO的专栏
05-09 9642
SSL/TSL协议基本过程：（1） 客户端向服务器端索要并验证公钥。 （2） 双方协商生成"对话密钥"。 （3） 双方采用"对话密钥"进行加密通信。1 客户端发出请求（ClientHello）首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。在这一步，客户端主要向服务器提供以下信息。（1） 支持的协议版本，比如TLS 1.0版。 （2） 一个客户端生成的...
SSL协议(HTTPS) 握手、工作流程详解(双向HTTPS流程)
birthmarkqiqi的专栏
08-30 2353
SSL协议的工作流程：       服务器认证阶段：1）客户端向服务器发送一个开始信息“Hello”以便开始一个新的会话连接；2）服务器根据客户的信息确定是否需要生成新的主密钥，如需要则服务器在响应客户的“Hello”信息时将包含生成主密钥所需的信息；3）客户根据收到的服务器响应信息，产生一个主密钥，并用服务器的公开密钥加密后传给服务器；4）服务器恢复该主密钥，并返回给客户一个用主密钥认证的
TLS/SSL 工作原理及握手过程详解
热门推荐
Tyler_Zx的博客
07-26 2万+
目录 前言 TLS/SSL 基础概念 密钥协商过程中存在的问题及解决办法 TLS/SSL 握手过程 前言 本文是对HTTPS 安全基础、TLS/SSL 工作原理及握手过程的总结。第一部分介绍为 HTTPS 提供安全基础的 TLS/SSL 的基础概念，及数据传输过程中密钥协商的原因。第二部分介绍密钥协商过程中存在的问题，及解决办法，其中会涉及PKI、CA 等概念。最后介绍 TLS/SSL 的握手过程。 HTTP 和 HTTPS 的区别：https://blog.csdn.net/qq_382..
TLS握手的OpenSSL实现（深度1）
好习惯成就伟大
11-30 2374
我们跳过握手的总状态机和读写状态机，因为我认为那是OpenSSL架构方案的一个败笔，逻辑非常的不清晰，是程序员思维，而不是正常的逻辑思维。与握手逻辑比较相关的在statem_clnt.c和statem_srv.c中。分别是客户端的握手逻辑和服务端的握手逻辑。 我们以服务端为重点来分析。 一个简单的函数列表就能看出来其中的大体逻辑。对于服务器来说，是被动的处理消息，响应客户端请求的一方。所以所有的发送都是有接收来触发，接收对应的函数典型的就是tls_process_开头的函数，而发送所对应的函数就是t
OpenSSL 握手过程及重要操作
冰冻三尺非一日之寒
06-24 4779
OpenSSL 握手过程及重要操作概述    大部分的网站都是支持SSL协议来保证数据在传输过程中的安全。因此了解OpenSSL握手过程及重要操作很重要。使用RSA密钥交换算法时的标准SSL握手主要步骤如下：1. Client Hello    客户端发送给服务器端需要的信息。 这些信息包括客户端SSL版本号，cipher设置，会话特定数据。对应于上图中的步骤【1】.2.Server Hello ...
SSL/TLS 握手失败怎么解决
05-13
SSL/TLS 握手失败可能由多种原因引起，如证书问题、协议版本不匹配、密码套件不支持等。以下是一些可能的解决方法： 1. 检查证书是否有效，是否过期或被撤销。 2. 检查服务器和客户端的协议版本是否匹配。如果服务器不支持客户端请求的协议版本，则握手可能会失败。在这种情况下，可以尝试使用较旧的协议版本或更新服务器以支持新的协议版本。 3. 检查密码套件，确保服务器和客户端都支持相同的密码套件。如果密码套件不匹配，则握手可能会失败。 4. 确保服务器的时间和日期正确。如果服务器的时间和日期不正确，则证书可能会被认为是无效的，从而导致握手失败。 5. 检查防火墙和代理服务器设置，确保它们不会阻止 SSL/TLS 握手流量。 如果以上方法不起作用，则可能需要进一步调试和排除故障。可以查看服务器和客户端的日志文件，以获取更多详细信息，并在必要时咨询网络安全专家。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值