我在计算已完成消息的MAC时遇到问题.RFC提供了公式
HMAC_hash(MAC_write_secret,seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment));
但是tlsCompressed(在这种情况下为tlsplaintext因为没有使用压缩)不包含版本信息:(hex dump)
14 00 00 0c 2c 93 e6 c5 d1 cb 44 12 bd a0 f9 2d
第一个字节是tlsplaintext.type,后跟uint24长度 附加MAC和填充以及加密前的完整消息是
1400000c2c93e6c5d1cb4412bda0f92dbc175a02daab04c6096da8d4736e7c3d251381b10b
我试图用以下参数计算hmac(符合rfc),但它不起作用:
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的参数究竟是什么?
答案 0 :(得分:3)
以下是Forge(JS实施TLS 1.0)的相关来源:
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;
};
处理完成消息的代码有点长,可以是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协议。这是"包装"或"信封"用于特定于内容的消息类型。它总是这样:
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
所以它总是有一个版本。完成消息是一种握手消息。所有握手消息的内容类型为22.握手消息如下所示:
struct {
HandshakeType msg_type;
uint24 length;
body
} Handshake;
握手消息是其他消息的另一个信封/包装器,如完成消息。在这种情况下,正文将是一个完成的消息(HandshakeType 20),如下所示:
struct {
opaque verify_data[12];
} Finished;
要实际发送完成消息,您必须将其包装在握手消息信封中,然后像任何其他消息一样,您必须将其包装在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,如上所述,然后将其附加到片段。然后加密片段(如果使用块密码则添加适当的填充)并将其替换为加密结果。所以,当你完成后,你仍然有一个类型,版本,长度和片段的记录,但片段是加密的。
所以,只有这样我们才能清楚,当您为完成消息计算MAC时,想象一下将上面的TLSPlainText(假设没有按照您指示的压缩)传递给函数。此函数接受此TLSPlainText记录,该记录具有类型,版本,长度和片段的属性。上面的HMAC功能在记录上运行。 HMAC密钥和序列号(此处为0)通过会话状态提供。因此,您可以看到HMAC功能所需的一切都可用。
无论如何,希望这能更好地解释协议如何运作,并且可能会揭示您的实施出现了什么问题。