In WebRTC, DTLS is introduced to encrypt the communication process in order to ensure the security of media transmission. The function and principle of DTLS is similar to SSL/TLS, which is to make insecure communication process secure. The difference between them is that DTLS is suitable for encrypting UDP traffic, while SSL/TLS is suitable for encrypting TCP traffic. It is the transport layer protocol used that causes some of the differences in their implementation.

The basic concept

Symmetric key encryption technology

Symmetric key encryption means that the encryption and decryption processes use the same key. Common symmetric encryption algorithms include DES, 3DES, AES, Blowfish, IDEA, RC5, and RC6.

Asymmetric encryption key encryption technology

Asymmetric key encryption means that different keys are used for encryption and decryption, which are called public keys and private keys respectively. The public key is well-known, but the key can only be held by the target host of the packet. Compared with symmetric encryption technology, its advantage is that it does not worry about the key being stolen by others in the communication process. The disadvantage is that the decryption speed is slow and consumes more CPU resources. Common asymmetric encryption algorithms include RSA, DSA, and DH.

A digital signature

A digital signature is a special encryption checksum attached to a packet, which uses the asymmetric encryption key encryption technology. The digital signature prevents the packet from being tampered with. Once the packet is tampered with by an attacker, the receiver can detect the packet immediately by verifying and matching it. The digital signature process is as follows:

Sender will be A message digest (A message through the hash algorithm to generate the SHA – 1) to generate encrypted with A private key signature, with clear text message sent to the receiver B, the receiver B can be calculated through the received information to get two copies of the message digest, comparing the two message digest is equal to verify whether message been tampered with,

  1. The plaintext message generates digest 1 by using the same hash algorithm as the sender.
  2. Abstract 2 is generated after the signature is decrypted by public key.

The digital certificate

Digital certificates are issued by recognized and trusted certification authorities and are not easily forged. Including the following:

  • Certificate serial number
  • Certificate signature algorithm
  • Certificate issuer
  • The period of validity
  • Public key
  • The digital signature of the certificate issuing authority

A digital certificate can be used by the receiver to verify the identity of the peer. Receiver (such as browser) received a certificate of end (such as a Web server), to check the signature authority digital signature, in general, the receiver will be pre-installed in advance the signature of the many common agency certificate (containing the public key), using the public key can be validated for signature in advance. Take Google as an example. If you go to the Google home page in a browser, click the exclamation mark in the upper left corner to see the complete information about the Google certificate, including all of the above:

The resources

Zhangbuhuai.com/post/https-…

SSL/TLS

Introduction to the

To understand DTLS, let’s start with the familiar SSL/TLS. Secure Socket Layer (SSL) and Transport Layer Security (TLS) are two evolution stages of the same thing. They are also Security layers added between the application Layer and the Transport Layer. This Security Layer was originally called SSL. Introduced by Netscape, it was later standardized by the IETF and called TLS. The purpose of SSL/TLS is to address three kinds of risks in Internet communication:

  1. Risk of eavesdropping: third parties can know the contents of communications;
  2. Tampering risk: a third party may modify the content of communication;
  3. Impersonation risk: Third parties can impersonate others to participate in communications.

The SSL/TLS protocol addresses the above three risks by doing the following:

  1. All messages are encrypted so that third parties cannot eavesdrop;
  2. With data signature and verification mechanism, once tampered, communication parties can immediately discover;
  3. Have identity certificate, prevent others to impersonate.

Protocol stack

SSL/TLS is built on the TCP transport layer. SSL/TLS is most commonly used in HTTPS. By adding SSL/TLS to HTTP and TCP, insecure HTTP becomes secure HTTPS. The protocol stack is shown in the figure below:

SSL/TLS encryption is implemented by symmetrically encrypting data using dynamic keys, which are negotiated by handshake. The following information needs to be negotiated during the SSL/TLS handshake:

  1. Protocol version number;
  2. Encryption algorithm, including asymmetric encryption algorithm, dynamic key algorithm;
  3. Digital certificate, the transmission parties through the exchange of certificates and signature verification to verify each other’s identity;
  4. Dynamic key. Asymmetric encryption consumes a lot of performance, so the main communication process uses dynamic key for symmetric encryption. The dynamic key used in symmetric encryption is transmitted through asymmetric encryption during the handshake.

