MQTT Security Fundamentals: TLS / SSL

mqttsecurityfundamentals_part5

Welcome to the fifth part of the MQTT Security Fundamentals series. Last week, we looked at authentication and authorization on the application layer. This week, we tackle Transport Encryption with TLS.

Join us as we explore why TLS / SSL is expedient for a secure MQTT solution and talk about best practices for transport encryption with MQTT.

What is TLS?

Transport Layer Security (TLS) and Secure Sockets Layer (SSL) provide a secure communication channel between a client and a server. At the core, TLS and SSL are cryptographic protocols which use a handshake mechanism to negotiate various parameters to create a secure connection between the client and the server. After the handshake is complete, an encrypted communication between client and server is established and no attacker can eavesdrop any part of the communication. Servers provide a X509 certificate (typically issued by a trusted authority) that clients use to verify the identity of the server.

A detailed description of how TLS and the TLS handshake work is beyond the scope of this blog post. However, a good starting point for learning about TLS is this chapter of ‘High Performance Browser Networking’.

Why is TLS important?

Imagine that you are sending a postcard. It’s clear who the recipient of the card is and the postman will make sure that the card arrives. But, nothing prevents the postman from reading the content of the card. In fact, everyone who is involved in delivering the postcard can read the content of your postcard. A malicious postal worker could even alter the content of your card!

The essence of this scenario is also true for computer networks in general and the Internet in particular. Use of plain TCP/IP is like sending the postcard. The TCP packet passes through many infrastructure components (routers, firewalls, Internet Exchange Points) before it reaches the target. Every participant along the way can read the content of the packet in clear text (and even modify it). This is not a fictitious scenario, recent history shows that Internet traffic is frequently wiretapped by intelligence agencies. While most attackers don’t have a lot of resources to eavesdrop your connection, it’s not difficult for sophisticated attackers to perform Man-In-The-Middle-Attacks.

TLS is all about providing a secure communication channel. TLS ensures that the content of your communication can not be read or altered by third parties*.

*Assuming secure cipher suites are used and there are no undiscovered attacks on the TLS version used.

MQTT and TLS

MQTT relies on the TCP transport protocol. By default, TCP connections do not use an encrypted communication. To encrypt the whole MQTT communication, many MQTT brokers (such as HiveMQ) allow use of TLS instead of plain TCP. If you use the username and password fields of the MQTT CONNECT packet for authentication and authorization mechanisms, you should strongly consider using TLS.

Port 8883 is standardized for a secured MQTT connection. The standardized name at IANA is “secure-mqtt”. Port 8883 is exclusively reserved for MQTT over TLS.

TLS Overhead

There is a drawback to using MQTT over TLS: Security comes at a cost in terms of CPU usage and communication overhead. While the additional CPU usage is typically negligible on the broker, it can be a problem for very constrained devices which are not designed for computation-intensive tasks. Techniques such as Session Resumption can drastically improve the TLS performance.

The communication overhead of the TLS Handshake can be significant if the MQTT client connections are expected to be short-lived. While the amount of bandwidth the TLS handshake needs depends on many factors, some measurements show that establishing a new TLS connection can require up to a few kilobytes of bandwidth. Since every packet is encrypted in TLS, packets on the wire have additional overhead compared to the unencrypted packets.

If you use long-living TCP connections with MQTT (which you should!), the TLS overhead, especially the TLS Handshake overhead can be negligible. If you deal with many reconnects and you can’t use session resumption, then the overhead can be significant, especially if you are publishing very small MQTT messages. If every byte on the wire counts for your use case, TLS may not be the best option for you because of the overhead. Be sure to measure how much overhead TLS creates for your use case.

Session Resumption

We mentioned TLS session resumption in regards to TLS Overhead. In a nutshell, TLS session resumption techniques allow the reuse of an already negotiated TLS session after reconnecting to the server. The client and server don’t need to repeat the full TLS handshake. It’s important to note that some TLS libraries do not implement all session resumption techniques. In fact, some TLS libraries don’t implement any session resumption mechanism at all.

