TLS扩展:省略TLS握手消息

Question

我一直在阅读各种RFCs，并没有找到一个明确的答案，我的问题:一个协商的TLS扩展可以跳过一些TLS握手消息，仍然符合TLS规范吗？我的目标是开发一个新版本的TLS，同时最好保持向后兼容。

在这里，我将特别讨论在TLS 1.2中定义的RFC 5246。下面是完全握手的消息流(直接取自RFC 5246)：

  Client                                          Server
  ------                                          ------      

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

 
* Indicates optional or situation-dependent messages that are not always sent.

现在，我知道TLS扩展修改某个消息的结构或添加一个新消息是完全合法的，但我不确定是否可以省略其中一个消息(未定义为可选/情况相关的消息)。

让我举一个具体的例子。假设我创建了一个名为XYZ的新扩展。客户端和服务器在扩展的hello消息中协商这个扩展。XYZ扩展要求服务器不发送ServerHelloDone消息是否合法？据我所知，这是不合法的。

RFC 5245第4.4.1.4节指出：

从技术上讲，使用扩展来更改

  aspects of the design of TLS; for example the design of cipher 
  suite negotiation.  This is not recommended; it would be more 
  appropriate to define a new version of TLS -- particularly since 
  the TLS handshake algorithms have specific protection against 
  version rollback attacks based on the version number, and the 
  possibility of version rollback should be a significant 
  consideration in any major design change

但是，我认为这些主要方面不包括忽略规范中未标记为可选/情况相关的消息。

Answer 1

我向TLS邮件列表发送了同样的问题，得到的答复是，实际上，扩展指定忽略规范中未标记为可选/状态相关的消息是合法的。

您可以找到讨论这里。

Answer 2

我看不出为什么您不能从正常的TLS握手状态中分叉，并且基于扩展来做任何您想做的事情。特别是因为它是经过协商的，客户机/服务器将知道如何相互交谈。但是，是否符合TLS 1.2取决于您所做的更改。改变握手会让你失去依从性。

我相信，扩展的目的是允许协议堵塞安全漏洞，并提供更多的安全选项。从RFC 5246中可以清楚地看到，握手协议中有可选的和必需的消息。忽略任何必需的消息将违反规范。握手消息也有特定的顺序，如果更改将违反规范：

第7.4节

握手协议消息按必须发送的顺序在下面显示；

我不认为您能够以您想要的方式创建一个符合TLS 1.2的新协议。