handshake

Take TLS 1.2 as an example:

The handshake process, as shown in the figure above, is generally divided into three processes: plaintext communication process, asymmetric encryption communication process, symmetric encryption communication process;

  1. Plaintext communication: When both ends send Hello messages to each other for the first time, the messages are sent in plaintext because the encryption mode to be used is not negotiated.

    A. the Client Hello: The client sends a handshake to the server and tells the other side the supported SSL/TLS version, encryption suite (including algorithms used in asymmetric encryption and, algorithms used in asymmetric encryption, pseudo-random function PRF for key generation) and data compression algorithm (this field is not available after TLS1.3) in the handshake message. It also carries a Session ID. Because the overhead of the handshake process is high, the Session ID can be used to reuse the previous handshake results (such as the version number, encryption algorithm suite, and master-key) in the next TLS handshake process, skipping the subsequent tedious handshake process. And generate A random number A, also tell each other;

    B. Server Hello: The Server responds with a Server Hello message with the negotiated TLS/SSL version number, encryption suite, and data compression algorithm. If the Server agrees with the client to reuse the last Session, it returns the same Session ID. Otherwise, a new Session ID is inserted.

    C. Server Certificate (Optional) : Carries the Server digital Certificate (CA) to authenticate the Server. The CA contains the public key used for asymmetric encryption on the Server. This step is required in most cases, except that the client and server use some anonymous key negotiation algorithms (such as the anonymous DH algorithm).

    D. (Optional) Server Key Exchange: When some asymmetric encryption algorithms (such as THE DH algorithm) are used, the information in the Server Certificate is insufficient, or the Server Certificate is omitted (the Server identity is not authenticated) in some communication processes. Additional information in the Server Key Exchange is required to help the client generate a pre-master Key.

    E. Client Sertificate Request (optional) : In scenarios with high security requirements, such as bank payment, the server requires the Client to provide the Client’s identity certificate.

    F. Server Hello Done: Indicates that Server Hello is finished.

    G. Client Certificate (Optional) : If the server asks the Client to provide a digital Certificate for identity authentication, the Client sends its own identity Certificate to the server.

  2. Asymmetric encryption communication process: due to the asymmetric encryption communication performance is bad, actually in the process of actual communication using symmetric encryption communication, in order to guarantee the security of symmetric encryption communication process, also is the need to avoid the symmetric encryption key is stolen, the key in the process of negotiation is encrypted by using asymmetric encryption.

    A. Client Key Exchange: After authenticating the ID card of the server, the client obtains the public key of the server and generates A random number C as the pre-master key. The client locally uses the previous random number A and B and the generated number C to generate the symmetric encryption key master-key. Use the server public key to encrypt the pre-master key and send it to the server.

    B. Certificate Verify (optional) : If the server requires the Client to provide a Client Certificate, the Client must send Certificate Verify immediately after sending the Client Key Exchange. The content is a piece of data encrypted by the Client using its private Key and provided to the server using the Client’s public Key for decryption verification. This step is needed to ensure that the certificate sent by the client is indeed its own;

    C. Client Change Cipher Spec: prompts the server to use the master key for symmetric encryption communication.

    D. Client Handshake Finished: Indicates that the SSL/TLS Handshake is complete on the Client.

    E. Server Change Cipher Spec: prompts the client to use the master key for symmetric encryption communication.

    F. Server Handshake Finished: Indicates that the SSL/TLS Handshake on the Server ends.

  3. Symmetric encryption communication process: After the symmetric encryption algorithm and the symmetric encryption key are negotiated through the handshake process, the subsequent communication process, that is, the actual application communication process, uses symmetric encryption.

Handshake message format

The SSL/TLS handshake message format is as follows. The message type has been explained in the handshake above. The structure contains message type, message length, and message body.