There are two session resumption mechanisms:

  • Session IDs: The server stores the secret state together with the session ID. When the client reconnects, it provides the session ID and the session can be resumed.
  • Session Tickets: The secret state of the server is transmitted to the client and is encrypted with a secret key only the server knows. The client sends this ticket back to the server when reconnecting. If the server can decrypt the contents again, the session is resumed with the state contained in the secret ticket.

HiveMQ supports session IDs but does not support session tickets.

TLS on constrained devices

Sometimes, TLS is not feasible for constrained devices due to insufficient resources. Depending on the ciphers used, TLS can be very computation intensive and can require many kilobytes of memory. If TLS is not possible with your devices, think about using payload encryption for your PUBLISH messages and at least hash or encrypt the password in the CONNECT message of your client. More on that topic in one of our upcoming posts.

It may also be an option to look into TLS-PSK cipher suites. These suites avoid the CPU intensive public key operations. TLS-PSK ciphers are not widely adopted yet, so you need to double check if your TLS library supports them.

Should I always use TLS with MQTT?

Short answer: Yes, if you can.

Long answer: If you can afford the overhead in CPU and bandwidth, then a secure communication channel is invaluable. If TLS is implemented properly on the client and server side, you ensure that no eavesdropper can intercept your communication and you get that additional layer of security that is important for application-level authentication and authorization.

Best practices

Always use TLS if you can

Always use TLS with MQTT if you can afford the additional bandwidth and your clients have enough computing power and memory for TLS. As a rule of thumb, always use encrypted communication channels, also for other protocols like HTTP.

Use the highest available TLS version possible

While TLS 1.0, TLS 1.1 and TLS 1.2 are not broken in practice (at least until now), you should always use the highest TLS version that is feasible for your MQTT clients. There are well-known attacks against TLS 1.0 and 1.1, which can be mitigated. Some attacks are designed to exploit HTTP. For example, the CRIME attack. At the time of writing there are no practically-applicable attacks against TLS 1.2.

Don’t use SSLv3

Don’t use SSLv3 or any prior versions. The POODLE attack showed that SSLv3 must be considered broken. All other SSL versions are also considered broken and should not be used.

Always validate the X509 certificate chain

To prevent Man-In-The-Middle attacks, have your MQTT clients validate the X509 certificate from the MQTT broker. Some sloppy client implementations use an “allow-all” approach (often in combination with self-signed server certificates). Never do this! Going the extra mile to validate certificates is always worth the effort.

Use certificates from trusted CAs

Certificates from trusted CAs are worth the extra money they cost. Self-signed certificates don’t play well with many TLS implementations and often lead to sloppy code. For example, code that doesn’t validate certificates and opens the door for Man-In-The-Middle attacks. If your MQTT broker is public-facing, a trusted certificate is a must. If you use MQTT over websockets, self-signed certificates are not optimal. Most modern web browsers don’t allow websocket connections to resources with untrusted certificates.

Use other security mechanisms

In addition to TLS, it is always a good idea to use further security mechanisms such as payload encryption, payload signature verifications, and authorization mechanisms. In general, more security never hurts.

Only use secure cipher suites

There are many insecure cipher suites available for TLS. Make sure to only allow secure cipher suites for your communication. Many cipher suites are known to be broken and don’t a false sense of security

We hope you enjoyed part five of the MQTT Security Fundamentals. Next week, we’re going to discuss X509 client certificate authentication in conjunction with TLS. If you want to get notified as soon as we publish the next post, subscribe to our newsletter or RSS feed. If you think we missed some important information, please use the comments to tell us. We are always open to questions and suggestions.

