tls1.3 - CSDN
精华内容
参与话题
  • 详解TLS1.3的握手过程

    万次阅读 2018-05-08 22:00:37
    最近学习了一下TLS几个版本的协议,今天来着重说明下TLS1.3的握手过程,通过对握手过程的说明你就可以清晰的明白为什么TLS1.3要比TLS1.2快那么多了,话不多说,先上TLS1.3的握手流程图: 图中的ClientHello具体内容...

    最近学习了一下TLS几个版本的协议,今天来着重说明下TLS1.3的握手过程,通过对握手过程的说明你就可以清晰的明白为什么TLS1.3要比TLS1.2快那么多了,话不多说,先上TLS1.3的握手流程图:                 

                      

                                 

    图中的ClientHello具体内容说明如下:

    (1)客户端支持的ssl的最高版本号

    (2)客户端支持的加密套件列表

    (3)确定的会话ID

    (4)客户端所支持的压缩算法列表

    图中ServerHello的具体内容如下:

    (1)服务端选择的ssl的版本(选择方式为选择客户端和服务端最高版本中的较低的那一个)

    (2)服务端选择的密码套件

    (3)会话ID

    (4)客户端选择的压缩算法

    那么TLS1.3比TLS1.2到底快在哪呢?我们再来看看TLS1.2的握手流程

                 

    TLS1.2的ClientHello和ServerHello和TLS1.3中的稍有不同,我们来看一下TLS1.2中的ClientHello和ServerHello的内容:

    ClientHello的内容如下:

    (1)客户端支持的ssl的最高版本号

    (2)客户端支持的加密套件列表

    (3)确定的会话ID

    (4)客户端所支持的压缩算法列表

    (5)一个用于生成主秘钥的32位随机数

    ServerHello的内容如下:

    (1)服务端选择的ssl的版本(选择方式为选择客户端和服务端最高版本中的较低的那一个)

    (2)服务端选择的密码套件

    (3)会话ID

    (4)客户端选择的压缩算法

    (5)一个用于生成主秘钥的32位随机数

    我们可以看到,TLS1.2比TLS1.3在握手过程中多了一次握手,为啥会多这一次握手嘞?首先我们要理解握手的本质是为了什么,握手是为了协商出一个client和server端都认可的一个对称秘钥,典型的秘钥协商算法有两种,RSA和ECDH,简明介绍下这两种算法会让你对这个过程更加清晰。

    首先是RSA的秘钥协商过程,RSA有一个很棒的特性:RSA算法给予server端一个公钥和私钥,一段消息既可以用公钥加密,然后用私钥解密,也可以用私钥加密,用公钥解密。公钥是什么呢?你可以理解成服务器从CA那得到的证书。好,我们来看下TLS1.2的秘钥协商过程,首先client发一个client_hello,然后server端收到这个消息后,回传一个server_hello(client_hello和server_hello中的内容就在上面讲了),一个证书(关键点),client收到证书后,用公钥(也就是证书)加密一段随机数发回给server,server收到后用私钥解密得到这段随机数,这段随机数就作为对称加密的秘钥了,至此握手就完成。

    然后我们来看下ECDH的秘钥协商过程,首先EC的意思是椭圆曲线,这个EC提供了一个很厉害的性质,你在曲线上找一个点P,给定一个整数K,求解Q=KP很容易,给定一个点P,Q,知道Q =KP,求K却是个难题。在这个背景下,给定一个大家都知道的大数G,client在每次需要和server协商秘钥时,生成一段随机数a,然后发送A=a*G给server,server收到这段消息(a*G)后,生成一段随机数b,然后发送B=b*G给client,然后server端计算(a*G)*b作为对称秘钥,client端收到后b*G后计算a*(G*b),因为(a*G)*b = a*(G*b),所以对称秘钥就是a*G*b啦,攻击者只能截获A=a*G和B=b*G,由于椭圆曲线难题,知道A和G是很难计算a和b的,也就无法计算a*G*b了(当然,实际上的计算过程和原理证明不是这么简单的,中间还有一个取模的过程,以及取模过程的交换律和结合律证明,但是本质思想和这个是差不多的)。反应在TLS1.2中,client发送client_hello,server收到后发送server_hello和ECC证书(B =b*G),client收到后就生成随机数a,然后发送a*G给server,并记录秘钥,server收到a*G后计算对称秘钥,握手就结束了。而为什么在TLS1.3会有区别呢,留意下TLS1.3图中的key_share,这段的功能就是直接记录了a*G,然后包含在client_hello中。然后server收到后在server_hello的key_share段中记录b*G。所以TLS1.3一个RTT就搞定握手了。

    至此,你应该已经对于为什么TLS1.3要快一个RTT有一定概念了吧,TLS1.3舍弃了RSA的协商过程,然后基于ECDH的算法优化了整个过程。(这里提下ECDHE,多的这个E是extemporaneous,临时的意思,临时的是ECC证书中的随机数,每次都会重新生成,也是是b*G中的b)。

    当然,TLS1.3不仅仅只做了这么一点优化,还有典型的连接回复过程,TLS1.3做到了0-RTT的过程,TLS1.2重建会话过程如下:

                          

    (1)client发送ClientHello,并携带session id,这个session id就是用于回复会话,server端会存储关于session id的对应的通信秘钥

    (2)server回复ServerHello,ChangeCipherSpec和Finished

    而TLS1.3呢

                             

    可以看出,TLS1.3是对TLS1.2过程的优化,也就是直接加密数据然后发送。

    当然了,TLS1.3还有很多其他的特性,这里稍微提一下,TLS1.3采用少即是多的思想,TLS1.2中原有的大量特性都被删除了,这些特性包括:

    • RSA密钥传输——不支持前向安全性
    • CBC模式密码——易受BEAST和Lucky 13攻击
    • RC4流密码——在HTTPS中使用并不安全
    • SHA-1哈希函数——建议以SHA-2取而代之
    • 任意Diffie-Hellman组——CVE-2016-0701漏洞
    • 输出密码——易受FREAK和LogJam攻击

    TLS 1.3版本是对规范的重大修改,一些工作方式也非常不同:

    • 有一些新的密码套件仅在TLS 1.3下工作。一些旧的密码套件无法用于TLS 1.3连接。
    • 新的密码套件定义方式不同,且并未详细规定证书类型(如RSA、DSA、ECDSA)或密钥交换机制(如DHE或ECHDE)。这对密码套件的配置有暗示作用。
    • 客户端在客户问候消息(ClientHello)中提供一个“key_share”。这会对“组”配置产生影响。
    • 直到主握手完成以后,会话才会建立。在握手结束和会话建立之间可能会有一个间隙(理论上,会话可能根本不会建立),并可能对会话恢复代码产生影响。
    • 在TLS 1.3版本中,重新磋商是不可能的。
    • 现在大部分握手都会被加密。
    • 更多类型的消息现在可以有扩展(这对定制扩展API和证书透明系统有影响)。
    • 在TLS 1.3连接中不再允许使用DSA证书。
    展开全文
  • TLS1.3 概述

    2020-04-08 17:15:20
    TLS1.3的最终版本,在2018年8月发布,它包含着很多不同以往版本的改进,相对于之前版本安全性以及性能具有极大的提高,同时它也具备了更多的扩展和握手模式,那么从实现完整TLS1.3结构的角度去学习TLS,我们应该从...

    tls1.3
    TLS1.3的最终版本,在2018年8月发布,它包含着很多不同以往版本的改进,相对于之前版本安全性以及性能具有极大的提高,同时它也具备了更多的扩展和握手模式,那么从实现完整TLS1.3结构的角度去学习TLS,我们应该从哪些方面入手呢?

    什么是TLS


    TLS代表传输层安全性,并且是SSL(安全套接字层)的后继者。TLS提供了Web浏览器和服务器之间的安全通信。连接本身是安全的,因为使用对称密码术对传输的数据进行加密。密钥是为每个连接唯一生成的,并且基于在会话开始时协商的共享机密(也称为TLS握手)。HTTP + TLS = HTTPS

    TLS历史

    history

    TLS1.2


    TLS1.2握手原理

    tls1.2
    握手的过程主要包括两部分:

    • 参数协商
      客户端向服务器发送client Hello消息,里面包含client所支持的参数(密码套件等等),还包含一些有用的参数(version、random、sessionId等等),server会从中选取自己支持的密码套件、版本,通过server Hello发送给client,其中也包含一个随机数还有一些其他字段。
    • 密钥交换
      之后server会通过Server Key Exchange消息向client发送自己用于协商的公钥,用于协商的算法是:ECDHE或DHE,同样client通过 Client Key Exchange 发送自己的公钥,这样双方都具有了彼此的公钥,用它们生成临时私钥。client在收到server的Certificate消息之后会验证server的身份,验证通过才会发送Client Key Exchange,其中还包含着pre-Masterkey,是对client生成的随机数加密得来,最后使用三个随机数生成Masterkey用于会话密钥。

    观察图片我们可以看出,TLS1.2整个握手过程需要2个RTT时间,而且每次握手都用到了非对称加密算法签名或者解密的操作,比较耗时和耗 CPU,每次都要传输证书,证书比较大会消耗带宽。

    • RTT
      Round-Trip Time,往返时延,在计算机网络中它也是一个重知要的性能指标,它表示从发送端发道送数据开始,到发送端收到来自接收端的确认版(接收端收到数据后便立即发送确认),总共经历的时延。

    TLS1.2会话恢复

    • SessionID
      将协商好的会话参数缓存在客户端与服务器中,client下次握手时会带上上次握手的SessionID,server对其查询,若存在直接复用。
    • SessionTicket
      server将协商好的会话参数和密钥加密发送给客户端,client下次握手会将这个SessionTicket带上,如果server解密成功就复用上次的会话参数和密钥。

    在TLS1.3中没有了SessionID这种会话恢复模式,但是在client Hello中还会存在该字段,主要是为了兼容版本。并且在SessionTicket模式中,添加了Ticket age,指的是会话是存在时间限制的,如果超过了该时间,那么也就不能进行会话恢复。

    sessionid
    我们可以看到,使用SessionID恢复会话的时候,需要花费1个RTT的时间,在TLS1.3中一定情况下恢复会话只需要花费0个RTT!

    在握手的过程中很多数据都会临时计算,如果我们把这些数据提前计算出来,然后存入扩展当中,这样就可以减少握手的时间为1个RTT,TLS1.3实现的主要思想就是这样的。

    TLS1.3


    TLS1.3握手

    更快的访问速度
    TLS1.2handshake
    这是一张TLS1.2的握手过程图片,前面也分析过,它需要2个RTT的时间才能完成整个握手过程,下面我们看一下TLS1.3的握手过程图:

    tls1.3extension
    我们会发现,其中存在一些以前版本从来没有出现过的extension,比如:key_share、signature_algorithms等等,这只是一部分,还包含很多扩展,我会一一细说。正因为这些扩展才使得TLS1.3的握手速度大大提高。

    注:

    • +:上一消息的扩展消息
    • *:可选发送
    • {}:用握手层流密钥加密
    • []:用流密钥加密

    client Hello

    当client第一次连接server的时候,它需要向server发送client Hello 消息。

    clientHello消息的结构:

      uint16 ProtocolVersion;
          opaque Random[32];
    
          uint8 CipherSuite[2];    /* Cryptographic suite selector */
    
          struct {
              ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
              Random random;
              opaque legacy_session_id<0..32>;
              CipherSuite cipher_suites<2..2^16-2>;
              opaque legacy_compression_methods<1..2^8-1>;
              Extension extensions<8..2^16-1>;
          } ClientHello;
    

    简单介绍一下比较重要的几个字段的含义:

    • legacy_version
      在 TLS 以前的版本里,这个字段被用来版本协商和表示 Client 所能支持的 TLS 最高版本号。经验表明,很多 Server 并没有正确的实现版本协商,导致了 “version intolerance” —— Sever 拒绝了一些本来可以支持的 ClientHello 消息,只因为这些消息的版本号高于 Server 能支持的版本号。在TLS1.3中,设置了一个supported_version的扩展来表明client所支持的版本。legacy_version 字段必须设置成 0x0303,这是 TLS 1.2 的版本号。在 TLS 1.3 中的 ClientHello 消息中的 legacy_version 都设置成 0x0303,supported_versions 扩展设置成 0x0304。主要是为了兼容之前的TLS版本。
    • legacy_session_id
      前面我也提到过,TLS1.3中不再使用SessionID进行会话恢复,这一特性已经和预共享密钥PSK合并了,设置这个字段的意义,主要也是为了兼容之前版本,如果 Client 有 TLS 1.3 版本之前的 Server 设置的缓存 Session ID,那么这个字段要填上这个 ID 值。兼容模式下,这个值必须是非空的,所以如果Client不能提供之前版本的值,那么需要重新生成一个32字节的值。

    还有cipher_suites、legacy_compression_methods,包含的是Client支持的密码套件和压缩算法,压缩算法TLS1.3也已经不再支持了,这个字段主要还是为了兼容版本,对于每个 ClientHello,该向量必须包含一个设置为 0 的一个字节,它对应着 TLS 之前版本中的 null 压缩方法。

    supported_groups

    这个扩展表明了 Client 支持的用于密钥交换的命名组。按照优先级从高到低。这个扩展中的 “extension_data” 字段包含一个 “NamedGroupList” 值:

     enum {
    
              /* Elliptic Curve Groups (ECDHE) */
              secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
              x25519(0x001D), x448(0x001E),
    
              /* Finite Field Groups (DHE) */
              ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
              ffdhe6144(0x0103), ffdhe8192(0x0104),
    
              /* Reserved Code Points */
              ffdhe_private_use(0x01FC..0x01FF),
              ecdhe_private_use(0xFE00..0xFEFF),
              (0xFFFF)
          } NamedGroup;
     struct {
              NamedGroup named_group_list<2..2^16-1>;
          } NamedGroupList;
    

    key_share

    这个扩展我觉得是TLS1.3的重大改变,它里面包含了Client对应于supported_groups中参数的公钥集,如果使用了曲线,则会表明所使用的曲线以及对应的公钥。

       struct {
              NamedGroup group;
              opaque key_exchange<1..2^16-1>;
          } KeyShareEntry;
    
    • group:
      要交换的密钥的命名组。
    • key_exchange:
      密钥交换信息。这个字段的内容由特定的组和相应的定义确定。主要包含特定组的公钥等信息。

    在 ClientHello 消息中,“key_share” 扩展中的 “extension_data” 包含 KeyShareClientHello 值:

      struct {
              KeyShareEntry client_shares<0..2^16-1>;
          } KeyShareClientHello;
    
    • client_shares:
      按照 Client 偏好降序顺序提供的 KeyShareEntry 值列表。

    在golang中该结构的实现:

    type KeyShareEntry struct {
    	group 			NamedGroup
    	length			uint16
    	keyExchange		[]byte
    }
    
    type KeyShareClientHello struct {
    	length 			uint16
    	clientShares	[]KeyShareEntry
    }
    

    如果我们只实现椭圆曲线的话,首先需要选择要使用的椭圆曲线,之后再选取随机数生成公钥,将公钥存入keyExchange字段中,也就是说这个扩展已经将Client用于协商会话密钥的参数提前计算出来,并存储了起来,这与之前版本的形式server先选择参数,然后发给Client,然后Client再计算相比较,极大的节省了时间和握手过程中占用的CPU。

    Client 可以提供与其提供的 support groups 一样多数量的 KeyShareEntry 的值。每个值都代表了一组密钥交换参数。例如,Client 可能会为多个椭圆曲线或者多个 FFDHE 组提供 shares。每个 KeyShareEntry 中的 key_exchange 值必须独立生成。Client 不能为相同的 group 提供多个 KeyShareEntry 值。Client 不能为,没有出现在 Client 的 “supported_group” 扩展中列出的 group 提供任何 KeyShareEntry 值。Server 会检查这些规则,如果违反了规则,立即发送 “illegal_parameter” alert 消息中止握手。

    当选用PSK密钥协商模式时,即使在supported_groups中不存在支持的算法也不会终止握手,这时候,server会向Client发送和serverhello具有相同结构的消息:HelloRetryRequest,它的目的主要是想让Client作出一些改变以使得握手正常进行,在这种情况下,在 HelloRetryRequest 消息中,“key_share” 扩展中的 “extension_data” 字段包含 KeyShareHelloRetryRequest 值。

        struct {
              NamedGroup selected_group;
          } KeyShareHelloRetryRequest;
    
    • selected_group
      表明server所选择的NamedGroup中组

    Client收到此消息之后也会对其进行验证,selected_group是否在NamedGroup中出现了,selected_group 没有在原始的 ClientHello 中的 “key_share” 中出现过。如果上面 的检查都失败了,那么 Client 必须通过 “illegal_parameter” alert 消息来中止握手。否则,在发送新的 ClientHello 时,Client 必须将原始的 “key_share” 扩展替换为仅包含触发 HelloRetryRequest 的 selected_group 字段中指示的组,这个组中只包含新的 KeyShareEntry。

    在 ServerHello 消息中,“key_share” 扩展中的 “extension_data” 字段包含 KeyShareServerHello 值。

      struct {
              KeyShareEntry server_share;
          } KeyShareServerHello;
    
    • server_share:
      与 Client 共享的位于同一组的单个 KeyShareEntry 值。

    我们再来看一下ECDHE的参数,对于 secp256r1,secp384r1 和 secp521r1,内容是以下结构体的序列化值:

          struct {
              uint8 legacy_form = 4;
              opaque X[coordinate_length];
              opaque Y[coordinate_length];
          } UncompressedPointRepresentation;
    

    对端还要验证对方的公钥以确保为有效的点:

    • 验证公钥不是无穷大点
    • 两个整数x、y中间有正确的间隔
    • x、y是椭圆曲线方程的正确的解

    小结

    TLS 1.3 中优化握手:

    • client发送clientHello(extension)消息,extension中的support_groups中携带client支持的椭圆曲线的类型,并且在扩展key_share中计算出了相对应的公钥,一起发送给server
    • server收到clientHello后会首先选择相应的椭圆曲线参数计算自身的公钥,从key_share扩展中提取相应的公钥作为密钥协商的参数,计算主密钥,并且把自身计算出的公钥放到serverHello的扩展key_share中,然后发送serverHello等消息给client,Client从key_share中取出公钥计算主密钥。

    TLS1.3会话恢复

    在本文前面我提到过TLS1.3已经不再使用SessionID进行会话恢复了,现在主要使用的是SessionTicket进行会话恢复,但是又不同于TLS1.2中使用SessionTicket进行会话恢复的过程,也做出了一些改变,或者说是进行了一些更新(PSK)。

    tls1.3handshake
    会话恢复所花费的时间是1个RTT,这与整个的握手时间是一样的。在TLS1.3中采用的会话恢复机制是PSK它与SessionTicket有些类似,Client通过PSK发送被server加密的会话缓存参数,如果server解密成功就可以直接复用会话,不需要再重新传输证书和协商密钥了。

    密钥交换模式

    • PSK-Only
    • (EC)DHE
    • PSK with (EC)DHE(暂时还没出现)

    PSK handshake

    在使用PSK密钥交换模式时我们首先要了解几个ClientHello的其它扩展:

    Pre-Shared Key Exchange Modes

    为了使用PSK,client还需要发送Pre-Shared Key Exchange Modes扩展,它的含义是Client 仅支持使用具有这些模式的 PSK,这就限制了在这个 ClientHello 中提供的 PSK 的使用,也限制了 Server 通过 NewSessionTicket 提供的 PSK 的使用。
    如果Client提供了 pre_shared_key扩展,那么就必须提供该扩展

      enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
    
          struct {
              PskKeyExchangeMode ke_modes<1..255>;
          } PskKeyExchangeModes;
    
    • psk_ke:
      仅 PSK 密钥建立。在这种模式下,Server 不能提供 key_share 值
    • psk_dhe_ke:
      PSK 和 (EC)DHE 建立。在这种模式下,Client 和 Server 必须提供 key_share值。

    这样的话就可以进行模式选择,并作出相应的改变。未来分配的任何值都必须要能保证传输的协议消息可以明确的标识 Server 选择的模式。目前 Server 选择的值由 ServerHello 中存在的 key_share 表示。

    Pre-Shared Key

    该扩展是用来协商标识的,该标识是与PSK密钥相关联的给定握手所使用的预共享密钥的标识。或者说是New Session Ticket+binders,由于在TLS1.3中,New Session Ticket可以在握手结束后可能多次发送,所以Pre-Shared Key可能会存储多组对应的值,下面我们具体来了解一下它的结构。

    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;
    
    • identity:
      一个预共享密钥的标签。
    • obfuscated_ticket_age:
      SessionTicket的寿命的混淆版本,为了防止一些相关连接的被动观察者。而在TLS1.2中是不存在这样的字段,即不会标识出客户端已存在的时间,server收到后主要靠里面的内容来判断Ticket是否过期,而在TLS1.3中就增加了这样一个字段来表示Ticket的寿命,因为是明文传输所以会被观察者发现,所以给时间加了一些调味品,是New Session Ticket中的ticket_age_add,因为New Session Ticket本身就是被加密的,所以这个ticket_age_add只有通信两端才知道。
    • 混淆的方法:
      用 ticket 时间(毫秒为单位)加上 “ticket_age_add” 字段,最后对 2^32 取模。注意,NewSessionTicket 消息中的 “ticket_lifetime” 字段是秒为单位,但是 “obfuscated_ticket_age” 是毫秒为单位。
    • identities:
      Client 愿意和 Server 协商的 identities 列表,其内容就是NewSessionTicket中的ticket部分。如果和 early_data 一起发送,第一个标识被用来标识 0-RTT 的。有关early_data后面还会说到。
    • selected_identity:
      server选择的标识,是server在自己的 Pre-Shared Key扩展中自己设置的选择的标识,表明正常解析了Client的扩展,其实选择的话就是一个序号。

    0-RTT

    前面已经提到过TLS1.3已经将握手时间优化到了1-RTT,对比之前版本的速度已经快了很多,但是TLS1.3最终极的做法是0-RTT,即握手的时间是0-RTT。

    Client发送ClientHello消息,除了在PSK模式中提到的那些扩展外,还应该具有一个early_data扩展,同理server发送serverHello中也应该包括该扩展,并表示其愿意接受early_data,client发送完early_data后,发送End_Of_Early_Data报文表示client自己发送完了early_data。

    如果 Server 提供了 early_data 扩展,Client 必须验证 Server 的 selected_identity 是否为 0。如果返回任何其他值,Client 必须使用 “illegal_parameter” alert 消息中止握手。下面我们看一下它的结构:

      struct {} Empty;
    
          struct {
              select (Handshake.msg_type) {
                  case new_session_ticket:   uint32 max_early_data_size;
                  case client_hello:         Empty;
                  case encrypted_extensions: Empty;
              };
          } EarlyDataIndication;
    

    其中的max_early_data_size字段表明,允许Client发送的最大0-RTT的数据量。

    发生错误会导致0-RTT降级到1-RTT。

    New Session Ticket

    Post-Handshake Messages在 Server 接收到 Client 的 Finished 消息以后的任何时刻,它都可以发送 NewSessionTicket 消息。此消息在 ticket 值和从恢复主密钥派生出来的 PSK 之间创建了唯一的关联。

       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:
      这个字段表示 ticket 的生存时间,这个时间是以 ticket 发布时间为网络字节顺序的 32 位无符号整数表示以秒为单位的时间。Server 禁止使用任何大于 604800秒(7 天)的值。值为零表示应立即丢弃 ticket。无论 ticket_lifetime 如何,Client 都不得缓存超过 7 天的 ticket,并且可以根据本地策略提前删除 ticket。Server 可以将 ticket 视为有效的时间段短于 ticket_lifetime 中所述的时间段。
    • ticket_age_add:
      安全的生成的随机 32 位值,用于模糊 Client 在 “pre_shared_key” 扩展中包含的 ticket 的时间。Client 的 ticket age 以模 2 ^ 32 的形式添加此值,以计算出 Client 要传输的值。Server 必须为它发出的每个 ticket 生成一个新值。
    • ticket_nonce:
      每一个 ticket 的值,在本次连接中发出的所有的 ticket 中是唯一的。初始值是0,发送一个则++
    • ticket:
      这个值是被用作 PSK 标识的值

    TLS1.3一些其他扩展和机制

    降级保护机制

    主要通过随机数来实现,当协商TLS1.2或更老的版本,为了响应ClientHello在random后8个字节填入特定的随机值,若为TLS1.2则后8个字节的值为:

    44 4F 57 4E 47 52 44 01
    

    supported_version

    主要功能的话前面也有提到,对Client标明所支持的TLS版本,对Server标明正在使用的TLS版本,如果协商TLS之前的版本,这个扩展必须带上,若不存在该扩展,server要协商之前的版本,则中止握手,若存在server将禁止使用ClientHello中的legacy_version作为版本协商的值,只能使用supported_versions中的值。
    对于server:

    • 版本<TLS1.3 则设置serverHello.version,不能发送supported_version
    • 版本>=TLS1.3则必须发送supported_version扩展,还要设置serverHello.legacy_version为0x0303,若扩展存在Client会忽略serverHello.legacy_version,而去读取supported_version的值。
        struct {
              select (Handshake.msg_type) {
                  case client_hello:
                       ProtocolVersion versions<2..254>;
    
                  case server_hello: /* and HelloRetryRequest */
                       ProtocolVersion selected_version;
              };
          } SupportedVersions;
    
    展开全文
  • 【科普】什么是TLS1.3

    千次阅读 2017-08-11 18:43:31
    TLS1.3是一种新的加密协议,它既能提高各地互联网用户的访问速度,又能增强安全性。 我们在访问许多网页的时候,常常会在浏览器的地址栏上看到一个锁的图标,并使用“https”代替传统的“http”。这里的“s”代表着...

    1478726110-7051-tls-1.3

    TLS1.3是一种新的加密协议,它既能提高各地互联网用户的访问速度,又能增强安全性。

    我们在访问许多网页的时候,常常会在浏览器的地址栏上看到一个锁的图标,并使用“https”代替传统的“http”。这里的“s”代表着安全。当你连接到一个HTTPS站点时,你和该站点之间的通信会被加密,这会显著提高浏览的安全性,使你的通信避开那些窥视的眼睛,并防止恶意代码的注入。HTTPS不仅应用于网站,还保护着大部分API和移动应用后台的安全。

    我们把使互联网实现安全通信的基础性技术称为传输层安全协议(TLS)。TLS是安全套接层协议(SSL)的进化版本,SSL是由Netscape公司在1990年代研发的。国际互联网工程任务组(IETF)做为一个标准化组织,负责定义该协议,该协议已经历了多次修订。最新版本TLS1.2在2008年被确立为标准,目前被大多数浏览器和启用HTTPS的web服务所支持。

    在配置正常的情况下,TLS1.2会很安全,但如今它却显得有些过时了。在过去几年中,几次引人注目的攻击暴露出该协议的一些漏洞。在计算机安全领域,8年是一段很长的时间,因此IETF已经在着手开发该协议的新版本TLS1.3,并将于2016年底完工。
    TLS1.3是一次全面升级,与此前版本相比,它有两个主要优势:
    ●增强安全性
    ●提升速度

    增强安全性

    过去几年来,大部分针对TLS的攻击都是以该协议90年代遗留下来的残余部分为目标的。TLS1.2具有很强的可配置性,因此一些有安全漏洞的站点为兼容老版本的浏览器而没有关闭那些旧的属性。

    TLS1.3信奉“少即是多”哲学,取消了对一些老旧而衰弱的加密方式的支持。这意味着你无法打开那些潜在的漏洞。TLS1.2中原有的大量特性都被删除了,其中大部分特性与那些著名的攻击有关,这些特性包括:
    ●RSA密钥传输——不支持前向安全性
    ●CBC模式密码——易受BEAST和Lucky 13攻击
    ●RC4流密码——在HTTPS中使用并不安全
    ●SHA-1哈希函数——建议以SHA-2取而代之
    ●任意Diffie-Hellman组——CVE-2016-0701漏洞
    ●输出密码——易受FREAK和LogJam攻击

    TLS1.3消除了旧版本中糟糕的加密方式,同时降低了旧的攻击方式对其产生影响的可能性。这种精简使网络管理员可以更简便地进行配置。此外,这次更新提高了协议的速度,也给用户带来更好的浏览体验。

    提升速度

    网页加载速度的提高对web服务的成功是至关重要的。亚马逊公司曾有一个著名的发现:网页加载时间每增加100毫秒,销售额就会下降1%。网页加载时间的一个主要组成部分就是浏览器和web服务器之间发送数据耗费的“延迟时间”。

    “延迟时间”特别会显著影响到:
    a)移动设备用户
    b)服务器在地理上相距很远的用户

    1478726111-6450-ls-1.3-handshake-performance

    一条消息从悉尼往返纽约会花费超过200毫秒,而在移动设备上浏览还会增加这一延迟时间。通过现代4G移动网络发送一条消息通常会额外增加100毫秒的延迟。在欧洲仍普遍使用的3G网络下,这一延迟则会增加200毫秒。就连家用WiFi和ISP也会再增加几十毫秒的延迟。这些额外的延迟会使人感觉到移动浏览速度很缓慢。不幸的是,数据加密会进一步降低连接的速度。而TLS1.3有助于改善这种状况。

    要向加密网站发送一条消息,你必须首先建立共用密钥。这一过程叫做一次握手。它要求有专门的消息往来于浏览器和网站之间。只要你的浏览器连接到一个加密站点,TLS握手就会在后台发生。

    对于TLS1.2来说,在请求发送出去之前,需要2次消息往来才能完成握手。通过移动网络访问一个站点时,加载时间会额外增加超过半秒钟。而对于TLS1.3来说,首次握手只需要1次消息往来。这就像把一辆0-60迈加速需10秒的旅行车升级成一辆只需5秒的特斯拉Model S。如果一次连接所需的消息往来耗时约100毫秒,那么TLS1.3的速度提升足以让那些反应迟缓(加载时间超过300毫秒)的站点变得足够快(加载时间低于300毫秒)。

    不仅如此,而TLS1.3还有其他的优点。对于近期访问过的站点,你可以在第一次给服务器发消息时就发送有用的数据。这叫做“零消息往来”模式(0-RTT),会使网页加载变得更快!

    它为所有浏览器而生

    TLS1.3对网络安全和性能来说都是一大进步。尽管TLS1.3规范仍在进一步完善中,但IETF已非常接近完成这一协议的最终版本。主要浏览器Firefox和Chrome都已在其开发版(火狐Nightly版和Chrome Canary版)中使用了TLS1.3的初步版本。

    那么问题来了,怎样才能在你的浏览器中启用TLS1.3呢?

    火狐Nightly版

    ●安装并运行火狐Nightly版:https://nightly.mozilla.org/
    ●在地址栏输入“about:config”
    ●将security.tls.version.max的值由3改为4
    ●重启浏览器

    1478726111-2362-illa-firefox-tls-1.3-768x423

    Chrome Canary版

    ●安装并运行Chrome Canary版:
    https://www.google.com/chrome/browser/canary.html
    ●在地址栏输入“chrome://flags/”
    ●找到“Maximum TLS version enabled.”并选择“TLS 1.3”
    ●重启浏览器

    1478726112-4398-chrome-tls-1.3

    关于TLS1.3的更多细节,请戳此处

    展开全文
  • TLS 1.3科普——新特性与协议实现

    千次阅读 2018-02-06 13:01:14
    在今年的GoSSIP软件安全小组面向全国优秀的本科同学开放的暑期实习中,来自上海交通大学的胡嘉尚同学深入研究了SSL/TLS协议,并撰写了这篇TLS 1.3的科普文章,希望能够帮助国内的安全研究人员和企业开发人员更加深入...

    上海交通大学密码与计算机安全实验室(LoCCS)软件安全小组(GoSSIP)版权所有,转载请与作者取得联系!


    在今年的GoSSIP软件安全小组面向全国优秀的本科同学开放的暑期实习中,来自上海交通大学的胡嘉尚同学深入研究了SSL/TLS协议,并撰写了这篇TLS 1.3的科普文章,希望能够帮助国内的安全研究人员和企业开发人员更加深入地理解和部署TLS 1.3协议。


    ======================================================================


    时隔九年之后的新升级,TLS 1.3备受关注。针对目前已知的漏洞和安全威胁,IETF小组对TLS协议进行了一次大的更新,从2014年4月,第0份TLS 1.3草案公开,到2017年7月第21份草案发布,TLS 1.3的编写工作已经进入尾声,跨时3年的编写,让该协议成为有史以来最安全、也是最复杂的TLS协议。

    正式的RFC虽然尚未发布,TLS 1.3已经开始被国内外一些网站使用,Chrome、Firefox、OpenSSL、Nginx等均提供了相应支持,TLS 1.3已经悄然进入我们的生活。借着这篇文章先来了解一下吧~


    Part 1-简介

    20年——从开始到现在

    对于安全加密通信,传输层安全协议(SSL/TLS)的重要性不言而喻。 
    起初,网景公司针对传输层协议(TCP/UDP)并没有对传输的数据进行加密保护的缺陷,为自家浏览器设计了SSL协议,于1995年公开协议的2.0版本。1999年,IETF小组基于SSL 3.0设计了与SSL协议独立的TLS 1.0协议,正式成为互联网传输层加密的标准。此后,TLS协议于2006年、2008年再次经历更新,分别命名为TLS 1.1和TLS 1.2。 
    如今的TLS协议不仅被用于传输层通讯,更作为一个标准的加密保护协议被广泛应用于 FTP, 电子邮件和VPN等领域,时刻保护着我们网络通信的安全。


    当前的TLS协议存在问题

    老版本的SSL协议被公认在完整性校验、密钥协商过程中有重大缺陷,因此,2011年与2015年IETF小组相继声明禁止使用SSL 2.03.0。 
    TLS协议针对此前披露的漏洞做了相应的处理,但是因为其复杂性,还没有一个版本能真正保证绝对的安全。 
    目前最新版本的TLS 1.2发布距今已有九年时间,在此期间,许多SSL/TLS协议的新漏洞被发现,比如针对其压缩机制的CRIME漏洞,针对CBC块加密模式的BEAST漏洞(主要是针对SSL 3.0和TLS 1.0),早已不再是当初设计者认为的那么安全,人们迫切需要新的协议将其代替。


    TLS1.3与之前的协议有较大差异

    SSL/TLS协议为网络通信提供了以下两种功能:

    1. 建立一个安全的连接:对其中传输的数据提供加密保护,防止被中间人嗅探到可见明文;对数据提供完整性校验,防止传输的数据被中间人修改。
    2. 建立一个可信的连接:对连接双方的实体提供身份认证。

    上述功能在以往的TLS协议中是这样实现的:

    • 加密:使用对称加密算法(块加密、流加密)加密会话数据,密钥交换主要通过非对称算法加密会话过程中使用的对称密钥传递给对方来实现(RSA)。从TLS 1.0起引入了DH密钥交换算法作为另一种可选的密钥交换算法。
    • 完整性校验:使用MAC对发送的报文进行完整性校验计算,先计算MAC再加密。在TLS 1.2中引入了更具有安全性的AEAD算法(同时完成加密和完整性校验)作为一个加密机制的备选选项 。
    • 身份认证:所有的身份认证都基于证书公钥体系完成。

    因为RSA密钥交换过程安全性完全依赖于服务器私钥的安全性,TLS 1.3彻底废弃了RSA密钥交换算法。 
    因为先计算MAC再加密的方法存在相当的安全缺陷,TLS 1.3废弃了使用MAC的块加密和流加密机制,仅采用AEAD类对称加密算法作为唯一的加密选项。 
    此外,TLS 1.3引入了一种新的密钥协商机制——PSK。

    其他新协议大的改变还包括: 
    - 支持0-RTT数据传输 
    - 废弃了3DES、RC4、AES-CBC等加密组件。废弃了SHA1、MD5等哈希算法。 
    - 不再允许对加密报文进行压缩、不再允许双方发起重协商,密钥的改变不再需要发送change_cipher_spec报文给对方。 
    - 握手阶段的报文可见明文大大减少。

    对比以往的协议RFC中不足一页的Major Differences from Previous。TLS 1.3确实可以称得上是向前的一大步。


    TLS 1.3包括3个子协议——alert、handshake、record

    handshake协议负责协商使用的TLS版本、加密算法、哈希算法、密钥材料和其他与通信过程有关的信息,对服务器进行身份认证,对客户端进行可选的身份认证,最后对整个握手阶段信息进行完整性校验以防范中间人攻击,是整个TLS协议的核心。 
    record协议负责对接收到的报文进行加密解密,将其分片为合适的长度后转发给其他协议层。 
    alert协议负责处理消息传输与握手阶段中的异常情况。 
    此前的协议中还定义了一个子协议change_cipher_spec来决定何时对传递的数据进行加密,TLS 1.3取消了这一机制,密钥的使用和改变随着服务器和客户端状态的改变自然进行。


    Part 2-新的术语

    PSK(pre_shared_key)——新的密钥交换暨身份认证机制

    1. 0-RTT:客户端和服务端的一次交互(客户端发一个报文,服务端回应一个报文)叫做一个RTT,TLS 1.2普遍采用2-RTT的握手过程,服务器延迟明显。因此TLS 1.3引入了一种0-RTT的机制,即在刚开始TLS密钥协商的时候,就能附送一部分经过加密的数据传递给对方。
    2. 为了实现0-RTT,需要双方在刚开始建立连接的时候就已经持有一个对称密钥,这个密钥在TLS 1.3中称为PSK(pre_shared_key)。
    3. PSK是TLS 1.2中的rusumption机制的一个升级,TLS握手结束后,服务器可以发送一个NST(new_session_ticket)的报文给客户端,该报文中记录PSK的值、名字和有效期等信息,双方下一次建立连接可以使用该PSK值作为初始密钥材料。
    4. 因为PSK是从以前建立的安全信道中获得的,只要证明了双方都持有相同的PSK,不再需要证书认证,就可以证明双方的身份,因此,PSK也是一种身份认证机制。
    ps: 0-RTT的实现有一定的安全缺陷,自身没有抗重放攻击的机制 
    在TLS 1.3草案中提出了几个对性能消耗比较大的可能的解决方法,感兴趣的话可以找来读一读。

    HKDF(HMAC_based_key_derivation_function)——新的密钥导出函数

    1. 经过密钥协商得出来的密钥材料因为随机性可能不够,协商的过程能被攻击者获知,需要使用一种密钥导出函数来从初始密钥材料(PSK或者DH密钥协商计算出来的key)中获得安全性更强的密钥。
    2. HKDF正是TLS 1.3中所使用的这样一个算法,使用协商出来的密钥材料和握手阶段报文的哈希值作为输入,可以输出安全性更强的新密钥。
    3. HKDF包括extract_then_expand的两阶段过程。extract过程增加密钥材料的随机性,在TLS 1.2中使用的密钥导出函数PRF实际上只实现了HKDF的expand部分,并没有经过extract,而直接假设密钥材料的随机性已经符合要求。

    AEAD(Authenticated_Encrypted_with_associated_data)——唯一保留的加密方式

    1. TLS协议的最终目的是协商出会话过程使用的对称密钥和加密算法,双方最终使用该密钥和对称加密算法对报文进行加密。
    2. AEAD将完整性校验和数据加密两种功能集成在同一算法中完成,是TLS 1.3中唯一支持的加密方式。TLS 1.2还支持流加密和CBC分组模式的块加密方法,使用MAC来进行完整性校验数据,这两种方式均被证明有一定的安全缺陷。
    3. 但是有研究表明AEAD也有一定局限性:使用同一密钥加密的明文达到一定长度后,就不能再保证密文的安全性。因此,TLS 1.3中引入了密钥更新机制,一方可以(通常是服务器)向另一方发送Key Update(KU)报文,对方收到报文后对当前会话密钥再使用一次HKDF,计算出新的会话密钥,使用该密钥完成后续的通信。

    Part 3-Handshake子协议

    TLS 1.3完整握手工作流

    • +表示该报文中值得注意的extension
    • * 表示该内容也可能不被发送
    • {} 表示该内容使用handshake_key加密
    • [] 表示该内容使用application_key加密

    TLS 1.3握手执行步骤

    TLS 1.3握手按照严格的顺序发送不同的报文,各个报文包含标识自己种类的数据以及其他与握手协商有关的扩展数据(extension)。任何时候收到不按顺序发出的报文种类,服务器会报错,并转交给alert协议层处理。 
    一个正常情况下的TLS 1.3握手应该按照以下顺序组织报文:

    • 客户端发送Client Hello(CH)报文,包含有关密钥协商以及其他与TLS连接建立有关的扩展给服务端。
    • 服务端发送Server Hello(SH)报文,包含有关密钥协商的扩展返还给客户端,双方根据CH和SH的协商结果可以得出密钥材料。
    • 如果客户端发送的CH报文不满足服务端的需要(如:不包含服务端支持的DH组件),服务端会发送一个Hello Retry Request报文给客户端,要求客户端重新发送符合要求的CH报文。
    • 利用密钥材料和前两个报文的哈希值,使用HKDF可以计算出一个handshake_key,此后握手阶段的信息受该密钥保护。
    • 服务端发送Encypted Extension(EE)报文,包含其他与密钥协商无关的扩展数据给客户端。
    • 如果使用公钥证书进行身份认证,服务端发送Certificate报文(传递自己的证书信息),和Certificate Verify(CV)报文(使用自己的证书私钥对之前的报文进行HMAC签名证明自己持有该证书)给客户端。
    • 如果需要对客户端身份进行认证,服务端还需要发送Certificate Request(CR)报文给对方请求客户端发送证书。
    • 服务端发送Finished报文。表明服务端到客户端信道的握手阶段结束,理论上不得再由该信道发送任何握手报文。
    • 如果客户端收到了服务端的CR报文,返回自己的Certificate报文和CV报文。
    • 客户端发送Finished报文,表明握手阶段结束,可以正式开始会话通讯。Finished报文使用会话密钥对上述所有握手信息进行HMAC签名,校验签名可以检验握手阶段的完整性,也可以验证双方是否协商出了一致的密钥。

    所有握手阶段的报文都是由record协议层加解密、分片、填充、转发的。 
    在这个过程中,如果发生了任何错误(如:服务端证书验证失败、完整性校验错误),则会发送一个alert报文,转交给alert协议层进行错误处理。


    其他没有提及到的报文种类

    除了正常的情况之外,还有其他一些报文可能出现在握手过程中。

    1. 用来传递PSK键值对信息的New Session Ticket(NST)报文: 之前也提到过,NST报文在连接建立后(即客户端发送完Finished报文后),由服务端发送给客户端,包含PSK初始值和PSK名字、有效期、用途限定等信息,双方会在协商完毕后计算application_key的同时计算出一个resumption_key,使用resumption_key与PSK初始值做HKDF计算才正式得到真正的PSK值,用于下一次TLS连接的建立。
    2. 负责更新密钥以保证AEAD安全性的Key Update(KU)报文
    3. 用来实现0-RTT数据传输的Early Data(ED)报文: 如果使用了PSK协商密钥,可以利用双方都持有的PSK计算出一个early_key,使用该key在发送CH报文之后客户端就可以发送加了密的应用数据(即ED)与服务端进行通讯,ED的发送与其他握手报文独立,即服务端不用等待接收到ED之后再向客户端发送SH,但是客户端一旦受到服务端发送的Finished报文,必须立即结束ED的发送,而转而发送一个End Of Early Data报文给服务端。除此之外,客户端也可以在early data正常发送完毕之后,发送End Of Early Data结束ED,而不需要等待收到服务端的Finished报文。

    TLS 1.3定义了12种握手报文

    使用Hello传递的信息进行密钥协商——选择加密组件

    经过两个Hello报文后,双方就明确了计算密钥的初始材料和最终使用的加密算法。加密算法是通过协商加密组件获知的。 
    因为只使用AEAD加密机制,且彻底禁止了所有不安全的加密算法,TLS 1.3目前支持的加密组件只有以下五种:

    TLS_AES_128_CCM_SHA256为例,TLS表明该加密组件用于TLS协议,AES表明使用AES对称加密算法,128表示密钥长度为128位,CCM表明分组加密模式,SHA256是HKDF过程使用的哈希算法。 
    协商加密组件时,双方只需要传递相应的value传递即可。由客户端传递一个所有自己支持的加密组件的列表,由服务器将最终选定的加密组件值返还给对方完成协商。 
    TLS 1.2中定义了多达37种的加密组件,大量使用了MD5、RC4、3DES等被证明不安全或者效率低下的加密算法。 
    TLS 1.3仅支持速度快安全性强的加密标准算法AES,以及08年才提出的对性能消耗极低的CHACHA20。使用CHACHA20进行AEAD运算时,CHACHA20本身不能提供完整性校验的功能,因此使用POLY1305——一种同样不耗费性能的MAC算法来提供完整性校验的功能。这些算法,包括协议中随着算法使用的分组加密模式CCM和GCM,目前都是理论上安全的算法,不容易被攻击者破解。


    如何得出最终密钥——PSK密钥协商机制

    协商出来加密算法,下一步则是协商出加密密钥,TLS 1.3支持DH、PSK两种密钥协商机制,也支持同时使用两者进行密钥协商。 
    如果双方持有未过有效期的PSK键值对,则可以使用PSK进行密钥协商。双方传递一个结构体PSK_entry。该结构体包括的内容有:PSK对应名字(PSK_name)、用该PSK对之前的握手报文进行的HMAC计算结果( PSK_identity)。 
    具体的实施过程如下:

    • 客户端在CH报文的pre_key_share扩展中传递一个PSK_entry的数组,包含所有自己持有的PSK信息。
    • 服务端接收到该数组后,首先根据PSK_name选择一个想要使用的PSK,再使用自己持有的该PSK值计算HMAC值,若与PSK_identity一致,则说明双方持有的PSK一致,否则服务器报错。
    • 服务端将选定的PSK_entry结构体在Server Hello中的pre_key_share扩展中返还给客户端。协商完成,得到初始密钥PSK

    如果使用了PSK,则客户端可以向服务端发送early_data,客户端会选择发送的PSK_entry数组中的第一个PSK计算early_trffic_key,因此,服务端也必须选择第一个PSK,如果服务端拒绝接受early data,则返回其他的PSK_entry,客户端丢弃已发送的ED报文。 
    使用PSK密钥协商,已经对双方的身份做了一定的认证,不得再使用公钥证书的认证方式,即CV/CR/CT报文都不会再发送。


    如何得出最终密钥——DHE密钥协商机制

    使用DHE扩展首先需要选定DH参数,对于有限域DH来说是g和p的值,对于椭圆域DH是椭圆曲线和基点的值,同选定加密组件一样,TLS 1.3定义了几组gp值,双方只需要协商想要使用的pg对即可。 
    在TLS 1.2中,g和p的值由双方自己生成。TLS 1.3则定义了几组g、p对,双方只需要选择想要使用的DH组即可。使用确定的参数值保证了DH密钥协商过程具有足够的安全性。 
    具体实施过程与PSK的实施过程类似,由客户端生成一个列表包含所有自己支持的DH组,为每个组生成一个DH密钥交换的参数,将其组名和参数值封装在key_share扩展中,服务端选定DH组后,返回一个封装好的key_share,双方根据交换的公钥参数和自己持有的私钥参数计算出DH最终密钥。

    理论上,客户端应该将所有与密钥协商有关的扩展(pre_shared_key、shared_key)都发送给服务端,服务端选定哪一种,再将对应选定的扩展返还给客户端,如果服务端同时使用两种密钥协商,则返还所有扩展,如果客户端没有提供足够的密钥扩展,服务端发送HRR报文要求客户端重新发送CH。


    使用密钥协商结果计算实际使用密钥

    TLS 1.3最大的特点就是对于不同的报文使用多种不同的密钥。 
    在TLS 1.2中只使用了两种密钥,一个用于完整性校验,一个用于报文加密,同一连接不同方向使用的加密密钥不一样。 
    TLS 1.3因为使用AEAD机制,不再需要使用MAC_key来进行完整性校验,同时由于其他各种用途的加密需要,TLS 1.3的实施过程还可能计算或者使用以下几种key: 
    - handshake_key 
    - early_traffic_key 
    - resumption_key 
    - exporter_key(导出密钥,用于用户自定义的其他用途)

    这些密钥都是由之前协商的密钥材料计算而出,区别在于HKDF的计算次数不同,HKDF计算使用的哈希值不同。以会话密钥application_key为例,以整个握手阶段的报文作为输入,计算四次HKDF导出最终使用的密钥。 
    同时,当加密的报文达到一定长度后,双方发送KU报文重新计算application_key。


    post-authentication机制

    ost-authentication机制方便用户确认是否向服务端提供自己的身份信息。

    TLS 1.3支持服务端在握手结束之后再对客户端发起身份的校验。 
    CH报文中有一个扩展字段post_handshake_anth。如果客户端发送了此字段,则允许服务端在握手阶段结束后再发起Certificate Request,客户端会在收到CR之后再发送CT、 CV报文给服务端进行身份认证。 
    p

    Part 4-record子协议

    TLS发送的报文由record层处理:

    1. 分片:TLS将接收到的报文分为一个个小的record后,对每个record单独进行加密后转发 
      TLS 1.3协议定义了一系列规则,大致有几点: 
      - 每一个record的长度有一定限制。 
      - 使用不同密钥的消息不能在一个record中。所有可能提示key即将变更的握手信息都必须单独发送(如:KU/SH/FI)。 
      - 对不同种类的报文有不同的处理方式: 
      - HM(handshake message):不能为空,不能在传递一连串的HM record时夹杂其他类型的信息。 
      - alert:每个alert报文都必须完整发送,不得分片。 
      - application data:对TLS协议不可见,所以没有对应的处理规则。
    2. 加密解密:使用AEAD加密机制和协商出来的加密算法对消息报文进行加密 。
      AEADEncrypted = AEAD-Encrypt(write_key(即加密密钥), nonce, plaintext)
    关于随机数的获取: 
    双方维护一个64位的sequence number,连接建立和每一次密钥变更时,sequence number置0,此后随传递的字节数增加 
    加密时将sequence扩充到write_iv(也是由write_key导出的一个初始向量)的长度,再与write_iv做异或计算得到nonce

    最后将数据传递出去时,record层会在密文头部附加一小段明文信息来标识解密后明文长度等信息。

    对方的record层收到该消息后,通过逆过程解密密文后转发给上层协议。

    3. TLS 1.3允许TLS对消息报文填充来阻止攻击者获知传送消息的长度等信息。

    填充时在末尾附上八个字节整数倍的全为0的二进制数据,对方收到该消息后,解密后从末尾 开始去掉0,当搜索到第一个不全为0的八字节数据,则结束。


    Part 5-alert子协议

    alert层负责处理TLS连接过程中的各种异常情况,对每种情况发送一个alert报文,报文中附加一些错误处理需要的必要信息,TLS 1.3中定义了30种alert报文。 
    举例来讲:alert层的close_notify报文标志发送方打算关闭TLS连接,不再使用该加密信道传递任何信息,bad_record_mac可能表示AEAD解密时完整性校验失败。


    Part 6-总结

    TLS 1.3使用了复杂的密钥导出过程,增强了最终使用的密钥的安全性。同时简化了所使用的加密算法,废弃了RC4、3DES、MD5、SHA1、AES-CBC等加密算法,删除了压缩、重协商等具有漏洞的机制,大大精简了协议。 
    因此,TLS 1.3如果能够得到普及,网络数据的传递将会变得更加安全、隐秘,TLS 1.3的推广需要每一位开发者、运营者的认可和支持。 
    目前TLS 1.3虽然还在草案阶段,但是其基本原理和思想已经应用在了实际生活中,chrome等浏览器都已准备好了对其的支持,期待TLS 1.3正式成为一个协议规范的那一天。


    附录:参考读物

    以下读物可以帮助读者对TLS 1.3有一些更深的理解 
    1. 写的很好的一篇博文,介绍了TLS协议的历史和核心思想 
    2. 微信基于TLS 1.3较早期草案设计的mmtls协议概述 
    3. cloud flare公司对TLS 1.3的介绍博文合集(英文) 
    4. TLS 1.3草案合集,可以从这里检索到最新版的TLS1.3草案(英文) 
    5. 16年NDSS会议研究TLS 1.3的论文合集(英文)


    展开全文
  • 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,如果要验证证书,需要更多次(下载和...
  • 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

    千次阅读 2018-12-26 18:25:26
    本文主要从TLS 1.3的优势、部署和时间发展线介绍了这种用于为计算机网络通信提供安全性的密码协议TLS。 上篇文章回顾:浅谈DHCP协议    TLS简介 按照维基百科的定义,TLS 是一种用于为计算机网络通信提供安全...
  • 科普:什么是TLS1.3

    千次阅读 2017-07-24 10:05:19
    TLS1.3是一种新的加密协议,它既能提高各地互联网用户的访问速度,又能增强安全性。 我们在访问许多网页的时候,常常会在浏览器的地址栏上看到一个锁的图标,并使用“https”代替传统的“http”。这里的“s”代表...
  • TLS 1.3 VS TLS 1.2,让你明白 TLS 1.3 的强大 https://www.jianshu.com/p/efe44d4a7501?utm_source=oschina-app 又拍云关注 0.52018.09.20 14:20字数 1830阅读 3685评论 1喜欢 8 HTTPS ...
  • HTTPS 加密时代已经来临,近两年,Google、Baidu、Facebook 等互联网巨头,不谋而合地开始大力推行 HTTPS, 2018 年 7 月 25 日,Chrome 68 上线,所有 HTTP 网站都会被明确标记为“不安全”。国内外大到 Google、...
  • OpenSSL支持TLS1.3特性前瞻

    千次阅读 2017-05-11 09:58:16
    即将到来的OpenSSL 1.1.1版本将支持TLS 1.3。这个新版本将兼容OpenSSL 1.1.0版本的二进制文件和API。理论上,如果你的应用程序支持OpenSSL 1.1.0,那么当更新可用时,TLS 1.3版本也将自动得到支持,你不需要专门进行...
  • TLS 1.3详解

    2020-04-28 18:45:15
    he Transport Layer Security (TLS) Protocol Version 1.3 (draft-ietf-tls-tls13-20) 与TLS1.2的主要区别: 以下是TLS 1.2和TLS 1.3之间主要功能的差异列表。 它不是详尽的,有很多微小的区别。 支持的对称...
  • 使用Wireshark解密TLS 1.3流量 作者: 虞卫东 (微信公众号: https://mp.weixin.qq.com/s/QhodMl210xWMK9XKjVtfAQ ) 2018-05-13 如果你想系统掌握 TLS 协议的细节,了解客户端和服务器消息的交互,非常好的学习工具...
  • TLS1.3抓包分析

    千次阅读 2020-03-12 08:24:47
    一、TLS1.3抓包分析——ClientHello 抓包使用的是WireShark2.6.7,抓包内容为https://tls13.crypto.mozilla.org/(Mozilla的TLS1.3测试页面),浏览器为chrome(需开启TLS1.3),这里我先给出抓包结果: ...
  • 随着互联网的发展,用户对网络速度的要求也越来越高,尤其是目前在大力发展 HTTPS 的情况下,TLS 加密协议变得至关重要。...2018年初,又拍云 CDN 网络部署了 TLS 1.3...TLS 1.3 加密协议是在 TLS 1.0 、TLS 1.1 、TLS ...
  • 文章目录目录对称加密和非对称加密SSL/TLSTLS 1.3 更快的访问速度TLS 1.3 更强的安全性OpenSSL 对称加密和非对称加密 加密的过程就是把 “明文” 变成 “密文” 的过程。反之,解密的过程,就是把 “密文” 变为...
  • TLS1.3规范(RFC文档)

    万次阅读 2017-01-05 11:07:44
    The Transport Layer Security (TLS) Protocol Version 1.3 (draft-ietf-tls-tls13-latest) TLS支持三种基本的密钥交换模式: (EC)DHE (Diffie-Hellman both the finite field and elliptic curve varieties)...
  • TLS1.3 抓包分析

    2020-04-29 15:13:50
    一、TLS1.3抓包分析——ClientHello 抓包使用的是WireShark2.6.7,抓包内容为https://tls13.crypto.mozilla.org/(Mozilla的TLS1.3测试页面),浏览器为chrome(需开启TLS1.3),这里我先给出抓包结果: ...
  • TLS 1.3协议分析

    千次阅读 2019-07-22 10:44:58
    2年多以前学习总结TLS1.3文档的笔记,希望里面的一些分析对有困惑的同行有所帮助 截止目前2017/04/07 已知实现TLS1.3的厂商有ngix 且在firefox 中49版本以经支持但没有默认打开,在52版本中已经默认打开; OpenSSL ...
  • 标准完成后,OpenSSL 组织将推出 OpenSSL 1.1.1 版本,对 TLS1.3 协议标准提供支持。 本文主要讲解 TLS 1.3 版本的相关特性以及如何在你的服务器上启用 TLS 1.3 的支持。 在谈 TLS 1.3 之前,我们先来看下 TLS 1.2...
1 2 3 4 5 ... 20
收藏数 15,182
精华内容 6,072
热门标签
关键字:

tls1.3