Datagram Transport Layer Security (DTLS)



The DTLS protocol ([RFC 6347]) is based on TLS protocol to provide similar security for the network traffic transported on datagram transport protocols (e.g. UDP). Usually the real time applications like media streaming and internet telephony are delay sensitive for the transported data so they use datagram transport to carry their data. DTLS  runs on UDP to secure the data in a transparent way (inserted between the application layer and transport layer). DTLS runs in application space without any kernel modifications. The DTLS preserves the in-order delivery of data which is not provided by the datagram transport. Current version of DTLS is 1.2

Why DTLS and NOT TLS for Datagram Transport

The answer is simply because using datagram transport like UDP means the packets could be lost or reordered and TLS cannot handle this (this is handled by TCP when it is used). So we take the TLS and add minimal changes to fix the unreliability problem and we call the result DTLS.

WhyDTLSMore specifically, the problems that are in TLS if datagram transport are used:

  • In TLS there is what is called integrity check which depends on the sequence number. For example record N is lost –> then the integrity check on record N+1 will fail because the wrong sequence number. The sequence numbers are implicit in the records. The record could also reach but in a wrong order. For example record N+1 reached before the record N.
  • The record could reach many times (replayed).
  • The TLS handshake will break if the handshake messages are lost.
  • Handshake message size is big (many kilobytes): as we know in UDP, datagrams are limited to 1500 bytes.

So the goal is changing TLS to solve the above problems and then we get DTLS. Briefly DTLS solves the problems by:

  • Banning the stream ciphers to make the records independent (don’t have the same cryptographic context – cipher key).
  • Adding explicit sequence numbers in the records.
  • Using retransmission timer for packet loss handling.
  • Handshake message fragmentation –> Each DTLS handshake message must contain fragment offset and fragment length.
  • Maintaining a bitmap window of received records so if a record is previously received it will be discarded.

The client automatically generates self-signed certificates for each peer. This means there is no certificate chain verification. The certificates themselves cannot be used to authenticate the peer because they are self-signed. So the DTLS provides encryption and integrity, but let the authentication to be done by the application.

Library Support For DTLS 1.2

Botan, GnuTLS, MatrixSSL, OpenSSL, wolfSSL

First Step In WebRTC



Here i will show you how to execute very simple WebRTC demo served by Apache web server . The example is how to get the media stream of the local device. I will take as an example the WebRTC “getUserMedia” example from the book “Real-Time Communication with WebRTC by Salvatore Loreto and Simon Pietro(O’Reilly)”. You can find the source code on the book’s GitHub page. Follow these steps:

  • Create a folder for your WebRTC project: # mkdir /var/www/html/webrtc
  • Create subdirector for Javascript files: # mkdir /var/www/html/webrtc/js
  • Open Apache configuration file “/etc/httpd/conf/httpd.conf” and add this line:

Alias  /webc  /var/www/html/webrtc

    Restart Apache: # systemctl restart httpd.service

Screenshot from 2015-03-08 20:20:28To debug your project, open the browser console (e.g. Chrome: More tools –> Javascript Console).

JSFIDDLE Framework

You can use jsfiddle framework to write, save, validate, and run your application online.


  • Update your browser (bug fixes). Using the developer edition is a good choice (e.g. Firefox Developer Edition).
  • Test your application on different browsers