enum {
       hello_request(0), client_hello(1), server_hello(2),
       certificate(11), server_key_exchange (12),
       certificate_request(13), server_hello_done(14),
       certificate_verify(15), client_key_exchange(16),
       finished(20)
       (255)
   } HandshakeType;

   struct {
       HandshakeType msg_type;
       uint24 length;
       select (HandshakeType) {
           case hello_request:       HelloRequest;
           case client_hello:        ClientHello;
           case server_hello:        ServerHello;
           case certificate:         Certificate;
           case server_key_exchange: ServerKeyExchange;
           case certificate_request: CertificateRequest;
           case server_hello_done:   ServerHelloDone;
           case certificate_verify:  CertificateVerify;
           case client_key_exchange: ClientKeyExchange;
           case finished:            Finished;
       } body;
   } Handshake;
Copy the code

Each message has its own body. The body contains information to be carried in the message during handshake. For example, ClientHello contains SSL/TLS version numbers, random numbers, Session IDS, optional encryption suites, and optional compression algorithms.

struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2.. 1 > 2 ^ 16 -; CompressionMethod compression_methods<1.. 2 ^ 8-1 >; } ClientHello;Copy the code

Answering questions

  1. When is the Server Certificate step not required during the handshake?

If the key exchange algorithm negotiated between the server and client is an anonymous algorithm, for example, the anonymous DH algorithm. Therefore, the Server Certificate step will be omitted if the following encryption suite is used:

CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = {0x00,0x18}; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = {0x00,0x1B}; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = {0x00,0x34}; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = {0x00,0x3A}; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = {0x00,0x6C}; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = {0x00,0x6D};Copy the code

The TLS RFC also makes it clear that using these anonymous algorithms is not secure because the client does not verify the identity of the server and is vulnerable to man-in-the-middle attacks.

The resources

The RFC: tools.ietf.org/html/rfc224… The TLS 1.0 tools.ietf.org/html/rfc434… The TLS 1.1 tools.ietf.org/html/rfc524… The TLS 1.2 (reference) in this paper, tools.ietf.org/html/rfc844… The TLS 1.3 BBS data: www.cnblogs.com/littleatp/p… Segmentfault.com/a/119000002… Halfrost.com/https_tls1-…

DTLS protocol

Introduction to the

The full name of DTLS is Datagram Transport Layer Security. The difference between DTLS and TLS is that it has a “Datagram”. The name means that DTLS is an encryption protocol for UDP transport. DTLS is designed to reuse as much of TLS’s existing code as possible, with minor modifications to accommodate UDP transport. DTLS and TLS have the same security mechanism and protection level, can also prevent message interception, tampering, and identity impersonation and other problems. In terms of version, DTLS and TLS also have a corresponding relationship as follows:

  • DTLS 1.0 corresponds to TLS 1.1
  • DTLS 1.2 corresponds to TLS 1.2
  • DTLS 1.3 corresponds to TLS 1.3

There should be no DTLS 1.1 to be consistent with the TLS version number.

Protocol stack

In WebRTC, the introduction of DTLS to encrypt RTP makes media communication secure. After the encryption key is negotiated through DTLS, RTP must also be upgraded to SRTP for communication after encryption with the key. The protocol stack is shown in the figure below:

handshake

TLS 1.2 and before did not attempt to solve DoS attacks, It wasn’t until TLS 1.3 that DoS attacks were addressed by adding HelloRetryRequest and cookies (and in THE RFC of TLS 1.3, mainly for non-connection-oriented channels, that is, UDP connections). Compared with TCP, UDP connections are more sensitive to DoS attacks, so DTLS added HelloVerifyRequest and cookies in version 1.0, which are used for the server to verify the client twice to avoid DoS attacks. Using DTLS 1.2 as an example (the process of TLS 1.3 and DTLS 1.3 is already very close), compared with TLS 1.2, DTLS 1.2 has most of the same steps, but there is an extra step of HelloVerifyRequest on the server side. The client also has a second ClientHello, as shown below:

After the server receives the Client Hello sent by the Client for the first time, it only generates a Cookie without any other operations and sends the HelloVerifyRequest message to the Client with the Cookie. Only after the Client sends the Client Hello again with the Cookie sent by the server does the handshake continue.

Handshake message format

