WebRTC的STUN消息完整性验证
WebRTC revision 8146
2014年底至2015年初,戴维营里开始WebRTC实时音视频聊天项目,并开始研究优化WebRTC的一些代码.这里仅仅简单记录一下研究打洞协议STUN源码过程中的一些东西.
WebRTC实时音视频通话技术最近两年比较火,他是基于P2P的架构实现,
通话双方在会话发起之后,要信令服务器的配合双方建立P2P链接.而大家都知道,建立P2P链接之前需要各种NAT类型的网络穿透技术(俗称打洞),目前打洞协议标准主要是STUN/TURN协议.ICE框架是组合运用STUN/TURN协议来达到打洞目的,当STUN建立UDP的P2P穿透失败时,则退回到采用TURN服务器中转来进行通信.因为不是所有的NAT网络都是可以成功穿透的.那么WebRTC框架在处理STUN协议数据的时候要根据标准的RFC5389(STUN)和RFC5766(TURN)文档来实现.
RFC5389文档地址:
https://tools.ietf.org/html/rfc5389
在RFC5389的15.4节有关于STUN消息的完整性验证的定义描述:
15.4. MESSAGE-INTEGRITY
The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of
the STUN message. The MESSAGE-INTEGRITY attribute can be present in
any STUN message type. Since it uses the SHA1 hash, the HMAC will be
20 bytes. The text used as input to HMAC is the STUN message,
including the header, up to and including the attribute preceding the
MESSAGE-INTEGRITY attribute. With the exception of the FINGERPRINT
attribute, which appears after MESSAGE-INTEGRITY, agents MUST ignore
all other attributes that follow MESSAGE-INTEGRITY.
The key for the HMAC depends on whether long-term or short-term
credentials are in use. For long-term credentials, the key is 16
bytes:
key = MD5(username ":" realm ":" SASLprep(password))
That is, the 16-byte key is formed by taking the MD5 hash of the
result of concatenating the following five fields: (1) the username,
with any quotes and trailing nulls removed, as taken from the
USERNAME attribute (in which case SASLprep has already been applied);
(2) a single colon; (3) the realm, with any quotes and trailing nulls
removed; (4) a single colon; and (5) the password, with any trailing
nulls removed and after processing using SASLprep. For example, if
the username was 'user', the realm was 'realm', and the password was
'pass', then the 16-byte HMAC key would be the result of performing
an MD5 hash on the string 'user:realm:pass', the resulting hash being
0x8493fbc53ba582fb4c044c456bdc40eb.
For short-term credentials:
key = SASLprep(password)
where MD5 is defined in RFC 1321 [RFC1321] and SASLprep() is defined
in RFC 4013 [RFC4013].
The structure of the key when used with long-term credentials
facilitates deployment in systems that also utilize SIP. Typically,
SIP systems utilizing SIP's digest authentication mechanism do not
actually store the password in the database. Rather, they store a
value called H(A1), which is equal to the key defined above.
Based on the rules above, the hash used to construct MESSAGE-
INTEGRITY includes the length field from the STUN message header.
Prior to performing the hash, the MESSAGE-INTEGRITY attribute MUST be
inserted into the message (with dummy content). The length MUST then
be set to point to the length of the message up to, and including,
the MESSAGE-INTEGRITY attribute itself, but excluding any attributes
after it. Once the computation is performed, the value of the
MESSAGE-INTEGRITY attribute can be filled in, and the value of the
length in the STUN header can be set to its correct value -- the
length of the entire message. Similarly, when validating the
MESSAGE-INTEGRITY, the length field should be adjusted to point to
the end of the MESSAGE-INTEGRITY attribute prior to calculating the
HMAC. Such adjustment is necessary when attributes, such as
FINGERPRINT, appear after MESSAGE-INTEGRITY.
WebRTC框架源码中处理STUN协议的源码文件是:
webrtc/p2p/base/stun.cc
源码文件中处理消息完整性验证的函数代码是在128行开始:
// Verifies a STUN message has a valid MESSAGE-INTEGRITY attribute, using the
// procedure outlined in RFC 5389, section 15.4.
bool StunMessage::ValidateMessageIntegrity(const char* data, size_t size,
const std::string& password) {
// Verifying the size of the message.
if ((size % 4) != 0) {
return false;
}
// Getting the message length from the STUN header.
uint16 msg_length = rtc::GetBE16(&data[2]);
if (size != (msg_length + kStunHeaderSize)) {
return false;
}
// Finding Message Integrity attribute in stun message.
size_t current_pos = kStunHeaderSize;
bool has_message_integrity_attr = false;
while (current_pos < size) {
uint16 attr_type, attr_length;
// Getting attribute type and length.
attr_type = rtc::GetBE16(&data[current_pos]);
attr_length = rtc::GetBE16(&data[current_pos + sizeof(attr_type)]);
// If M-I, sanity check it, and break out.
if (attr_type == STUN_ATTR_MESSAGE_INTEGRITY) {
if (attr_length != kStunMessageIntegritySize ||
current_pos + attr_length > size) {
return false;
}
has_message_integrity_attr = true;
break;
}
// Otherwise, skip to the next attribute.
current_pos += sizeof(attr_type) + sizeof(attr_length) + attr_length;
if ((attr_length % 4) != 0) {
current_pos += (4 - (attr_length % 4));
}
}
if (!has_message_integrity_attr) {
return false;
}
// Getting length of the message to calculate Message Integrity.
size_t mi_pos = current_pos;
rtc::scoped_ptr<char[]> temp_data(new char[current_pos]);
memcpy(temp_data.get(), data, current_pos);
if (size > mi_pos + kStunAttributeHeaderSize + kStunMessageIntegritySize) {
// Stun message has other attributes after message integrity.
// Adjust the length parameter in stun message to calculate HMAC.
size_t extra_offset = size -
(mi_pos + kStunAttributeHeaderSize + kStunMessageIntegritySize);
size_t new_adjusted_len = size - extra_offset - kStunHeaderSize;
// Writing new length of the STUN message @ Message Length in temp buffer.
// 0 1 2 3
// 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// |0 0| STUN Message Type | Message Length |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
rtc::SetBE16(temp_data.get() + 2,
static_cast<uint16>(new_adjusted_len));
}
char hmac[kStunMessageIntegritySize];
size_t ret = rtc::ComputeHmac(rtc::DIGEST_SHA_1,
password.c_str(), password.size(),
temp_data.get(), mi_pos,
hmac, sizeof(hmac));
ASSERT(ret == sizeof(hmac));
if (ret != sizeof(hmac))
return false;
// Comparing the calculated HMAC with the one present in the message.
return memcmp(data + current_pos + kStunAttributeHeaderSize,
hmac,
sizeof(hmac)) == 0;
}
如果我们需要去掉消息完整性验证,则可以简单的短路处理这个函数,直接返回true.
