lin_ux_linux的ChinaUnix博客

“有效的程序员不应该浪费很多时间用于程序调试,他们应该一开始就不要把故障引入。”

  • 博客访问: 76478
  • 博文数量: 73
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 266
  • 用 户 组: 普通用户
  • 注册时间: 2014-07-28 23:52
文章分类

全部博文(73)

文章存档

2017年(19)

2014年(54)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: 网络与安全

简述
    此备忘录描述了可用于将ClientHello消息填充到所需大小的传输层安全(TLS)扩展。

1.介绍

连续TLS [RFC5246]版本增加了对更多密码套件的支持,随着时间的推移,已经定义了更多的TLS扩展。 这导致TLS ClientHello的大小增长,额外的大小已经导致一些实现错误。 这些实现错误中的至少一个可以通过使ClientHello更大来改善。 这是希望的,因为难以实现对受影响的实现的全面修补。

    此备忘录描述了TLS扩展,可用于将ClientHello填充到所需的大小,以避免由某些ClientHello大小导致的实现错误。

2.需求表示法
    略

3.填充扩展
 

  
新的扩展类型(填充21)被定义,可能包含在ClientHello消息中。
    
  enum {
       padding(21), (65535)
  } ExtensionType;
    扩展的“extension_data”由任意数量的零字节组成。 例如,最小的“填充”扩展是四个字节长,并且被编码为0x00 0x15 0x00 0x00。 十字节扩展将包括六个字节的“extension_data”,并且将被编码为:
   00 15 00 06 00 00 00 00 00 00
   |---|   |-----| |--------------------|
     |         |             |
     |         |             \- 扩展数据: 6 字节0
     |         |
     |         \------------- 16比特, 扩展数据长度
     |
     \------------------- 填充扩展的类型

 客户端必须用零字节完全填充填充扩展,尽管填充extension_data字段可能为空。

  服务器不得回显此扩展。

4. 使用示例

作为示例,考虑希望避免发送具有256和511字节(包括)之间的TLSCiphertext.length[详解tls协议]的ClientHello的客户端。考虑这种情况是因为已知至少一个TLS实现在接收到这样的ClientHello记录时挂起连接。

   在正常构建ClientHello后,客户端可以向长度添加四个字节(以考虑握手协议的“msg_type”和“length”字段),并测试所得长度是否落入该范围。如果是,则可以添加填充扩展,以便将长度推到(至少)512字节。

   注意,如果原始ClientHello大小在505和507字节之间,则利用握手协议开销,记录有效载荷将在509和511字节长之间。由于扩展不可能占用少于四个字节的空间,因此在这些情况下,附加的填充将不得不将ClientHello记录有效负载扩展到512字节以外。

5.安全注意事项

    填充扩展的内容可以用作隐蔽通道。 为了防止这种情况,内容被要求是全零,虽然扩展的长度仍然可以用作小得多的隐蔽通道。

6. IANA考虑因素

    IANA已在“ExtensionType值”注册表中永久注册了值21(填充)。

7. 规范性引用文件
    rfc2119
    rfc5246

阅读(92) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册