The DTLS handshake message format is shown below. Compared to SSL/TLS, DTLS has a HelloVerifyRequest message (introduced during the handshake) in the message type. Message_seq, fragment_offset, and fragment_length fields are added to the structure. SSL/TLS is based on TCP, so there is no need to worry about replay, disorderly order, packet loss problems, reliable transmission by TCP to ensure; DTLS is based on UDP, which is a protocol of best effort. Therefore, DTLS needs to deal with replay, disorderly order, and packet loss by itself. DTLS has made some minor changes on the basis of reusing most TLS, adding three fields message_seq, fragment_offset, and fragment_length to the handshake message. The details are described in the next section.

enum { hello_request(0), client_hello(1), server_hello(2), hello_verify_request(3), // New field certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20), (255) } HandshakeType; struct { HandshakeType msg_type; uint24 length; uint16 message_seq; // New field uint24 fragment_offset; // New field uint24 fragment_length; // New field select (HandshakeType) { case hello_request: HelloRequest; case client_hello: ClientHello; case server_hello: ServerHello; case hello_verify_request: HelloVerifyRequest; // New field case certificate:Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done:ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished: Finished; } body; } Handshake;Copy the code

Each message also has its own body. The content of the body is the information carried in the message mentioned in the handshake. Most of the body content is the same as that of SSL/TLS.

  1. There are many HelloVerifyRequest messages, which need to carry cookies. The message body is as follows:
struct { ProtocolVersion server_version; opaque cookie<0.. 32 >; } HelloVerifyRequest;Copy the code
  1. The Cookie field is added to the ClientHello because the second ClientHello needs to carry Cookie information:
struct { ProtocolVersion client_version; Random random; SessionID session_id; opaque cookie<0.. 32 >; // New field CipherSuite cipher_suites<2.. 1 > 2 ^ 16 -; CompressionMethod compression_methods<1.. 2 ^ 8-1 >; } ClientHello;Copy the code

Implementation differences with SSL/TLS

Some of the differences between DTLS and SSL/TLS have been described in the handshake process and protocol above. In addition, DTLS adds some protection mechanisms against problems such as repetition, out-of-order and packet loss.

Handshake protection mechanism

The retransmission

TCP’s natural retransmission mechanism guarantees that messages will not be lost, whereas UDP has no guarantee. Therefore, DTLS adds an additional timeout retransmission mechanism to confirm the arrival of the handshake message. The process is as follows:

Take the first stage of the handshake as an example. After the Client sends Client Hello (without Cookie, which is different from the second Client Hello in the handshake process), a timer is started and the server returns HelloVerifyRequest. If the timer expires and the Client doesn’t receive the HelloVerifyRequest, then the Client will know that either the Client Hello message is missing or the HelloVerifyRequest message is missing, The Client will send the same Client Hello message again, and even if the server does send the Hello Verify Request and still receives the Client Hello message, it knows it needs to be retransmitted, The server sends the Hello Verify Request message again, and similarly, the server starts a timer to wait for the next message.

The serial number

TCP messages have their own sequence number, SEQ, and handle the problem of out-of-order, and UDP has no guarantee of out-of-order problems. To ensure the order of handshake messages, DTLS adds the Message_seq field to the handshake messages to facilitate the receiver to process out-of-order messages. The receiver processes messages belonging to the current step directly, providing a cache queue to cache messages that arrive early.

Message size limit

TCP is byte stream oriented, while UDP is packet oriented. Therefore, TCP automatically splits and assembles packets without the upper-layer concern. If UDP packets exceed the MTU (maximum transmission unit of the link layer) limit, they are forcibly fragmented at the IP layer, so that the size of each packet is smaller than the MTU. The IP layer of the receiver needs to reorganize the packet. In this way, much more work is done. The entire UDP packet is lost. Therefore, DTLS segments handshake messages directly on UDP. For this purpose, the fragment_offset and fragment_length in handshake messages represent the offset from the start of the message and the length of the packet, respectively.

Cookie

TLS 1.2 and before did not attempt to solve DoS attacks during the handshake above, It was not until TLS1.3 that the problem of DoS attacks was solved by adding HelloRetryRequest and cookies (and it was mentioned in THE RFC of TLS1.3 that it was mainly used for non-connection-oriented channels, i.e. UDP connections). UDP connections are more sensitive to DoS attacks than TCP because TCP can use the SYN Cookie mechanism to defend against DoS attacks. If the TLS handshake is used directly over UDP, the following two situations may occur:

