ssl - TLS 1.0-计算完成的消息MAC

Question

我在计算完成消息的 MAC 时遇到问题。RFC 给出了公式

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

但是tlsCompressed(在这种情况下是tlsplaintext，因为没有使用压缩)不包含版本信息:(十六进制转储)

14 00 00 0c 2c 93 e6 c5 d1 cb 44 12 bd a0 f9 2d

第一个字节是 tlsplaintext.type，然后是 uint24 长度。
完整的消息，附加了 MAC 和填充，在加密之前是

1400000c2c93e6c5d1cb4412bda0f92dbc175a02daab04c6096da8d4736e7c3d251381b10b

我尝试使用以下参数(符合 rfc)计算 hmac，但它不起作用:

uint64 seq_num  
uint8  tlsplaintext.type  
uint8  tlsplaintext.version_major  
uint8  tlscompressed.version_minor  
uint16 tlsplaintext.length  
opaque tlsplaintext.fragment

我也试过省略版本并使用 uint24 长度代替。运气不好。
我的 hmac_hash() 函数不会是问题所在，因为到目前为止它一直有效。我还能够计算 verify_data 并验证它。 因为这是新连接状态下发送的第一条消息，所以序号为0。
那么，最终报文的MAC计算参数到底是什么？

Answer 1

这是来自 Forge 的相关来源(TLS 1.0 的 JS 实现):

The HMAC function :

var hmac_sha1 = function(key, seqNum, record) {
    /* MAC is computed like so:
    HMAC_hash(
      key, seqNum +
        TLSCompressed.type +
        TLSCompressed.version +
        TLSCompressed.length +
        TLSCompressed.fragment)
    */
    var hmac = forge.hmac.create();
    hmac.start('SHA1', key);
    var b = forge.util.createBuffer();
    b.putInt32(seqNum[0]);
    b.putInt32(seqNum[1]);
    b.putByte(record.type);
    b.putByte(record.version.major);
    b.putByte(record.version.minor);
    b.putInt16(record.length);
    b.putBytes(record.fragment.bytes());
    hmac.update(b.getBytes());
    return hmac.digest().getBytes();
};

The function that creates the Finished record :

tls.createFinished = function(c) {
    // generate verify_data
    var b = forge.util.createBuffer();
    b.putBuffer(c.session.md5.digest());
    b.putBuffer(c.session.sha1.digest());

    // TODO: determine prf function and verify length for TLS 1.2
    var client = (c.entity === tls.ConnectionEnd.client);
    var sp = c.session.sp;
    var vdl = 12;
    var prf = prf_TLS1;
    var label = client ? 'client finished' : 'server finished';
    b = prf(sp.master_secret, label, b.getBytes(), vdl);

    // build record fragment
    var rval = forge.util.createBuffer();
    rval.putByte(tls.HandshakeType.finished);
    rval.putInt24(b.length());
    rval.putBuffer(b);
    return rval;
};

处理 Finished 消息的代码有点长，可以是 found here .我看到我在该代码中有一条评论，听起来它可能与您的问题相关:

 // rewind to get full bytes for message so it can be manually
 // digested below (special case for Finished messages because they
 // must be digested *after* handling as opposed to all others)

这是否有助于您发现实现中的任何内容？

更新 1

根据您的评论，我想澄清一下 TLSPlainText 的工作原理。 TLSPlainText 是 TLS 协议(protocol)的主要“记录”。它是特定内容类型消息的“包装器”或“信封”。它总是看起来像这样:

struct {
    ContentType type;
    ProtocolVersion version;
    uint16 length;
    opaque fragment[TLSPlaintext.length];
} TLSPlaintext;

所以它总是有一个版本。 Finished 消息是一种握手消息。所有握手消息的内容类型都是 22。握手消息如下所示:

struct {
    HandshakeType msg_type;
    uint24 length;
    body
} Handshake;

握手消息是其他消息的另一个信封/包装器，例如 Finished 消息。在这种情况下，正文将是一条 Finished 消息 (HandshakeType 20)，如下所示:

struct {
    opaque verify_data[12];
} Finished;

要实际发送 Finished 消息，您必须将其包装在 Handshake 消息信封中，然后像任何其他消息一样，您必须将其包装在 TLS 记录 (TLSPlainText) 中。最终结果看起来/代表这样的东西:

struct {
    ContentType type=22;
    ProtocolVersion version=<major, minor>;
    uint16 length=<length of fragment>;
    opaque fragment=<struct {
        HandshakeType msg_type=20;
        uint24 length=<length of finished message>;
        body=<struct {
          opaque verify_data[12]>;
        } Finished>
    } Handshake>
} TLSPlainText;

然后，在运输之前，记录可能会被更改。您可以将这些更改视为获取记录并转换其片段(和片段长度)的操作。第一个操作压缩片段。压缩后，您计算 MAC，如上所述，然后将其附加到片段。然后加密片段(如果使用分组密码，则添加适当的填充)并将其替换为加密结果。因此，完成后，您仍然会得到一条包含类型、版本、长度和片段的记录，但片段已加密。

所以，我们很清楚，当您计算 Finished 消息的 MAC 时，想象一下将上面的 TLSPlainText(假设没有如您指示的那样进行压缩)传递给一个函数。此函数采用此 TLSPlainText 记录，该记录具有类型、版本、长度和片段的属性。上面的HMAC函数运行在记录上。 HMAC key 和序列号(此处为 0)通过 session 状态提供。因此，您可以看到 HMAC 功能所需的一切都可用。

无论如何，希望这能更好地解释协议(protocol)的工作原理，并且可能会揭示您的实现出了什么问题。