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.01995
    SSL 3.01996
    TLS 1.01999
    TLS 1.12006
    TLS 1.22008
    TLS 1.32018

    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位,以提高安全性。

     

    展开全文
  • 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: RFC8446
    下面我们将介绍 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

    说明:为了简化 CA 校验证书的过程,本文只介绍了最基本的情况。在实际大多数情况下:

    1. server 端的证书颁发机构 CA 和 client 端的证书颁发机构 CA 通常不同
    2. 证书实际情况下,可以是证书链,也就是多个上级机构逐级下发证书的链
    3. 证书校验时,CA 通常可以选择校验证书链的深度,最基础的情况是只校验一级

    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 将进行秘钥协商。接下来 server 和 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,核查证书域名是否与当前的访问域名匹配 (CN 字段)

    证书校验没有强制的过程,也就是校验严格和校验宽松通常都是可以配置的,由校验端来确定。

    (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 也详细描述证书工作方式等。

    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 2048
    openssl genrsa -out server.key 2048
    openssl genrsa -out client.key 2048
    
    # 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 地址
    - [可选] 加密位数 2048 修改为你需要的加密位数

    将会看到:
    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 删除脚本

    rmfile.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

    展开全文
  • mbedtls 开源库Mbed TLS是一个开源、可移植、易于使用、代码可读性高的SSL库
  • 访问某个比较老旧的网站或者内部站点时,提示:无法安全地连接到此页面,这可能是因为该站点使用过期的或不安全的 TLS 安全设置。如果这种情况持续发生,请与网站的所有者联系。TLS 安全设置未设置为默认设置,这也...

    访问某个比较老旧的网站或者内部站点时,提示:无法安全地连接到此页面,这可能是因为该站点使用过期的或不安全的 TLS 安全设置。如果这种情况持续发生,请与网站的所有者联系。TLS 安全设置未设置为默认设置,这也可能导致此错误。

    错误截图:

    这里写图片描述

    提醒:这是win10升级后系统安全策略自动禁用的,请确保访问的网站为内部站点或者可信站点,修改安全配置可能引起安全风险,概不负责

    解决方法:
    一、依次打开IE的Internet选项高级,往下拉,找到安全模块,勾上四个使用:使用SSL 3.0使用TLS 1.0使用TLS 1.1TLS 1.2,点击确定,刷新页面重试。

    结果图:
    这里写图片描述

    二、如果该网站有使用自签证书,请导入并信任(导入方法:双击证书,一直下一步即可)。

    三、如果以上配置完毕,网页还是无法访问,则修改组策略。

    参考微软官方文档:更新启用 Internet Explorer 11 中的 SSL 3.0 回退警告

    1.打开运行(可直接按win+R),输入gpedit.msc,确定。
    这里写图片描述

    2.在弹出的本地组策略编辑器中,依次选择:本地计算机策略计算机配置管理模板Windows 组件Internet Explorer安全功能。在右边选中允许回退到SSL 3.0(Internet Explorer),双击打开。
    这里写图片描述

    3.修改“未配置”为已启用,然后在允许以下项的非安全回退中,下拉选择所有站点,点击确定进行保存,然后重启系统即可。
    在这里插入图片描述

    展开全文
  • 用SVD-TLS估计观测数据的ARMA模型的AR参数,
  • TLS安全说明

    2018-01-12 14:52:18
    TLS安全说明 TLS安全说明TLS安全说明 TLS安全说明TLS安全说明
  • 图示的TLS连接 发布在 site/ :成品的页面来源 server/main.go :服务器代码 client/main.go :客户端代码 tlscopy/ :golang的crypto/tls/ lib的副本,以便于提取秘密值 captures/ :PCAP和keylog文件 另请参阅
  • XP支持TLS1.1和TLS1.2.rar

    2020-08-25 21:54:12
    XP的IE8增加TLS1.1 1.2支持 将XP识别成POSReady 2009 。打上对应的补丁。最后更新证书就实现了。
  • 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)...

    原文链接: https://blog.wangriyu.wang/2018/03-http-tls.html

    1. TLS 定义

    SSL(Secure Sockets Layer) 安全套接层,是一种安全协议,经历了 SSL 1.0、2.0、3.0 版本后发展成了标准安全协议 - TLS(Transport Layer Security) 传输层安全性协议。TLS 有 1.0 (RFC 2246)、1.1(RFC 4346)、1.2(RFC 5246)、1.3(RFC 8446) 版本。

    TLS 在实现上分为 记录层握手层 两层,其中握手层又含四个子协议: 握手协议 (handshake protocol)、更改加密规范协议 (change cipher spec protocol)、应用数据协议 (application data protocol) 和警告协议 (alert protocol)

    image

    2. HTTPS = HTTP over TLS.

    只需配置浏览器和服务器相关设置开启 TLS,即可实现 HTTPS,TLS 高度解耦,可装可卸,与上层高级应用层协议相互协作又相互独立。

    image

    3. 加密

    TLS/SSL 的功能实现主要依赖于三类基本算法:散列函数 Hash、对称加密和非对称加密,其利用非对称加密实现身份认证和密钥协商,对称加密算法采用协商的密钥对数据加密,基于散列函数验证信息的完整性。

    image

    TLS 的基本工作方式是,客户端使用非对称加密与服务器进行通信,实现身份验证并协商对称加密使用的密钥,然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信,不同的节点之间采用的对称密钥不同,从而可以保证信息只能通信双方获取。

    例如,在 HTTPS 协议中,客户端发出请求,服务端会将公钥发给客户端,客户端验证过后生成一个密钥再用公钥加密后发送给服务端(非对称加密),双方会在 TLS 握手过程中生成一个协商密钥(对称密钥),成功后建立加密连接。通信过程中客户端将请求数据用协商密钥加密后发送,服务端也用协商密钥解密,响应也用相同的协商密钥。后续的通信使用对称加密是因为对称加解密快,而握手过程中非对称加密可以保证加密的有效性,但是过程复杂,计算量相对来说也大。

    4. 记录层

    记录协议负责在传输连接上交换的所有底层消息,并且可以配置加密。每一条 TLS 记录以一个短标头开始。标头包含记录内容的类型 (或子协议)、协议版本和长度。原始消息经过分段 (或者合并)、压缩、添加认证码、加密转为 TLS 记录的数据部分。

    image

    分片 (Fragmentation)

    记录层将信息块分割成携带 2^14 字节 (16KB) 或更小块的数据的 TLSPlaintext 记录。

    记录协议传输由其他协议层提交给它的不透明数据缓冲区。如果缓冲区超过记录的长度限制(2^14),记录协议会将其切分成更小的片段。反过来也是可能的,属于同一个子协议的小缓冲区也可以组合成一个单独的记录。

    struct {
      uint8 major, minor;
    } ProtocolVersion;
    
    enum {
      change_cipher_spec(20),
      alert(21),
      handshake(22),
      application_data(23), (255)
    } ContentType;
    
    struct {
      ContentType type; // 用于处理封闭片段的较高级协议
      ProtocolVersion version; // 使用的安全协议版本
      uint16 length; // TLSPlaintext.fragment 的长度(以字节为单位),不超过 2^14
      opaque fragment[TLSPlaintext.length]; // 透明的应用数据,被视为独立的块,由类型字段指定的较高级协议处理
    } TLSPlaintext;
    

    记录压缩和解压缩 (Record compression and decompression)

    压缩算法将 TLSPlaintext 结构转换为 TLSCompressed 结构。如果定义 CompressionMethod 为 null 表示不压缩

    struct {
      ContentType type; // same as TLSPlaintext.type
      ProtocolVersion version; // same as TLSPlaintext.version
      uint16 length; // TLSCompressed.fragment 的长度,不超过 2^14 + 1024
      opaque fragment[TLSCompressed.length];
    } TLSCompressed;
    

    空或标准流加密 (Null or standard stream cipher)

    流加密(BulkCipherAlgorithm)将 TLSCompressed.fragment 结构转换为流 TLSCiphertext.fragment 结构

    stream-ciphered struct {
        opaque content[TLSCompressed.length];
        opaque MAC[CipherSpec.hash_size];
    } GenericStreamCipher;
    

    MAC 产生方法如下:

    HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment));
    

    seq_num(记录的序列号)、hash(SecurityParameters.mac_algorithm 指定的哈希算法)

    MAC(Message authentication code) - 消息认证码

    注意,MAC 是在加密之前计算的。流加密加密整个块,包括 MAC。对于不使用同步向量 (例如 RC4) 的流加密,从一个记录结尾处的流加密状态仅用于后续数据包。如果 CipherSuite 是 TLS_NULL_WITH_NULL_NULL,则加密由身份操作 (数据未加密,MAC 大小为零,暗示不使用 MAC) 组成。TLSCiphertext.length 是 TLSCompressed.length 加上 CipherSpec.hash_size。

    CBC 块加密 (分组加密)

    块加密(如 RC2 或 DES),将 TLSCompressed.fragment 结构转换为块 TLSCiphertext.fragment 结构

    block-ciphered struct {
      opaque content[TLSCompressed.length];
      opaque MAC[CipherSpec.hash_size];
      uint8 padding[GenericBlockCipher.padding_length];
      uint8 padding_length;
    } GenericBlockCipher;
    

    padding: 添加的填充将明文长度强制为块密码块长度的整数倍。填充可以是长达 255 字节的任何长度,只要满足 TLSCiphertext.length 是块长度的整数倍。长度大于需要的值可以阻止基于分析交换信息长度的协议攻击。填充数据向量中的每个 uint8 必须填入填充长度值 (即 padding_length)。

    padding_length: 填充长度应该使得 GenericBlockCipher 结构的总大小是加密块长度的倍数。合法值范围从零到 255(含)。该长度指定 padding_length 字段本身除外的填充字段的长度

    加密块的数据长度(TLSCiphertext.length)是 TLSCompressed.length,CipherSpec.hash_size 和 padding_length 的总和加一

    示例: 如果块长度为 8 字节,压缩内容长度(TLSCompressed.length)为 61 字节,MAC 长度为 20 字节,则填充前的长度为 82 字节(padding_length 占 1 字节)。
    因此,为了使总长度为块长度 (8 字节) 的偶数倍,模 8 的填充长度必须等于 6,所以填充长度可以为 6,14,22 等。如果填充长度是需要的最小值,比如 6,填充将为 6 字节,每个块都包含值 6。因此,块加密之前的 GenericBlockCipher 的最后 8 个八位字节将为 xx 06 06 06 06 06 06 06,其中 xx 是 MAC 的最后一个八位字节。

    XX  - 06 06 06 06 06 06 - 06
    MAC -     padding[6]    - padding_length
    

    记录有效载荷保护 (Record payload protection)

    加密和 MAC 功能将 TLSCompressed 结构转换为 TLSCiphertext。记录的 MAC 还包括序列号,以便可以检测到丢失,额外或重复的消息。

    struct {
      ContentType type; // same
      ProtocolVersion version; // same
      uint16 length; // TLSCiphertext.fragment 的长度,不超过 2^14 + 2048
      select (CipherSpec.cipher_type) {
        case stream: GenericStreamCipher;
        case block: GenericBlockCipher;
      } fragment; // TLSCompressed.fragment 的加密形式,带有 MAC
    } TLSCiphertext;
    

    注意
    这里提到的都是先 MAC 再加密,是基于 RFC 2246 的方案 (TLS 1.0) 写的。但新的方案选择先加密再 MAC,这种替代方案中,首先对明文和填充进行加密,再将结果交给 MAC 算法。这可以保证主动网络攻击者不能操纵任何加密数据。

    密钥计算 (Key calculation)

    记录协议需要一种算法,从握手协议提供的安全性参数生成密钥、IV 和 MAC secret.

    主密钥 (Master secret): 在连接中双方共享的一个 48 字节的密钥
    客户随机数 (client random): 由客户端提供的 32 字节值
    服务器随机数 (server random): 由服务器提供的 32 字节值

    5. 握手层

    • 握手协议的职责是生成通信过程所需的共享密钥和进行身份认证。这部分使用无密码套件,为防止数据被窃听,通过公钥密码或 Diffie-Hellman 密钥交换技术通信。
    • 密码规格变更协议,用于密码切换的同步,是在握手协议之后的协议。握手协议过程中使用的协议是“不加密”这一密码套件,握手协议完成后则使用协商好的密码套件。
    • 警告协议,当发生错误时使用该协议通知通信对方,如握手过程中发生异常、消息认证码错误、数据无法解压缩等。
    • 应用数据协议,通信双方真正进行应用数据传输的协议,传送过程通过 TLS 应用数据协议和 TLS 记录协议来进行传输。

    握手是 TLS 协议中最精密复杂的部分。在这个过程中,通信双方协商连接参数,并且完成身 份验证。根据使用的功能的不同,整个过程通常需要交换 6~10 条消息。根据配置和支持的协议扩展的不同,交换过程可能有许多变种。在使用中经常可以观察到以下三种流程:(1) 完整的握手, 对服务器进行身份验证;(2) 恢复之前的会话采用的简短握手;(3) 对客户端和服务器都进行身份验证的握手。

    握手协议消息的标头信息包含消息类型(1 字节)和长度(3 字节),余下的信息则取决于消息类型:

    struct {
      HandshakeType msg_type;
      uint24 length;
      HandshakeMessage message;
    } Handshake;
    

    5.1 完整握手

    每一个 TLS 连接都会以握手开始。如果客户端此前并未与服务器建立会话,那么双方会执行一次完整的握手流程来协商 TLS 会话。握手过程中,客户端和服务器将进行以下四个主要步骤:

    • 交换各自支持的功能,对需要的连接参数达成一致
    • 验证出示的证书,或使用其他方式进行身份验证
    • 对将用于保护会话的共享主密钥达成一致
    • 验证握手消息并未被第三方团体修改

    下面介绍最常见的握手规则,一种不需要验证客户端身份但需要验证服务器身份的握手:

    image

    5.1.1 ClientHello

    这条消息将客户端的功能和首选项传送给服务器。

    image

    • Version: 协议版本(protocol version)指示客户端支持的最佳协议版本
    • Random: 一个 32 字节数据,28 字节是随机生成的 (图中的 Random Bytes);剩余的 4 字节包含额外的信息,与客户端时钟有关 (图中使用的是 GMT Unix Time)。在握手时,客户端和服务器都会提供随机数,客户端的暂记作 random_C (用于后续的密钥的生成)。这种随机性对每次握手都是独一无二的,在身份验证中起着举足轻重的作用。它可以防止 重放攻击,并确认初始数据交换的完整性。
    • Session ID: 在第一次连接时,会话 ID(session ID)字段是空的,这表示客户端并不希望恢复某个已存在的会话。典型的会话 ID 包含 32 字节随机生成的数据,一般由服务端生成通过 ServerHello 返回给客户端。
    • Cipher Suites: 密码套件(cipher suite)块是由客户端支持的所有密码套件组成的列表,该列表是按优先级顺序排列的
    • Compression: 客户端可以提交一个或多个支持压缩的方法。默认的压缩方法是 null,代表没有压缩
    • Extensions: 扩展(extension)块由任意数量的扩展组成。这些扩展会携带额外数据

    5.1.2 ServerHello

    是将服务器选择的连接参数传回客户端。

    image

    这个消息的结构与 ClientHello 类似,只是每个字段只包含一个选项,其中包含服务端的 random_S 参数 (用于后续的密钥协商)。服务器无需支持客户端支持的最佳版本。如果服务器不支持与客户端相同的版本,可以提供某个其他版本以期待客户端能够接受

    图中的 Cipher Suite 是后续密钥协商和身份验证要用的加密套件,此处选择的密钥交换与签名算法是 ECDHE_RSA,对称加密算法是 AES-GCM,后面会讲到这个

    还有一点默认情况下 TLS 压缩都是关闭的,因为 CRIME 攻击会利用 TLS 压缩恢复加密认证 cookie,实现会话劫持,而且一般配置 gzip 等内容压缩后再压缩 TLS 分片效益不大又额外占用资源,所以一般都关闭 TLS 压缩

    5.1.3 Certificate

    典型的 Certificate 消息用于携带服务器 X.509 证书链
    服务器必须保证它发送的证书与选择的算法套件一致。比方说,公钥算法与套件中使用的必须匹配。除此以外,一些密钥交换算法依赖嵌入证书的特定数据,而且要求证书必须以客户端支持的算法签名。所有这些都表明服务器需要配置多个证书(每个证书可能会配备不同的证书链)。

    image

    Certificate 消息是可选的,因为并非所有套件都使用身份验证,也并非所有身份验证方法都需要证书。更进一步说,虽然消息默认使用 X.509 证书,但是也可以携带其他形式的标志;一些套件就依赖 PGP 密钥

    5.1.4 ServerKeyExchange

    携带密钥交换需要的额外数据。ServerKeyExchange 是可选的,消息内容对于不同的协商算法套件会存在差异。部分场景下,比如使用 RSA 算法时,服务器不需要发送此消息。

    ServerKeyExchange 仅在服务器证书消息(也就是上述 Certificate 消息)不包含足够的数据以允许客户端交换预主密钥(premaster secret)时才由服务器发送。

    比如基于 DH 算法的握手过程中,需要单独发送一条 ServerKeyExchange 消息带上 DH 参数:

    image

    5.1.5 ServerHelloDone

    表明服务器已经将所有预计的握手消息发送完毕。在此之后,服务器会等待客户端发送消息。

    5.1.6 verify certificate

    客户端验证证书的合法性,如果验证通过才会进行后续通信,否则根据错误情况不同做出提示和操作,合法性验证内容包括如下:

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

    PKI 体系 的内容可知,对端发来的证书签名是 CA 私钥加密的,接收到证书后,先读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后利用对应 CA 的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性;然后去查询证书的吊销情况等

    5.1.7 ClientKeyExchange

    合法性验证通过之后,客户端计算产生随机数字的预主密钥(Pre-master),并用证书公钥加密,发送给服务器并携带客户端为密钥交换提供的所有信息。这个消息受协商的密码套件的影响,内容随着不同的协商密码套件而不同。

    此时客户端已经获取全部的计算协商密钥需要的信息: 两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master,然后得到协商密钥(用于之后的消息加密)

    enc_key = PRF(Pre_master, "master secret", random_C + random_S)
    

    image

    图中使用的是 ECDHE 算法,ClientKeyExchange 传递的是 DH 算法的客户端参数,如果使用的是 RSA 算法则此处应该传递加密的预主密钥

    5.1.8 ChangeCipherSpec

    通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信

    注意
    ChangeCipherSpec 不属于握手消息,它是另一种协议,只有一条消息,作为它的子协议进行实现。

    5.1.9 Finished (Encrypted Handshake Message)

    Finished 消息意味着握手已经完成。消息内容将加密,以便双方可以安全地交换验证整个握手完整性所需的数据。

    这个消息包含 verify_data 字段,它的值是握手过程中所有消息的散列值。这些消息在连接两端都按照各自所见的顺序排列,并以协商得到的主密钥 (enc_key) 计算散列。这个过程是通过一个伪随机函数(pseudorandom function,PRF)来完成的,这个函数可以生成任意数量的伪随机数据。
    两端的计算方法一致,但会使用不同的标签(finished_label):客户端使用 client finished,而服务器则使用 server finished。

    verify_data = PRF(master_secret, finished_label, Hash(handshake_messages))
    

    因为 Finished 消息是加密的,并且它们的完整性由协商 MAC 算法保证,所以主动网络攻击者不能改变握手消息并对 vertify_data 的值造假。在 TLS 1.2 版本中,Finished 消息的长度默认是 12 字节(96 位),并且允许密码套件使用更长的长度。在此之前的版本,除了 SSL 3 使用 36 字节的定长消息,其他版本都使用 12 字节的定长消息。

    5.1.10 Server

    服务器用私钥解密加密的 Pre-master 数据,基于之前交换的两个明文随机数 random_C 和 random_S,同样计算得到协商密钥: enc_key = PRF(Pre_master, "master secret", random_C + random_S);

    同样计算之前所有收发信息的 hash 值,然后用协商密钥解密客户端发送的 verify_data_C,验证消息正确性;

    5.1.11 change_cipher_spec

    image

    服务端验证通过之后,服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信(图中多了一步 New Session Ticket,此为会话票证,会在会话恢复中解释);

    5.1.12 Finished (Encrypted Handshake Message)

    服务器也结合所有当前的通信参数信息生成一段数据 (verify_data_S) 并采用协商密钥 session secret (enc_key) 与算法加密并发送到客户端;

    5.1.13 握手结束

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

    5.1.14 加密通信

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

    image

    5.2 密钥交换和签名算法

    常用的密钥交换和签名算法

    HTTPS 通过 TLS 层和证书机制提供了内容加密、身份认证和数据完整性三大功能。加密过程中,需要用到非对称密钥交换和对称内容加密两大算法。

    对称内容加密强度非常高,加解密速度也很快,只是无法安全地生成和保管密钥。在 TLS 协议中,最后的应用数据都是经过对称加密后传输的,传输中所使用的对称协商密钥(上文中的 enc_key),则是在握手阶段通过非对称密钥交换而来。常见的 AES-GCM、ChaCha20-Poly1305,都是对称加密算法。

    非对称密钥交换能在不安全的数据通道中,产生只有通信双方才知道的对称加密密钥。目前最常用的密钥交换算法有 RSA 和 ECDHE。

    RSA 历史悠久,支持度好,但不支持 完美前向安全 - PFS(Perfect Forward Secrecy);而 ECDHE 是使用了 ECC(椭圆曲线)的 DH(Diffie-Hellman)算法,计算速度快,且支持 PFS。

    PKI 体系 一节中说明了仅有非对称密钥交换还是无法抵御 MITM 攻击的,所以需要引入了 PKI 体系的证书来进行身份验证,其中服务端非对称加密产生的公钥会放在证书中传给客户端。

    在 RSA 密钥交换中,浏览器使用证书提供的 RSA 公钥加密相关信息,如果服务端能解密,意味着服务端拥有与公钥对应的私钥,同时也能算出对称加密所需密钥。密钥交换和服务端认证合并在一起。

    在 ECDH 密钥交换中,服务端使用私钥 (RSA 或 ECDSA) 对相关信息进行签名,如果浏览器能用证书公钥验证签名,就说明服务端确实拥有对应私钥,从而完成了服务端认证。密钥交换则是各自发送 DH 参数完成的,密钥交换和服务端认证是完全分开的。

    可用于 ECDHE 数字签名的算法主要有 RSAECDSA - 椭圆曲线数字签名算法,也就是目前密钥交换 + 签名有三种主流选择:

    • RSA - RSA 密钥交换(无需签名)
    • ECDHE_RSA - ECDHE 密钥交换、RSA 签名
    • ECDHE_ECDSA - ECDHE 密钥交换、ECDSA 签名

    image

    比如我的网站使用的加密套件是 ECDHE_RSA,可以看到数字签名算法是 sha256 哈希加 RSA 加密,在 PKI 体系 一节中讲了签名是服务器信息摘要的哈希值加密生成的

    内置 ECDSA 公钥的证书一般被称之为 ECC 证书,内置 RSA 公钥的证书就是 RSA 证书。因为 256 位 ECC Key 在安全性上等同于 3072 位 RSA Key,所以 ECC 证书体积比 RSA 证书小,而且 ECC 运算速度更快,ECDHE 密钥交换 + ECDSA 数字签名是目前最好的加密套件

    以上内容来自本文: 开始使用 ECC 证书

    关于 ECC 证书的更多细节可见文档: ECC Cipher Suites for TLS - RFC4492

    RSA 密钥交换和 DH 密钥交换的区别

    使用 RSA 进行密钥交换的握手过程与前面说明的基本一致,只是没有 ServerKeyExchange 消息,其中协商密钥涉及到三个参数 (客户端随机数 random_C、服务端随机数 random_S、预主密钥 Premaster secret),
    其中前两个随机数和协商使用的算法是明文的很容易获取,最后一个 Premaster secret 会用服务器提供的公钥加密后传输给服务器 (密钥交换),如果这个预主密钥被截取并破解则协商密钥也可以被破解。

    RSA 算法的细节见: wikiRSA算法原理(二)- 阮一峰

    RSA 的算法核心思想是利用了极大整数 因数分解 的计算复杂性

    而使用 DH(Diffie-Hellman) 算法 进行密钥交换,双方只要交换各自的 DH 参数(在 ServerKeyExchange 发送 Server params,在 ClientKeyExchange 发送 Client params),不需要传递 Premaster secret,就可以各自算出这个预主密钥

    DH 的握手过程如下,大致过程与 RSA 类似,图中只表达如何生成预主密钥:

    image

    服务器通过私钥将客户端随机数 random_C,服务端随机数 random_S,服务端 DH 参数 Server params 签名生成 signature,然后在 ServerKeyExchange 消息中发送服务端 DH 参数和该签名;

    客户端收到后用服务器给的公钥解密验证签名,并在 ClientKeyExchange 消息中发送客户端 DH 参数 Client params;

    服务端收到后,双方都有这两个参数,再各自使用这两个参数生成预主密钥 Premaster secret,之后的协商密钥等步骤与 RSA 基本一致。

    基于 RSA 算法与 DH 算法的握手最大的区别就在于密钥交换与身份认证。前者客户端使用公钥加密预主密钥并发送给服务端完成密钥交换,服务端利用私钥解密完成身份认证。后者利用各自发送的 DH 参数完成密钥交换,服务器私钥签名数据,客户端公钥验签完成身份认证。

    关于 DH 算法如何生成预主密钥,推荐看下 WikiEphemeral Diffie-Hellman handshake

    其核心思想是利用了 离散对数问题 的计算复杂性

    原根:假设一个整数 g 对于质数 P 来说是原根,那么 g^i mod P (1 ≦ i < P) 的结果各不相同,且其结果按一定顺序排列后是 1 到 P-1 的所有整数,例子

    离散对数:如果对于一个整数 n 和质数 P 的一个原根 g,可以找到一个唯一的指数 i,使得 n = g^i mod P (0 ≦ i < P),那么指数 i 称为 n 的以 g 为基数的模 P 的离散对数

    Diffie-Hellman 算法的有效性依赖于计算离散对数的难度,其含义是:当已知大素数 P 和它的一个原根 g 后,对给定的 n,要计算 i,被认为是很困难的,而给定 i 计算 n 却相对容易

    算法过程可以抽象成下图:

    image

    双方预先商定好了一对 P g 值 (公开的),而 Alice 有一个私密数 a(非公开,对应一个私钥),Bob 有一个私密数 b(非公开,对应一个私钥)

    • Alice 计算 A = g^a mod P,并把 A(公开,对应一个公钥) 发给 Bob

    • Bob 计算 B = g^b mod P,并把 B(公开,对应一个公钥) 发给 Alice

    • 双方计算出共享密钥,K = B^a mod P = A^b mod P (= g^ab mod P)

    对于 Alice 和 Bob 来说通过对方发过来的公钥参数和自己手中的私钥可以得到最终相同的密钥

    而第三方最多知道 P g A B,想得到私钥和最后的密钥很困难,当然前提是 a b P 足够大 (RFC3526 文档中有几个常用的大素数可供使用),否则暴力破解也有可能试出答案,至于 g 一般取个较小值就可以

    如下几张图是实际 DH 握手发送的内容:

    image

    image

    image

    可以看到双方发给对方的参数中携带了一个公钥值,对应上述的 A 和 B

    而且实际用的加密套件是 椭圆曲线 DH 密钥交换 (ECDH),利用由椭圆曲线加密建立公钥与私钥对可以更进一步加强 DH 的安全性,因为目前解决椭圆曲线离散对数问题要比因式分解困难的多,而且 ECC 使用的密钥长度比 RSA 密钥短得多(目前 RSA 密钥需要 2048 位以上才能保证安全,而 ECC 密钥 256 位就足够)

    关于 椭圆曲线密码学 - ECC,推荐看下 A Primer on Elliptic Curve Cryptography - 原文 - 译文

    5.3 客户端身份验证

    尽管可以选择对任意一端进行身份验证,但人们几乎都启用了对服务器的身份验证。如果服务器选择的套件不是匿名的,那么就需要在 Certificate 消息中跟上自己的证书。

    image

    相比之下,服务器通过发送 CertificateRequest 消息请求对客户端进行身份验证。消息中列出所有可接受的客户端证书。作为响应,客户端发送自己的 Certificate 消息(使用与服务器发送证书相同的格式),并附上证书。此后,客户端发送 CertificateVerify 消息,证明自己拥有对应的私钥。

    只有已经过身份验证的服务器才被允许请求客户端身份验证。基于这个原因,这个选项也被称为相互身份验证(mutual authentication)。

    5.3.1 CertificateRequest

    在 ServerHello 的过程中发出,请求对客户端进行身份验证,并将其接受的证书的公钥和签名算法传送给客户端。

    它也可以选择发送一份自己接受的证书颁发机构列表,这些机构都用其可分辨名称来表示:

    struct {
      ClientCertificateType certificate_types;
      SignatureAndHashAlgorithm supported_signature_algorithms;
      DistinguishedName certificate_authorities;
    } CertificateRequest;
    

    5.3.2 CertificateVerify

    在 ClientKeyExchange 的过程中发出,证明自己拥有的私钥与之前发送的客户端证书中的公钥匹配。消息中包含一条到这一步为止的所有握手消息的签名:

    struct {
      Signature handshake_messages_signature;
    } CertificateVerify;
    

    5.4 会话恢复

    最初的会话恢复机制是,在一次完整协商的连接断开时,客户端和服务器都会将会话的安全参数保存一段时间。希望使用会话恢复的服务器为会话指定唯一的标识,称为会话 ID(Session ID)。服务器在 ServerHello 消息中将会话 ID 发回客户端。

    希望恢复早先会话的客户端将适当的 Session ID 放入 ClientHello 消息,然后提交。服务器如果同意恢复会话,就将相同的 Session ID 放入 ServerHello 消息返回,接着使用之前协商的主密钥生成一套新的密钥,再切换到加密模式,发送 Finished 消息。
    客户端收到会话已恢复的消息以后,也进行相同的操作。这样的结果是握手只需要一次网络往返。

    Session ID 由服务器端支持,协议中的标准字段,因此基本所有服务器都支持,服务器端保存会话 ID 以及协商的通信信息,占用服务器资源较多。

    image

    用来替代服务器会话缓存和恢复的方案是使用会话票证(Session ticket)。使用这种方式,除了所有的状态都保存在客户端(与 HTTP Cookie 的原理类似)之外,其消息流与服务器会话缓存是一样的。

    其思想是服务器取出它的所有会话数据(状态)并进行加密 (密钥只有服务器知道),再以票证的方式发回客户端。在接下来的连接中,客户端恢复会话时在 ClientHello 的扩展字段 session_ticket 中携带加密信息将票证提交回服务器,由服务器检查票证的完整性,解密其内容,再使用其中的信息恢复会话。

    这种方法有可能使扩展服务器集群更为简单,因为如果不使用这种方式,就需要在服务集群的各个节点之间同步会话。
    Session ticket 需要服务器和客户端都支持,属于一个扩展字段,占用服务器资源很少。

    警告
    会话票证破坏了 TLS 安全模型。它使用票证密钥加密的会话状态并将其暴露在线路上。有些实现中的票证密钥可能会比连接使用的密码要弱。如果票证密钥被暴露,就可以解密连接上的全部数据。因此,使用会话票证时,票证密钥需要频繁轮换。

    References

    展开全文
  • 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 黑客 内容 OpenSSL 漏洞 工具 模糊测试 编程 扫描 其他 词汇表 SSL/TLS 协议历史 协议名称 发布日期 作者 RFC SSL 1.0 不适用 网景 不适用 SSL 2.0 1995年 网景 不适用 SSL 3.0 1996年 网景 不...
  • 一个mqtt+tls客户端,能够订阅tls加密过的数据和加密推送数据
  • android TLS

    2014-10-15 11:59:26
    android jni下的pthread tsd(tls)
  • tls-源码

    2021-02-16 00:12:49
    tls-main.zip
  • Mbed TLS is now maintained under open governance at TrustedFirmware.org. Head there for the latest information about the project. The information on this website will be retained while we migrate but ...
  • mbedtls 2.16.0

    2019-03-04 11:25:46
    官方的mbedtls库,2.16.0版本,移植教程可以去他们的github上面看,https://github.com/ARMmbed/mbedtls
  • 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...
  • xt_tls xt_tls是netfilter / IPtables的扩展,允许您基于TLS主机名过滤流量。 特征 根据SNI扩展过滤TLS流量 去做 添加更多高级匹配功能(即通配符匹配) 添加对服务器证书匹配的支持 手动安装 先决条件 内核头文件...
  • Rust TLS API和实现 几个板条箱: tls-api — TLS API,没有任何实现,也没有依赖性 tls-api-native-tls —通过板条箱实现TLS API tls-api-openssl —通过板条箱实现TLS API tls-api-rustls —通过板条箱实现TLS ...
  • 解析TLS ClientHello消息 关于 编写该解析器是为了支持基于子域(类似于apache虚拟主机)构建具有TLS功能的代理。 TLS具有名为服务器名称标识(SNI)的扩展名,以支持此类应用程序。 client_hello框架包含TLS ...
  • cl-mbedtls mbedTLS的CFFI绑定 描述 cl-mbedtls为 (一种安全的网络和加密库)提供CFFI绑定。 cl-mbedtls仍在进行中。 当前,它提供了足够的功能来运行 。 支持SBCL和CCL。 安装 配置和构建mbedTLS 下载并解压缩 ...
  • TLS 1.3 协议详解

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

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

    2021-02-16 12:32:25
    tls300
  • Haskell TLS 该库为服务器和客户端提供了本机的Haskell TLS和SSL协议实现。 描述 这提供了敏感安全协议的高层实现,通过使用高级类型系统,高层结构和常见的Haskell功能消除了一系列常见的安全问题。 特征 很小的...
  • 【小程序】对应的服务器 TLSTLS 1.0 ,小程序要求的 TLS 版本必须大于等于 1.2-附件资源

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 185,984
精华内容 74,393
关键字:

tls