  1. An attacker can consume resources on the server by sending a series of handshake start requests, for example, the server may allocate buffers for this, and the encryption process is also a very CPU intensive operation;
  2. The attacker can forge the IP address of the victim client to initiate a DTLS handshake to the server, forcing the server to send a Certificate message to the victim client. As mentioned above, the Certificate carries a lot of information, including digital certificates, so the message will be very large. The victim client has to accept a large number of unwanted messages.

Therefore, HelloVerifyRequest and Cookie were added to DTLS in version 1.0, which are used for the secondary verification of the server to the client to avoid DoS attacks. The specific implementation is as follows:

  1. When the Client sends Client Hello to the server for the first time, the server only generates a Cookie and sends it to the Client through HelloVerifyRequest, without performing operations such as allocating buffers. The handshake will not continue until the Client Hello with the same Cookie is received, which can make the attack of forged IP difficult to achieve (DoS attack using real IP is helpless);
  2. The HelloVerifyRequest is small enough that it will not cause a lot of data to be sent even if the server is used as a gun by an attacker to attack other machines.

encryption

SSL/TLS relies on TCP, so SSL/TLS has the following features:

  1. SSL/TLS cannot independently decrypt a single packet. SSL/TLS authentication of packets requires a serial number as input. In SSL/TLS, the serial number is not directly transmitted.
  2. Some encryption algorithms of SSL/TLS are not independently decrypted and need to rely on the last packet. A typical example is the RC4 stream encryption algorithm.

Due to the unreliability of UDP itself, to solve the first problem mentioned above, DTLS carries an explicit serial number in each record as input for decoding; As for the second problem, DTLS cannot support streaming encryption algorithms such as RC4.

Message replay detection

Message replay is also a DoS attack. An attacker can intercept the data sent by the sender and directly send it to the receiver intact to deceive the receiver. DTLS adds message replay detection similar to IPsec AH/ESP. A sliding bitmap window is used to receive messages. Based on the sequence number of the message, the Bitmap determines whether the message is too old. This feature is optional in DTLS because some UDP packets are repeated simply because of network errors.

Answering questions

  1. Do users need to implement DTLS themselves?

OpenSSL supports DTLS. After receiving a packet in WebRTC and determining that it is a DTLS packet, OpensslStreamAdaptor will hand over the remaining steps to OpenSSL, which basically does not need to be realized by the user.

  1. What is the payoff for an attacker doing a replay attack? Why does DTLS do replay detection? Would this cause the same problem if the sender, instead of the middleman, repeatedly sent a message?

www.pcmag.com/encyclopedi…

www.kaspersky.com/resource-ce…

Refer to some online cases: a. User A logs in to a website, and then the attacker directly records the login process and plays it back. Although the attacker does not know user A’s password, the attacker can log in successfully through the replay and achieve the purpose of account theft; B. User A logs in to A payment platform to transfer 100 yuan to USER B. User B records the communication process between USER A and the payment platform and plays it back, so that the payment platform will transfer A lot of money to user B.

In fact, DTLS is not only for WebRTC media transmission, for example, OpenSSL directly includes DTLS, DTLS may be used in some very important occasions. As a standard protocol, DTLS needs to consider its own security, so DTLS should be designed to prevent replay attacks.

For the second problem, the sender repeatedly sends a message, which is not a replay attack. Of course, malicious clients may want to consume server resources and frantically call some apis. DTLS cannot prevent such problems and needs to be ensured by upper-layer services.

The resources

The RFC: tools.ietf.org/html/rfc371… SRTP tools.ietf.org/html/rfc434… 1.0 tools.ietf.org/html/rfc634 DTLS… DTLS 1.2 (main reference for this article) tools.ietf.org/id/draft-ie… DTLS 1.3 BBS data: www.bbsmax.com/A/RnJW0Rpg5… Yq.aliyun.com/articles/61… Juejin. Cn/post / 684490…