美文网首页
WebRTC的STUN消息完整性验证

WebRTC的STUN消息完整性验证

作者: 戴维营教育 | 来源:发表于2016-03-14 16:46 被阅读1063次

    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.

    相关文章

      网友评论

          本文标题:WebRTC的STUN消息完整性验证

          本文链接:https://www.haomeiwen.com/subject/zapflttx.html