tls 订阅
安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。 展开全文
安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。
信息
外文名
Transport Layer Security
简    称
TLS
中文名
安全传输层协议
TLS简介
传输层安全性协议(英语:Transport Layer Security,缩写作TLS),及其前身安全套接层(Secure Sockets Layer,缩写作SSL)是一种安全协议,目的是为互联网通信提供安全及数据完整性保障。网景公司(Netscape)在1994年推出首版网页浏览器,网景导航者时,推出HTTPS协议,以SSL进行加密,这是SSL的起源。IETF将SSL进行标准化,1999年公布第一版TLS标准文件。随后又公布RFC 5246 (2008年8月)与RFC 6176(2011年3月)。在浏览器、邮箱、即时通信、VoIP、网络传真等应用程序中,广泛支持这个协议。主要的网站,如Google、Facebook等也以这个协议来创建安全连线,发送数据。目前已成为互联网上保密通信的工业标准。SSL包含记录层(Record Layer)和传输层,记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证,之后利用非对称加密演算来对通信方做身份认证,之后交换对称密钥作为会谈密钥(Session key)。这个会谈密钥是用来将通信两方交换的数据做加密,保证两个应用间通信的保密性和可靠性,使客户与服务器应用之间的通信不被攻击者窃听。 [1] 
收起全文
精华内容
参与话题
问答
  • TLS

    2019-02-23 20:13:38
    该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。 简介  传输层安全性协议(英语:Transport Layer Security,缩写作TLS),及其前身安全套接层(Secure Sockets Layer,缩...

          安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。

    简介

          传输层安全性协议(英语:Transport Layer Security,缩写作TLS),及其前身安全套接层(Secure Sockets Layer,缩写作SSL)是一种安全协议,目的是为互联网通信提供安全及数据完整性保障。网景公司(Netscape)在1994年推出首版网页浏览器,网景导航者时,推出HTTPS协议,以SSL进行加密,这是SSL的起源。

          IETF(国际互联网工程任务组)将SSL进行标准化,1999年公布第一版TLS标准文件。随后又公布RFC 5246(2008年8月)与RFC 6176(2011年3月)。在浏览器、邮箱、即时通信、VoIP、网络传真等应用程序中,广泛支持这个协议。主要的网站,如Google、Facebook等也以这个协议来创建安全连线,发送数据。目前已成为互联网上保密通信的工业标准。

          SSL包含记录层(Record Layer)和传输层,记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509(密码学里公钥证书的格式标准)认证,之后利用非对称加密演算来对通信方做身份认证,之后交换对称密钥作为会谈密钥(Session key)。这个会谈密钥是用来将通信两方交换的数据做加密,保证两个应用间通信的保密性和可靠性,使客户与服务器应用之间的通信不被攻击者窃听。

    概论

          TLS协议采用主从式架构模型,用于在两个应用程序间透过网络创建起安全的连线,防止在交换数据时受到窃听及篡改。

          TLS协议的优势是与高层的应用层协议(如HTTP、FTP、Telnet等)无耦合。应用层协议能透明地运行在TLS协议之上,由TLS协议进行创建加密通道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密,从而保证通信的私密性。

          TLS协议是可选的,必须配置客户端和服务器才能使用。主要有两种方式实现这一目标:一个是使用统一的TLS协议通信端口(例如:用于HTTPS的端口443);另一个是客户端请求服务器连接到TLS时使用特定的协议机制(例如:邮件、新闻协议和STARTTLS)。一旦客户端和服务器都同意使用TLS协议,他们通过使用一个握手过程协商出一个有状态的连接以传输数据。通过握手,客户端和服务器协商各种参数用于创建安全连接:

          1、当客户端连接到支持TLS协议的服务器要求创建安全连接并列出了受支持的密码组合(加密密码算法和加密哈希函数),握手开始。

          2、服务器从该列表中决定加密和散列函数,并通知客户端。

          3、服务器发回其数字证书,此证书通常包含服务器的名称、受信任的证书颁发机构(CA)和服务器的公钥。

          4、客户端确认其颁发的证书的有效性。

          5、为了生成会话密钥用于安全连接,客户端使用服务器的公钥加密随机生成的密钥,并将其发送到服务器,只有服务器才能使用自己的私钥解密。

          6、利用随机数,双方生成用于加密和解密的对称密钥。这就是TLS协议的握手,握手完毕后的连接是安全的,直到连接(被)关闭。如果上述任何一个步骤失败,TLS握手过程就会失败,并且断开所有的连接。

    发展历史

    协议 年份
    SSL 1.0 未知
    SSL 2.0 1995
    SSL 3.0 1996
    TLS 1.0 1999
    TLS 1.1 2006
    TLS 1.2 2008
    TLS 1.3 2018

    TLS 1.3在RFC 8446中定义,于2018年8月发表。它基于更早的TLS 1.2规范,与TLS 1.2的主要区别包括:

           1、将密钥协商和认证算法从密码包中分离出来。

           2、移除脆弱和较少使用的命名椭圆曲线支持(参见椭圆曲线密码学)。

           3、移除MD5和SHA-224密码散列函数的支持。

           4、请求数字签名,即便使用之前的配置。

           5、集成HKDF和半短暂DH提议。

           6、替换使用PSK和票据的恢复。

           7、支持1-RTT握手并初步支持0-RTT。

           8、通过在(EC)DH密钥协议期间使用临时密钥来保证完善的前向安全性。

           9、放弃许多不安全或过时特性的支持,包括数据压缩、重新协商、非AEAD密码本、静态RSA和静态DH密钥交换、自定义DHE分组、点格式协商、更改密码本规范的协议、UNIX时间的Hello消息,以及长度字段AD输入到AEAD密码本。

          10、禁止用于向后兼容性的SSL和RC4协商。

          11、集成会话散列的使用。

          12、弃用记录层版本号和冻结数以改进向后兼容性。

          13、将一些安全相关的算法细节从附录移动到标准,并将ClientKeyShare降级到附录。

          14、添加带有Poly1305消息验证码的ChaCha20流加密。

          15、添加Ed25519和Ed448数字签名算法。

          16、添加x25519和x448密钥交换协议。

          17、将支持加密服务器名称指示(EncryptedServerNameIndication, ESNI)。

           网络安全服务(NSS)是由Mozilla开发并由其网络浏览器Firefox使用的加密库,自2017年2月起便默认启用TLS 1.3。随后TLS 1.3被添加到2017年3月发布的Firefox 52.0中,但它由于某些用户的兼容性问题,默认情况下禁用。直到Firefox 60.0才正式默认启用。

    算法

    密钥交换和密钥协商:

          在客户端和服务器开始交换TLS所保护的加密信息之前,他们必须安全地交换或协定加密密钥和加密数据时要使用的密码。用于密钥交换的方法包括:使用RSA算法生成公钥和私钥(在TLS握手协议中被称为TLS_RSA),Diffie-Hellman(在TLS握手协议中被称为TLS_DH),临时Diffie-Hellman(在TLS握手协议中被称为TLS_DHE),椭圆曲线Diffie-Hellman(在TLS握手协议中被称为TLS_ECDH),临时椭圆曲线Diffie-Hellman(在TLS握手协议中被称为TLS_ECDHE),匿名Diffie-Hellman(在TLS握手协议中被称为TLS_DH_anon)和预共享密钥(在TLS握手协议中被称为TLS_PSK)。

          TLS_DH_anon和TLS_ECDH_anon的密钥协商协议不能验证服务器或用户,因为易受中间人攻击因此很少使用。只有TLS_DHE和TLS_ECDHE提供前向保密能力。

          在交换过程中使用的公钥/私钥加密密钥的长度和在交换协议过程中使用的公钥证书也各不相同,因而提供的强健性的安全2013年7月,Google宣布向其用户提供的TLS加密将不再使用1024位公钥并切换到2048位,以提高安全性。

     

    展开全文
  • tls

    2017-06-24 16:55:33
    tls的原理在于用非对称加密方法,建立对称加密通道。 由非对称公钥加密对称钥匙防止钥匙泄露,由数字证书确定对端身份,由数字签名防止篡改。

    tls的原理在于用非对称加密方法,建立对称加密通道。

    由非对称公钥加密对称钥匙防止钥匙泄露,由数字证书确定对端身份,由数字签名防止篡改。


    展开全文
  • SSL/TLS 双向认证(一) -- SSL/TLS 工作原理

    万次阅读 多人点赞 2017-08-04 17:58:27
    本文部分参考: https://www.wosign.com/faq/faq2016-0309-03.htm https://www.wosign.com/faq/faq2016-0309-04.htm ... 一: SSL/TLS介绍 什么是SSL,什么是TLS呢?官话说SSL是安全套...

    本文部分参考:
    https://www.wosign.com/faq/faq2016-0309-03.htm
    https://www.wosign.com/faq/faq2016-0309-04.htm
    http://blog.csdn.net/hherima/article/details/52469674

    一: SSL/TLS 介绍

    什么是 SSL, 什么是 TLS 呢?官话说 SSL 是安全套接层(secure sockets layer),TLS 是 SSL 的继任者,叫传输层安全(transport layer security)。说白点,就是在明文的上层和 TCP 层之间加上一层加密,这样就保证上层信息传输的安全。如HTTP 协议是明文传输,加上 SSL 层之后,就有了雅称 HTTPS。它存在的唯一目的就是保证上层通讯安全的一套机制。它的发展依次经历了下面几个时期,像手机软件升级一样,每次更新都添加或去除功能,比如引进新的加密算法,修改握手方式等。

    SSL1.0: 已废除
    SSL2.0: RFC6176, 已废除
    SSL3.0: RFC6101, 基本废除
    TLS1.0: RFC2246, 少数古董服务器仍在使用
    TLS1.1: RFC4346
    TLS1.2: RFC5246, 目前已广泛使用
    TLS1.3: IETF正在酝酿中
    下面我们将介绍 TLS1.x 如何保证通讯安全。


    二: CA & SSL Server & SSL Client 介绍

    如何保证安全呢?你说安全就安全吗,究竟是怎么实现的呢?绝对安全吗?

    哈,有人的地方就有江湖,有江湖的地方就没有绝对的安全。但 SSL/TLS 确实可以极大程度保证信息安全。
    下面根据图一 SSL/TLS 工作流来一览实现过程。

    2.1 SSL/TLS 工作流

    SSL workflow

    图一 SSL/TLS 工作流

    Q1: CA 介绍

    CA: 证书授权中心(certificate authority)
    它呢,类似于国家出入境管理处一样,给别人颁发护照;
    也类似于国家工商管理局一样,给公司/企业颁发营业执照。

    CA 有两大主要性质:

    • CA 本身是受信任的 (国际认可的)
    • 给他受信任的申请对象颁发证书

    和办理护照一样,要确定你的合法身份,你不能是犯罪分子或造反派。当然,你需要被收保护费,同时,CA 机构可以随时吊销你的证书。

    Q2: CA 证书长啥样

    其实你的电脑中有一堆证书。你可以看一看嘛:

    • 360 浏览器: 选项/设置-> 高级设置 -> 隐私于安全 -> 管理 HTTPS/SSL 证书 -> 证书颁发机构
    • 火狐浏览器: 首选项 -> 高级 -> 证书 -> 查看证书 -> 证书机构
    • chrome浏览器: 设置 -> 高级 -> 管理证书 -> 授权中心
    • ubuntu: /etc/ssl/certs/xxx_CA.pem (或 xxx_Certification_Authority.pem)

    这些都是 CA 的证书!

    Q3: CA 的证书 ca.crt 和 SSL Server 的证书 server.crt 是什么关系呢

    1. SSL Server 自己生成一个私钥/公钥对。server.key/server.pub // 私钥加密,公钥解密!
    2. server.pub 生成一个请求文件 server.req. 请求文件中包含有 server 的一些信息,如域名/申请者/公钥等。
    3. server 将请求文件 server.req 递交给 CA 机构,CA 机构验明正身后,将用 ca.key 和请求文件加密生成 server.crt
    4. 由于 ca.key 和 ca.crt 是一对, 于是 ca.crt 可以解密 server.crt.

    Q4: 举例说明

    如果 SSL Client 想要校验 SSL server. 那么 SSL server 必须要将他的证书 server.crt 传给 client. 然后 client 用 ca.crt 去校验 server.crt 的合法性。
    如果 server 是一个钓鱼网站,那么 CA 是不会给他颁发合法 server.crt 证书的,这样 client 用 ca.crt 去校验,就会失败。
    比如浏览器作为一个 SSL Client,你想访问合法的淘宝网站 https://www.taobao.com, 结果不慎访问到 https://wwww.jiataobao.com, 那么浏览器将会检验到这个假淘宝钓鱼网站的非法性,提醒用户不要继续访问!这样就可以保证 client 的所有 https 访问都是经过安全检查的。

    2.2 不认证 & 单向认证 & 双向认证

    何为 SSL/TLS 单向认证,双向认证?

    单向认证:指的是只有一个对象校验对端的证书合法性
    通常是客户端来校验服务器的合法性。那么 client 需要一个 ca.crt, 服务器需要 server.crt, server.key

    例如:浏览器校验各个 HTTPS 网站的合法性。如果导航栏有绿色的小锁,说明网站合法;如果是红色小锁,说明该网站证书校验不过。

    也可以是服务器来校验客户端的合法性。那么 server 需要一个 ca.crt, 客户端需要 client.crt, client.key

    例如: 亚马逊物联网平台(AWS IoT) 给每个设备颁发证书,所有设备要想连接上 AWS, 必须使用其提供的客户端证书

    双向认证:指的是相互校验,服务器需要校验每个 client 证书, client 也需要校验服务器证书
    server 需要 server.key 、server.crt 、ca.crt
    client 需要 client.key 、client.crt 、ca.crt

    不认证:指的是不相互校验证书,但仍然使用 TLS 连接

    证书校验只是 TLS 连接过程中的一小步

    2.3 证书详细工作流

    证书工作流

    图二 证书详细工作流

    1)申请认证:服务器需自己生成公钥私钥对pub_svr & pri_svr,同时根据 pub_svr 生成请求文件 csr, 提交给 CA 机构,csr 中含有公钥、组织信息、个人信息(域名)等信息。(图一中 server.req 就是 csr 请求文件)

    2)审核信息:CA 机构通过线上、线下等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的所有权等。

    3)签发证书:如信息审核通过,CA 机构会向申请者签发认证文件-证书。
    证书包含以下信息:申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文,同时包含一个签名。
    签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,然后,采用 CA 的私钥对信息摘要进行加密,密文即签名。(图一中生成 server.crt)

    4)返回证书:client 如果请求验证服务器,服务器需返回证书文件。(图一中 handshake 传回 server.crt)

    5)client验证证书:client 读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后,利用对应 CA 的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性,即公钥合法。客户端然后验证证书相关的域名信息、有效时间是否吊销等信息。
    客户端会内置信任 CA 的证书信息(包含公钥),如果 CA 不被信任,则找不到对应 CA 的证书,证书也会被判定非法。(图一中check 可选,我们可以选择不验证服务器证书的有效性)

    6)秘钥协商:验证通过后,Server 和 Client 将进行秘钥协商。接下来 Serve r和 Client 会采用对称秘钥加密。(对称加密时间性能优)(图一中 pre-master/change_cipher_spec/encrypted_handshake_message 过程)

    7)数据传输:SSL Server 和 SSL Client 采用对称秘钥加密解密数据。

    2.4 SSL/TLS单向认证流程

    单项认证

    (1) client_hello

    客户端发起请求,以明文传输请求信息,包含版本信息,加密套件候选列表,压缩算法候选列表,随机数,扩展字段等信息,相关信息如下:

    • 支持的最高 TLS 协议版本 version,从低到高依次 SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2, 当前基本不再使用低于 TLSv1 的版本
    • 客户端支持的加密套件 cipher suites 列表, 每个加密套件对应前面 TLS 原理中的四个功能的组合:
      • 认证算法 Au (身份验证)
      • 密钥交换算法 KeyExchange(密钥协商)
      • 对称加密算法 Enc (信息加密)
      • 信息摘要 Mac(完整性校验)
    • 支持的压缩算法 compression methods 列表,用于后续的信息压缩传输
    • 随机数 random_C,用于后续的密钥的生成
    • 扩展字段 extensions,支持协议与算法的相关参数以及其它辅助信息等,常见的 SNI 就属于扩展字段,后续单独讨论该字段作用

    (2) server_hello + server_certificate + sever_hello_done

    • server_hello, 服务端返回协商的信息结果,包括选择使用的协议版本 version,选择的加密套件 cipher suite,选择的压缩算法 compression method、随机数 random_S 等,其中随机数用于后续的密钥协商;
    • server_certificates, 服务器端配置对应的证书链,用于身份验证与密钥交换;
    • server_hello_done,通知客户端 server_hello 信息发送结束;

    (3) 证书校验

    • [证书链]的可信性 trusted certificate path,方法如前文所述;
    • 证书是否吊销 revocation,有两类方式离线 CRL 与在线 OCSP,不同的客户端行为会不同;
    • 有效期 expiry date,证书是否在有效时间范围;
    • 域名 domain,核查证书域名是否与当前的访问域名匹配,匹配规则后续分析;

    (4) client_key_exchange + change_cipher_spec + encrypted_handshake_message

    • client_key_exchange,合法性验证通过之后,客户端计算产生随机数字 Pre-master,并用证书公钥加密,发送给服务器;
    • 此时客户端已经获取全部的计算协商密钥需要的信息:两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master,计算得到协商密钥;
      enc_key=Fuc(random_C, random_S, Pre-Master)
    • change_cipher_spec,客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;
    • encrypted_handshake_message,结合之前所有通信参数的 hash 值与其它相关信息生成一段数据,采用协商密钥 session secret 与算法进行加密,然后发送给服务器用于数据与握手验证

    (5) change_cipher_spec + encrypted_handshake_message

    • 服务器用私钥解密加密的 Pre-master 数据,基于之前交换的两个明文随机数 random_C 和 random_S,计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);
    • 计算之前所有接收信息的 hash 值,然后解密客户端发送的 encrypted_handshake_message,验证数据和密钥正确性;
    • change_cipher_spec, 验证通过之后,服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;
    • encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端;

    (6) 握手结束

    客户端计算所有接收信息的 hash 值,并采用协商密钥解密 encrypted_handshake_message,验证服务器发送的数据和密钥,验证通过则握手完成

    (7) 加密通信

    开始使用协商密钥与算法进行加密通信。

    2.5 实际 wireshark 分析

    这里写图片描述
    我们搭建的 SSL/TLS 服务器是192.168.111.100, client 是192.168.111.101. client 需要认证 server的合法性。
    我们只看 TLSv1.1 的数据包:
    第一包(No. 25) Client Hello 包,即SSL/TLS单向认证流程的(1)
    第二包(No. 27) Server Hello 包,包含服务器证书等。即SSL/TLS单向认证流程的(2)
    第三包(No. 28) 服务器证书验证完成,同时发送 client key exchange+change cipher spec + encrypted handshake message.即 SSL/TLS 单向认证流程的(4)
    第四包(No. 29)秘钥协商,change cipher spec + encrypted hanshake message.即 SSL/TLS 单向认证流程的(5)
    第五包(No. 30)握手完成。开始上层数据传输。SSL/TLS 单向认证流程的(7)

    2.6 SSL/TLS双向认证流程

    和单向认证几乎一样,只是在 client 认证完服务器证书后,client 会将自己的证书 client.crt 传给服务器。服务器验证通过后,开始秘钥协商。

    实际 wireshark 分析:
    这里写图片描述

    和单向认证一样:
    我们搭建的 SSL/TLS 服务器是 192.168.111.100, client是192.168.111.101. client 需要认证 server 的合法性,server 也需要认证 client 的合法性

    我们只看 TLSv1.1 的数据包:
    第一包(No. 55) Client Hello 包,即 SSL/TLS 单向认证流程的(1)
    第二包(No. 57) Server Hello 包,包含服务器证书等。即 SSL/TLS 单向认证流程的(2)
    第三包(No. 60) 服务器证书验证完成,同时发送客户端的证书 client.crt ,同时包含 client key exchange+change cipher spec + encrypted handshake message. 即 SSL/TLS 单向认证流程的(4)
    第四包(No. 61)**服务器验证客户端证书的合法性。**通过后进行秘钥协商,change cipher spec + encrypted hanshake message.即 SSL/TLS 单向认证流程的(5)
    重传包(No. 62)由于网络原因,TCP 重传第No. 60包。
    第五包(No. 64)握手完成,开始上层数据传输。SSL/TLS 单向认证流程的(7)

    2.7 证书等格式说明

    crt/key/req/csr/pem/der等拓展名都是什么东东?

    .crt 表示证书, .key 表示私钥, .req 表示请求文件,.csr 也表示请求文件, .pem 表示 pem 格式,.der 表示 der 格式。

    文件拓展名你可以随便命名,只是为了理解需要而命名不同的拓展名。但文件中的信息是有格式的,和 exe,PE 格式一样。

    证书有两种格式:pem 格式和 der 格式

    所有证书,私钥等都可以是 pem, 也可以是 der 格式,取决于应用需要。
    pem 和 der 格式可以互转:

    openssl x509 -in ca.crt -outform DER -out ca.der  # pem -> der
    openssl x509 -inform der -in ca.der -out ca.pem   # der -> pem
    

    pem 格式:经过加密的文本文件,一般有下面几种开头结尾:

    	-----BEGIN RSA PRIVATE KEY-----
    	-----END RSA PRIVATE KEY-----
    	or:
       -----BEGIN CERTIFICATE REQUEST-----
       -----END CERTIFICATE REQUEST-----
    	or:
       ----BEGIN CERTIFICATE-----
      -----END CERTIFICATE-----
    

    der 格式: 经过加密的二进制文件。

    如何查看证书中有什么

    证书中含有 申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文,同时包含一个签名。如查看百度证书详细信息。

    a) 先下载百度证书
    火狐浏览器访问https://www.baidu.com/, 点击左上角绿色小锁,点击向右箭头,点击更多信息,点击查看证书,点击详细信息,点击导出。即可导出百度的证书 baiducom.crt

    b) 命令查看证书详细信息

    openssl x509 -noout -text -in baiducom.crt
    

    baiducert

    详细信息中,有一个字段: X509v3 Basic Constraints: CA: FALSE
    该字段指出该证书是否是 CA 证书,还是一般性的非 CA 证书。详细描述见 RFC5280#section-4.2.1.9,同时 RFC5280 也详细描述证书工作方式等。

    1. 私钥加密,公钥解密!

    2.8 SSL/TLS 和 OpenSSL, mbedTLS 是什么关系

    SSL/TLS 是一种工作原理,OpenSSL 和 mbedTLS 是 SSL/TLS 的具体实现,很类似于 TCP/IP 协议和 socket 之间的关系。

    三: 本地生成SSL相关文件

    3.1 证书生成脚本

    我们自己本地使用 makefile.sh 脚本建立一个CA(ca.crt + ca.key),用这个 CA 给 server 和 client 分别颁发证书。

    makefile.sh

    # * Redistributions in binary form must reproduce the above copyright
    #   notice, this list of conditions and the following disclaimer in the
    #   documentation and/or other materials provided with the distribution.
    # * Neither the name of the axTLS project nor the names of its
    #   contributors may be used to endorse or promote products derived
    #   from this software without specific prior written permission.
    #
    # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
    # "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
    # LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 
    # A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
    # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
    # SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
    # TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
    # DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY 
    # OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
    # NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
    # THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    #
    
    #
    # Generate the certificates and keys for testing.
    #
    
    
    PROJECT_NAME="TLS Project"
    
    # Generate the openssl configuration files.
    cat > ca_cert.conf << EOF  
    [ req ]
    distinguished_name     = req_distinguished_name
    prompt                 = no
    
    [ req_distinguished_name ]
     O                      = $PROJECT_NAME Dodgy Certificate Authority
    EOF
    
    cat > server_cert.conf << EOF  
    [ req ]
    distinguished_name     = req_distinguished_name
    prompt                 = no
    
    [ req_distinguished_name ]
     O                      = $PROJECT_NAME
     CN                     = 192.168.111.100
    EOF
    
    cat > client_cert.conf << EOF  
    [ req ]
    distinguished_name     = req_distinguished_name
    prompt                 = no
    
    [ req_distinguished_name ]
     O                      = $PROJECT_NAME Device Certificate
     CN                     = 192.168.111.101
    EOF
    
    mkdir ca
    mkdir server
    mkdir client
    mkdir certDER
    
    # private key generation
    openssl genrsa -out ca.key 1024
    openssl genrsa -out server.key 1024
    openssl genrsa -out client.key 1024
    
    # cert requests
    openssl req -out ca.req -key ca.key -new \
                -config ./ca_cert.conf
    openssl req -out server.req -key server.key -new \
                -config ./server_cert.conf 
    openssl req -out client.req -key client.key -new \
                -config ./client_cert.conf 
    
    # generate the actual certs.
    openssl x509 -req -in ca.req -out ca.crt \
                -sha1 -days 5000 -signkey ca.key
    openssl x509 -req -in server.req -out server.crt \
                -sha1 -CAcreateserial -days 5000 \
                -CA ca.crt -CAkey ca.key
    openssl x509 -req -in client.req -out client.crt \
                -sha1 -CAcreateserial -days 5000 \
                -CA ca.crt -CAkey ca.key
     
    openssl x509 -in ca.crt -outform DER -out ca.der
    openssl x509 -in server.crt -outform DER -out server.der
    openssl x509 -in client.crt -outform DER -out client.der
    
    mv ca.crt ca.key ca/
    mv server.crt server.key server/
    mv client.crt client.key client/
    
    mv ca.der server.der client.der certDER/
    
    rm *.conf
    rm *.req
    rm *.srl 
    

    将上述代码保存为 makefile.sh
    做如下修改,终端执行。

    - 修改 CN 域中 IP 地址为你主机/设备的 IP 地址
    - [可选]加密位数 1024 修改为你需要的加密位数

    将会看到:
    ssldir

    ca目录:保存 ca 的私钥 ca.key 和证书 ca.crt
    certDER目录:将证书保存为二进制文件 ca.der, client.der, server.der
    client目录: client.crt, client.key
    server目录:server.crt, server.key

    3.2 删除脚本

    makefile.sh

    rm ca/ -rf
    rm certDER/ -rf
    rm client/ -rf
    rm server/ -rf
    

    将上述代码保存为 rmfile.sh, 终端执行,将会删除产生过的目录和文件:

    ./rmfile.sh
    

    3.3 CA 校验证书测试

    我们可在本地使用 CA 证书来分别校验由自己颁发的服务器证书 server.crt 和客户端证书 client.crt

    $openssl verify -CAfile ca/ca.crt server/server.crt
    
    $openssl verify -CAfile ca/ca.crt client/client.crt
    

    verify

    展开全文
  • TLS 1.3

    2021-01-12 02:57:02
    <p>Just wondering whether it makes sense to have a test for TLS 1.3. Is there any server out there yet? <p>None that I've been able to test against. ...
  • TLS安全说明

    2018-01-12 14:52:18
    TLS安全说明 TLS安全说明TLS安全说明 TLS安全说明TLS安全说明
  • TLS 1.3 协议详解

    万次阅读 热门讨论 2018-08-09 10:46:08
    TLS 1.3 握手流程详解 需要的背景知识: (1):对 TLS 1.2 协议有一定程度的了解,包括秘钥交换、会话复用等。 第一节 TLS 1.3 的握手概述 协议分析的第一步就是看报文。TLS 1.3的报文,有个特点,就是通过抓...

    TLS 1.3 握手流程详解

    我的TLS实现(支持TLS1.3和国密SSL),大家可以学习参考:https://github.com/mrpre/atls/
    如果觉得有用,请打赏N元:http://39.98.242.44

    需要的背景知识:
    (1):对 TLS 1.2 协议有一定程度的了解,包括秘钥交换、会话复用等。

    第一节 TLS 1.3 的握手概述

    协议分析的第一步就是看报文。TLS 1.3的报文,有个特点,就是通过抓包发现,只能看到明文的Client HelloServer Hello,其余的握手报文均被加密。

    1-RTT

    如图:

    图1
    这里写图片描述

    条件:无条件(如果client发送的keyshare类型是server不支持,那就不是1-RTT了,此处忽略)
    换句话说,TLS 1.3 正常情况下,第一次握手就是1-RTT的。(而TLS 1.3之前的协议只有第二次及其之后的握手且session resume成功后,才有1-RTT)。其次1-RTT又分为两种情况,一种是完整的握手(新的握手,就是上面图1所示),还有一种是不发送early data的PSK握手(可以理解为session 复用),如下图:

    图2
    这里写图片描述
    可见,图2 相对 图1,server少发送了诸多报文(熟悉TLS协议的肯定能猜到,至少是少发了server的证书,好几k的数据)。话句话说,TLS 1.3,PSK handshake和FULL handshake都是1-RTT,而所谓的0-RTT是建立在PSK handshake基础上的,下面就说说0-RTT。

    0-RTT

    如图3:
    图3
    这里写图片描述
    上面第一行,Application Data就是应用数据了,换句话说0-rtt就是在client-hello时就把应用数据捎带发给server(当然,server会根据自己的设置选择相信这个数据,也可以拒绝这个数据)
    条件:
    (1)之前已经有一次握手,并且server发送了session ticket。且session ticket中存在max_early_data_size拓展表示愿意接受early data。很好理解,0-rtt是基于session 复用的,所以肯定之前已经完成一次握手,且那次握手携带了session ticket以方便下一次握手时完成复用。

    (2)第二次握手时,client 发送了psk(其实就是session ticket外加一些检验的东西),server处理session ticket 会话复用成功,即server从client发送的psk中提恢复出了session。

    (3)第二次握手时,client 配置了发送 early data,表象就是如上图,Client Hello后面紧跟ccsccs后面紧跟application data(ccs不是必须的),且Client Hello 中的拓展中early data拓展表示会发送early data

    (3)第二次握手时,server配置了允许读取early data,且client行为如(2)。表象就是server的Encrypted Extensions中携带了early data拓展表示自己会读取early data。 如果 server没有配置读取early data的选项,那么server就会忽略client发送的Application data。client 需要在应用层主动ssl_write应用数据(通常库函数肯定会告诉你early data有没有被处理)。

    综上所述,0-RTT的要求还是蛮严格的,首先第一次握手时,server表示愿意读取early data,其次第二次握手时,会话复用成功,接着客户端表示会发early data且server表示自己会读取early data

    第二节 TLS 1.3 1-RTT 流程

    第一节中,我们已经看到了TLS 1.3的报文,可惜的是,握手报文是被加密的,看不出什么东西,不知道发了什么东西。本节将描述TLS 1.3下的诸多改进,以及详细的TLS 1.3 的报文。

    1-RTT 概述

    (1)TLS 1.3 相较于之前的版本,多了许多握手类型报文,比如Encrypted Extensions End of early data等。
    (2)除了Client HelloServer Hello其余报文全部都被加密,这就导致了你无法从wireshark的抓包结果中学习。
    (3)server 发送 certificate verify。之前协议中,只有客户端认证时,client才会发送certificate verify

    上述这些都是比较明显的区别,不明显的区别后文会一一阐述。

    接下来先回顾老的协议,再说新的协议。

    TLS 1.3之前的握手流程

    首先回忆一下,TLS 1.3 之前是如何秘钥交换的。

    这里简单的描述下 TLS 1.3 之前协议的秘钥交换流程,以及其缺点

    RSA 秘钥交换
    1:client 发起请求(Client Hello
    2:server 回复 certificate
    3:client使用证书中的公钥,加密预主秘钥,发给 server(Client Key Exchange
    4:server 提取出 预主秘钥,计算主秘钥,然后发送对称秘钥加密的finished
    5:client 计算主秘钥,验证 finished,验证成功后,就可以发送Application Data了。

    缺点:RSA秘钥交换不是前向安全算法(证书对应私钥泄漏后,之前抓包的报文都能被解密)。

    所以在 TLS 1.3中 RSA 已经废弃了。

    ECDHE秘钥交换
    1:client 发送请求(Client Hello),extension携带支持的椭圆曲线类型。
    2:server 回复 Server Hellocertificate等;server选择的椭圆曲线参数,然后 生成私钥(BIGNUM),乘以椭圆曲线的base point得到公钥(POINT),顺便签个名表示自己拥有证书,然后将报文发给client,报文就是Server Key Exchange,其包含了server选择的椭圆曲线参数、自己根据这个参数计算的公钥、自己用证书的私钥对当前报文的签名。
    3:client 收到 Server Key Exchange,获得椭圆曲线参数,生成私钥(BIGNUM)后计算公钥(POINT),然后把公钥发出去Client Key Exchange。client使用自己的私钥(BIGNUM)和server的公钥(POINT)计算出主秘钥。
    4:server 收到 client的公钥(POINT),使用自己的私钥(BIGNUM),计算主秘钥。两端主秘钥是一致。

    缺点:
    client发送自己支持的椭圆曲线类型,然后等待server选择后,才计算自己的公钥然后发送给server。这个可以优化。

    TLS 1.3 中是这样优化握手的:
    1:client 发送请求(Client Hello),extension携带支持的椭圆曲线类型。且对每个自己支持的椭圆曲线类型计算公钥(POINT)。公钥放在extension中的keyshare中。
    2:server 回复 Server Hellocertificate等;server选择的椭圆曲线参数,然后乘以椭圆曲线的base point得到公钥(POINT)。然后提取Client Hello中的key_share拓展中对应的公钥,计算主秘钥。公钥(POINT)不再和之前的以协议一样放在Server Key Exchange中,而是放在Server Hellokey_share拓展中。client收到server的公钥(POINT)后计算主秘钥。

    所以在TLS 1.3 中最显著的变化,也即上文说的无条件的1-RTT就是基于对握手协商的优化生。

    所以,Client 相当于计算了多种可能情况下server会使用的ecdhe参数,然后根据这些参数计算公钥提前发给server = =(为了追求rtt,也是绝了),你让那种嵌入式的客户端怎么办。

    完整的 TLS 1.3 1-RTT描述

    由于TLS 1.3几乎所有的报文都被加密,不好分析这里使用了写手段,将其解密开来,好可以在wireshark中进行直观的分析(修改方法:找一套开源代码,将其加解密流程bypass,然后用这套代码,起一个server和client,例如在OpenSSL中,我将加解密用的ctx全部强制置为NULL,保证了加解密都bypass)。
    顺便提一句,一张证书链怎么也得2、3k,这比通常的应用数据都长,原先传输证书是没有加密的,而TLS 1.3是加密的 = = 真把服务器当牛来用
    其流程如下图(解密后的):

    这里写图片描述

    Full handshake

    1:client发送Client Hello,携带如下几个重要信息
    (1):支持的加密套件(该作用和之前一样)。
    (2):supproted_versions 拓展。包含自己支持的TLS协议版本号。(之前协议没有)
    (3):supproted_groups 拓展,表示自己支持的椭圆曲线类型。
    (4):key_share拓展。包含supprot_groups中各椭圆曲线对应的public key。(当然可以发送空的,然后server会回复hello request,其中会包含server的key_share,可以用来探测,这里不讨论)。key_share中的椭圆曲线类型必须出现在supproted_groups中。(之前协议没有)

    2:server 发送Server Hello,携带如下几个重要信息
    (1):supproted_versions 拓展。包含自己从client的supproted_versions中选择的TLS协议版本号。(之前协议没有)
    (2):key_share拓展。包含自己选中的椭圆曲线,以及自己计算出来的公钥。(之前协议没有)

    3:server 发送Change Cipher Spec。(允许不发送)

    4:server发送Encrypted Extension。(加密的)
    (1:):ServerHello之后必须立刻发送Encrypted Extension。这是第一个被加密的数据数据。显然,放在这里的拓展,是和秘钥协商没关系的拓展。(之前协议没有)

    5:server发送Certificate。(加密的)
    这个报文和之前的协议没有太大区别,唯一的区别就是,在证书链中的每个证书后面,都有一个extension。(双向认证时也会有区别,有机会再说)。这个extension目前只能是OCSP Status extensionSignedCertificateTimestamps

    6:server发送Certificate Verify(加密的)
    这个报文并不陌生,但是以前只出现在双向认证(客户端认证)中,以前Certificate Verify生成的逻辑是将当前所有的握手报文解析解析签名(简单的md+非对称加密)。而在TLS 1.3中,这个计算有些变化,但是还是很简单。计算逻辑如下:

        u8 *p = tbs[BUFFER_SIZE];
    
        memset(p, 0x20, 64);
        p += 64;
        memcpy(p, "TLS 1.3, server CertificateVerify", 33);
        p += 33;
        *p ++ = 0;
        HASH(ALL_HANDSHKE, ALL_SIZE, P);
        p += md_size;
    
        SIGN(tbs)
    

    而TLS 1.2的计算是这样的:

        SIGN(HASH(ALL_HANDSHKE, ALL_SIZE));
    

    7:server回复Finished(加密的)
    这个报文的目的和之前协议一样,检验握手报文的完整性。但是计算方法有变化。
    TLS 1.3 的计算方法,先计算md,然后计算hamc,其中finishkey详细如何生成见key_derive。

        buffer = HMAC(HASH(ALL_HANDSHKE, finishkey)
        buffer 前添加握手报文类型+长度
        加密_send(buffer)
    

    TLS 1.2是这样计算的

        buffer = prf("server finished" + HASH(ALL_HANDSHKE))
        buffer 前添加握手报文类型+长度
        加密_send(buffer)
    

    8:client发送Change Cipher Spec。(允许不发送)

    9:client发送 Finished(加密的)
    同7。

    10:server发送New Session Ticket(可选,0-RTT 依赖次报文)
    若server表明自己有能力读取0-RTT,则会在New Session Ticket后面添加一个max_early_data_size拓展。

    整个流程的目的和TLS 1.2是相似的,就是为了交换椭圆曲线参数。和之前不一样的就是,无非就是提前把所有的公钥计算了一遍,发给server,server再挑选。

    PSK handshake

    我还是习惯于叫会话复用。其流程如下图(解密后的)

    这里写图片描述
    1:client发送Client Hello,除了Full handshake中提到的携带的拓展以外还包含如下字段:
    (1):psk_key_exchange_modes,目前只有psk_dhe_ke才能跑的通。
    (2):pre_shared_key拓展,其实就是New Session Ticket+binders,由于TLS 1.3 中,Server的New Session Ticket可以在握手结束后随时随地的发送,且可能发送多次,这意味着client会缓存多个New Session Ticket,所以pre_shared_key会保存多对New Session Ticket+binders组合。详细pre_shared_key后文会将,为了方便理解PSK handshake和0-RTT握手,此处的pre_shared_key完全理解为 TLS 1.2中的Client Hello中携带的Session_Ticket_TLS拓展。

    2:server发送Server Hello,除了Full handshake中提到的携带的拓展以外还包含如下字段:
    (1):pre_shared_key。表示自己正常解析了client发送的pre_shared_key,然后指定字节从client中选择的New Session Ticket+binders组合,用数字0,1,2,3…表示选择了第几个。

    3:server发送Change Cipher Spec(允许不发送)

    4:server发送Encrypted Extension
    Full handshake中一样

    5:client发送Change Cipher Spec(允许不发送)

    6:client发送 Finished(加密的)
    Full handshake中一样

    7:server发送New Session Ticket(可选)
    Full handshake中一样

    可见,他和TLS 1.2的session ticket复用没什么区别,无非就是处理session ticket的方式有些改变而已。

    TLS 1.3 0-RTT 流程

    上面讲了1-RTT的情况,TLS 1.3 默认最多1-RTT(不考虑Hello request),所以从这个角度上来说,TLS 1.3已经相较于 TLS 1.2 有了握手速度的提升,但是最终极的做法是0-RTT。0-RTT必然存在重放攻击,但是在Google的威逼利诱下,TLS 1.3 还是同意支持了0-RTT。后面会说0-RTT下重放攻击。

    文章开头TLS 1.3 的握手概述一节中,对0-RTT已经有了一些描述,但是不详细,这里根据报文详细描述下其流程。

    RFC中的描述

                ClientHello
                + early_data
                + key_share*
                + psk_key_exchange_modes
                + pre_shared_key
                (Application Data*)     -------->
                                                                ServerHello
                                                           + pre_shared_key
                                                               + key_share*
                                                      {EncryptedExtensions}
                                                              + early_data*
                                                                 {Finished}
                                        <--------       [Application Data*]
                (EndOfEarlyData)
                {Finished}              -------->
                [Application Data]      <------->        [Application Data]
    

    完整的TLS 1.3 0-RTT 描述

    0-RTT是基于上文中PSK handshake为基础的,所以这里和PSK handshake一样的地方直接一笔带过。

    1:client发送Client Hello,除了PSK handshake中提到的携带的拓展以外还包含如下字段:
    (1):early_data拓展,表示其在Client Hello后面紧跟着early data

    2:client发送Change Cipher Spec。(可以选,允许不发送)

    3:client发送application data
    这个application data是被加密的应用层数据,例如GET /...,可以发送好几个Application Data

    4:server发送Server Hello
    PSK Handshake

    5:server发送Change Cipher Spec(允许不发送)

    6:server发送Encrypted Extension。除了PSK Handshake中提到的携带的拓展以外还包含如下字段:
    (1):early_data拓展,表示其愿意接受Client Hello发送的early data

    7:server发送Finished

    8:client发送完early data后,发送End_Of_Early_Data报文表示client自己发送完了early data
    注意,early data并不算在最后的Finished中,其次,End_Of_Early_Data不参与最后application traffic secret的计算。

    9:client发送完End_Of_Early_Data后,发送Finished

    10:server发送New Session Ticket(可选)。

    11:server处理early data,这一步可能是server边收边处理的,所以放在3与4中间也行。

    0-RTT 处理顺序

    作为client,client发送early data之后,可以一直发early data
    作为server,接受Client Hello后,立刻发送自己的数据Server HelloChange Cipher SpecFinished
    作为client,当收到server的Finished后,才允许发送End_Of_Early_Data
    作为client,在如果server没有接受自己发送的early data,则不发送End_Of_Early_Data

    0-RTT 降级到 1-RTT

    上文TLS 1.3 的握手概述中描述过,完成0-RTT的条件有如下2个
    1:PSK Handshake成功
    2:Server配置了接受0-RTT
    那么自然,1和2都有可能发生错误(无论主观还是客观),肯定会由0-RTT降级到1-RTT的情况。降级必然需要妥善处理early data

    对于server来说,拒绝early data,有2种程度的方式可以拒绝:
    (1):拒绝PSK Handshake,即Server Hello中,不加入pre_shared_key拓展。这个常见于session ticket过期等情况。不支持PSK Handshake,自然而然不支持early data
    (2):只拒绝early data,但允许PSK Handshake。即Server Hello中,加入pre_shared_key拓展,但是Encrypted Extension报文中不加入early_data拓展。这个常见于server不准备读取early_data的情况。

    无论(1)和(2),都会忽略client发送的early data,如何忽略?其实如果server不准备读取early data,其当前阶段的secret导出是handshake secret而不是early secret(即想解密的是握手报文而不是early data),所以当拿这个secret去解密early data必然会出现错误,话句话说,所谓的忽略,就是忽略解密错误

    TLS 1.3 中的 New Session Ticket

    TLS 1.2 中的New Session Ticket

          struct {
              uint32 ticket_lifetime_hint;
              opaque ticket<0..2^16-1>;
          } NewSessionTicket;
    

    很简单的格式,一个是ticket_lifetime_hint,告知客户端这个ticket的生命周期(老化时间),ticket就是主要包含了主秘钥等其他信息(客户端认证的话可能还包含客户端的证书)。

    只有在Client HelloServer Hello中都携带了session ticket拓展,server才能在Change Cipher Spec之前发送New Session Ticket

    TLS 1.3 中的New Session Ticket

          struct {
              uint32 ticket_lifetime;
              uint32 ticket_age_add;
              opaque ticket_nonce<0..255>;
              opaque ticket<1..2^16-1>;
              Extension extensions<0..2^16-2>;
          } NewSessionTicket;
    

    ticket_lifetime和TLS 1.2中的ticket_lifetime_hint含义一样,用以告知客户端ticket的老化时间;ticket_age_add作用讲PSK还会再说,这里我们需要知道的是,该值主要是用来混淆PSK中携带的session ticket老化时间。ticket_nonce目前都是是一个counter,,初始值是0,发送一次后,counter++。ticket和TLS 1.2 中的含义类似,只是这里是PSK,而不是master_secretExtension extensions目前只定义了一种拓展:max_early_data_size,该值的作用在上文多次提到过,就是表明server愿意接收多少early data,超过这个值,server会断开连接。
    这个PSK,需要着重说一下,RFC中其计算流程如下:

    HKDF-Expand-Label(resumption_master_secret,
                    "resumption", ticket_nonce, Hash.length) = PSK
    

    入参的核心是,resumption_master_secret,它是由Master Secret进行derive后获得的(详见key derive)。

    TLS 1.3 中的 pre_share_key

    先看一下RFC中对应的格式:

          struct {
              opaque identity<1..2^16-1>;
              uint32 obfuscated_ticket_age;
          } PskIdentity;
    
          opaque PskBinderEntry<32..255>;
    
          struct {
              PskIdentity identities<7..2^16-1>;
              PskBinderEntry binders<33..2^16-1>;
          } OfferedPsks;
    
          struct {
              select (Handshake.msg_type) {
                  case client_hello: OfferedPsks;
                  case server_hello: uint16 selected_identity;
              };
          } PreSharedKeyExtension;
    
    

    上面的意思是说,对于Client Hello而言,发送的是OfferedPsks,也是这节我们关注的。(Server Hello中携带的PSK拓展,上文已经提到过了,也描述了其作用)。我们要关注3个值。
    1:Obfuscated Ticket Age
    2:Identity
    3:PSK binders

    Obfuscated Ticket Age

    个人理解,首先在TLS 1.2中,client发送的Session_Ticket_TLS拓展,并不携带该ticket在客户端已存在的时间。server收到后,靠ticket里面的内容来判断收到的ticket是否过期(例如server发送的ticket里面增加时间相关信息,收到后校验、或者server会定时更新解密key,解密失败意味着ticket过期),而在TLS 1.3中,特地增加一个值,表示ticket的年龄(即在客户端存在的时间)。但是,Client Hello是明文传输的,这个年龄必然也是明文传输的,所以中间人能够看到(看到有什么坏处呢?我不是很清楚,反正就是这么说的)。为了不让中间人知道这个ticket的年龄,很容易想到的是,对这个值 加盐。这个盐就是server端发送的New Session Ticket中的ticket_age_add,因为New Session Ticket本身就是被加密的,所以这个ticket_age_add只有通信两端才知道。
    Obfuscated Ticket Age的计算方法,RFC中也提到了:

    The "obfuscated_ticket_age" field of each PskIdentity contains an obfuscated version of the ticket age formed by taking the age in milliseconds and adding the 
    "ticket_age_add" value that was included with the ticket (seeSection 4.6.1), modulo 
    2^32
    

    obfuscated_ticket_age = (uint32)(jiffies + ticket_age_add)

    其次,Clienthello携带这个时间信息还有一个好处就是,Server可以依据这个时间来快速拒绝0-RTT。Server解密客户端发送Session Ticket后,提取出ticket_age_add,根据公式获取到这个Session Ticket在客户端的age ,判断这个ticket时间是否在自己可接受的范围之内。

    Identity

    其内容就是NewSessionTicket中的ticket部分。server用来恢复session的。这里不赘述了。

    PSK binders

    先说一下,对于client,PSK binders是怎么计算的:
    1、首先计算一个binder_key

                     0
                     |
                     v
       PSK ->  HKDF-Extract = Early Secret
                     |
                     +-----> Derive-Secret(.,
                     |                     "ext binder" |
                     |                     "res binder",
                     |                     "")
                     |                     = binder_key
    

    (1)第一步就是获取PSK
    PSK哪里的?其实就是从New Session Ticket中的ticket恢复得到。

    (2)第二步就是PSK和0进行HKDF-Extract计算Early Secret
    (3)第三步就是计算binder_key

    2、计算Finished key

    The PskBinderEntry is computed in the same way as the Finished message (Section 4.4.4) but with the BaseKey being the binder_key.
    

    所以我们需要计算Finished key

    3、计算当前client hello的摘要md
    注意这个不包括PSK BindersPSK Binders length,否则就出现鸡生蛋蛋生鸡的问题了。

    4、将md进行hmac计算,hmac的key是Finished key

    结尾

    无语 搞这么复杂,为了减少 RTT,代价就是增加 client 和 server的性能消耗。

    如果觉得有用,请打赏N元:http://39.98.242.44

    展开全文
  • Possible Values: [SSL2, SSL3, TLS10, TLS11, TLS12, TLS13, TLS13_DRAFT14, TLS13_DRAFT15, TLS13_DRAFT16, TLS13_DRAFT17, TLS13_DRAFT18, TLS13_DRAFT19, TLS13_DRAFT20, TLS13_DRAFT21, TLS13_DRAFT22, TLS13_...
  • TLS1.3 vs TLS1.2

    2020-07-30 15:08:24
    TLS1.3与TLS1.2的主要不同点(翻译自RFC8446) 裁剪掉支持的对称加密算法。剩下的是Authenticated Encryption with Associated Data(AEAD)算法。密码套件的概念已经更改:将认证和密钥交换算法与记录保护算法(包括...
  • TLSTLS反调试

    千次阅读 2015-07-06 09:18:53
    这里只讨论TLS静态存储,T不讨论TLS动态存储,毕竟跟反调试关系不大。  TLS设计的本意,是为了解决多线程程序中变量同步的问题,是Thread Local Storage的缩写,意为线程本地存储。线程本身有独立于其他线程的栈...
  • TLS1.3和TLS1.2的区别

    千次阅读 2020-05-04 15:44:33
    TLS1.3和TLS1.2的区别 1、密钥协商机制改变,TLS1.3借助扩展进行密钥交换,TLS1.3只需要三次握手交互,TLS1.2则需要四次握手。 首先看TLS1.2,它通过KeyExchange进行密钥协商,即ServerKeyExchange和...
  • SSL和TLS-TLS 1.2

    千次阅读 2018-11-12 11:00:30
    SSL和TLS-TLS 1.2TLS ExtensionsServer Name IndicationMaximum Fragment Length NegotiationClient Certificate URLTrusted CA KeysTruncated HMACCertificate Status RequestUser MappingAuthorizationCertificate...
  • TLS 1.0 RFC http://www.ietf.org/rfc/rfc2246.txt TLS 1.1 RFC http://www.ietf.org/rfc/rfc4346.txt TLS 1.2 RFC http://www.ietf.org/rfc/rfc5246.txt TLS 1.3 见:...
  • TLS 详解

    千次阅读 2019-03-20 09:39:37
    1. TLS 定义 SSL(Secure Sockets Layer) 安全套接层,是一种安全协议,经历了 SSL 1.0、2.0、3.0 版本后发展成了标准安全协议 - TLS(Transport Layer Security) 传输层安全性协议。TLS 有 1.0 (RFC 2246)...
  • mbedtls

    2019-03-13 10:07:00
    mbedtls libmbedcrypto libmbedtls
  • SSL和TLS-TLS 介绍

    2018-11-08 17:02:18
    SSL和TLS-TLS 介绍TLS PRFGeneration of Keying Material TLS协议在结构上与SSL协议相同。是一个客户端/服务器协议,运行在可靠的传输层协议之上,比如TCP。 和SSL一样,也由两层组成: 底层,是TLS record ...
  • TLS详解

    2019-07-30 14:32:33
    一、为什么使用TLS 在SSL/TLS出现之前,很多应用层协议(http、ftp、smtp等)都存在着网络安全问题,例如大家所熟知的http协议,在传输过程中使用的是明文信息,传输报文一旦被截获便会泄露传输内容;传输过程中...
  • SSL和TLS-TLS 1.3

    2018-11-12 14:54:31
    SSL和TLS-TLS 1.3Cipher SuitesCertificate ManagementAlert Messages TLS 1.3(版本号3,4)变化很大,比如新的消息流和更强大的加密。 一个典型的SSL/TLS握手需要最少两个RTTs,如果要验证证书,需要更多次(下载和...
  • nginx 修复TLS1.0,TLS1.1协议漏洞

    千次阅读 2020-04-17 21:15:33
    nginx 修复TLS1.0,TLS1.1协议漏洞 漏洞描述 服务 端口 漏洞名称 加固建议 nginx 443 TLS版本1.0协议检测 启用对TLS 1.2或1.3的支持,并禁用对TLS 1.0的支持。 nginx 443 TLS版本1.1协议检测 启用对TLS ...
  • TLS协议中PRF和TLS1.3中的HKDF

    千次阅读 2018-04-23 21:20:45
    TLS 协议中 PRF 和 TLS 1.3 中的 HKDF TLS 1.0/1.1/1.2协议中,使用了PRF算法进行 key derive。 TLS 1.3中使用了标准的HKDF来进行key derive。 这里大概先回顾一下 &amp;amp;lt;= TLS 1.2 时密钥导出流程和...
  • mbedtls学习5.mbedtls扩展

    2020-05-26 19:18:44
    学习链接 SSL编程- 简单函数介绍 ...mbedTLS(PolarSSL)简单思路和函数笔记(Client端) mbed TLS 简明教程(一) mbed TLS 简明教程(二) mbed TLS 简明教程(三) mbed_TLS RT-thread移植 mbed_TLS arm网站 ...
  • TLS1.3规范

    2017-06-15 15:07:48
    TLS1.3草拟规范,供提前研究
  • windows服务器下 TLS1.0 升 TLS1.2

    千次阅读 2019-02-12 14:58:30
    windows服务器下 TLS1.0 升 TLS1.2 服务器是阿里云的window server 2008 R2 ,在IIS上发布Webservices时发现微信小程序的wx.request要求HTTPS 服务器的 TLS 版本必须支持1.2 TLS网页检测网站:...
  • /etc/tls/private/tls.crt' - '-tls-key=/etc/tls/private/tls.key' - >- -client-secret-file=/var/run/secrets/kubernetes.io/serviceaccount/token - '-cookie-secret-file=/...

空空如也

1 2 3 4 5 ... 20
收藏数 51,320
精华内容 20,528
关键字:

tls