20 comments

  1. Harshit Bangar says:

    How can we verify if an mqtt broker supports ssl resumption? SSLyze doesn’t seem to work for mqtt.

    1. Hi Harshit,

      you can try with openSSL. You could for example take a look here: http://serverfault.com/a/566361

      Hope this helps!
      Dominik from the HiveMQ Team

  2. Dan says:

    How can i implement the TLS in C or C++

    1. Hi Dan,

      this depends a lot on what MQTT library you want to use. You can find code examples for all popular MQTT C and C++ libraries here: http://www.hivemq.com/mqtt-client-library-encyclopedia

      Hope this helps,
      Dominik from the HiveMQ Team

  3. Dan says:

    i have seen that . thanks

    how can i use a securely Connect for Embedded microcontroller (for example) with the MQTT.
    Where can i find simple Example ?

    Thanks

    1. Hi Dan,

      this post should be exactly what you need: http://www.hivemq.com/blog/mqtt-client-library-encyclopedia-paho-embedded

      Hope this helps,
      Dominik from the HiveMQ Team

  4. Dan says:

    thank you Dominik

    where can i find the explanation for this example?, because I am a beginner

    1. Hi Dan,

      since the example uses CyaSSL, I would recommend to take a look at their documentation to get familiar with the API. Typically SSL APIs aren’t the most straight-forward APIs one can imagine, so I would recommend to make yourself familiar with the APIs itself and the basic principles of TLS/SSL. After doing that I think the best way is to copy paste the code that’s already available and modify for your own use case.

      Hope this helps,
      Dominik

  5. Ani says:

    Is there any math calculation where we can see the performance degradation of the system when using TLS ?
    I would like to know how much will be affected the security using TLS with session resumption for different session ticket lifetime.

    Thank you

    1. Hi Ani,

      glad to see you take an interest in HiveMQ.
      Indeed we already investigated this interesting issue.
      Our findings can be found here.

      I hope this helps,
      Florian from the HiveMQ Team.

  6. Brano Zarnovican says:

    Does HiveMQ support TLS-PSK mentioned in this blog post ?

    I haven’t found any reference on how to configure PSK identities and secrets in your documentation. Nor have I found TLS-PSK in the list of supported key-exchange protocols on Oracle Java site.

    1. Hallo Brano,
      at this moment TLS-PSK is not supported in HiveMQ.

      Kind regards,
      Florian, from The HiveMQ Team.

  7. Praveen says:

    Hello,
    It was nice introduction on Session Resumption. This helped me a lot to understand the TLS and session resumption in MQTT. I have a question. Could you please check if you have answer to this ?
    I am presently using Mosquitto to connect to TLS server. My question is does Mosquitto supports TLS Session Resumption.?
    If yes which one would it support -> the “Session IDs” or “Session tickets” ? And also how this could be achieved.

    Thanks,
    Praveen

    1. Hi Praveen,

      Thank you for your kind words.
      We are glad that the post helped you.

      Regarding your question about Mosquitto, please ask them on the Mosquitto Mailing list.

      Best regards,
      Christian from the HiveMQ Team

  8. Hi HiveMQ Team

    I have been looking high and low and can’t find an implementation of MQTT using websockets on the client side for an ESP8266 / NodeMCU. Any ideas?

    Best regards
    Bruce

    1. Hi Bruce,

      Nice to see you are taking an interest in MQTT.
      I believe NodeMCU does not support websockets.
      See this feature request
      This library could be an alternative.
      Disclaimer: I did not test this library myself.
      Hope this helps.

      Kind regards,
      Florian from The HiveMQ Team.

  9. krishanu says:

    Can i implement some other security algorithm other than TLS ?

    1. Hallo Krishanu,

      Nice to see you’re taking an interest in MQTT and HiveMQ and are concern about security mechanisms.
      During the remainder of this blog series we specifically talk about different security measures like OAuth 2.0, Payload Encryption or MQTT Data Integrity.
      Is there another, specific mechanisms you are interested in?

      Kind regards,
      Florian from The HiveMQ Team.

  10. Michael Schmidt says:

    How would I implement TLS client hostname verification (i.e. validation whether the client DNS name matches the Common Name in its certificate) at TLS connection establishment on the HiveMQ side?

    1. Hi Micheal,

      Nice to see you’re taking an interest in MQTT and HiveMQ.

      The HiveMQ Plugin System offers the OnAuthenticationCallback which can be used to implement a authentication based on a certificate verification.

      If you need further assistance, feel free contact us again.

      Kind regards,
      Abdullah from the HiveMQ Team.

Leave a Reply

Your email address will not be published. Required fields are marked *