This Chapter is provided for guidance only and is Non Normative. However, it is strongly recommended that Server implementations that offer TLS SHOULD use TCP port 8883 (IANA service name: secure-mqtt).
There are a number of threats that solution providers should consider. For example:
- Devices could be compromised
- Data at rest in Clients and Servers might be accessible
- Protocol behaviors could have side effects (e.g. “timing attacks”)
- Denial of Service (DoS) attacks
- Communications could be intercepted, altered, re-routed or disclosed
- Injection of spoofed Control Packets
MQTT solutions are often deployed in hostile communication environments. In such cases, implementations will often need to provide mechanisms for:
- Authentication of users and devices
- Authorization of access to Server resources
- Integrity of MQTT Control Packets and application data contained therein
- Privacy of MQTT Control Packets and application data contained therein
Guidance on using MQTT within the NIST Cyber Security Framework can be found in the MQTT supplemental publication, MQTT and the NIST Framework for Improving Critical Infrastructure Cybersecurity [MQTT NIST]. The use of industry proven, independently verified and certified technologies will help meet compliance requirements.
There are many security concerns to consider when implementing or using MQTT. The following section should not be considered a “check list”.
An implementation might want to achieve some, or all, of the following:
The CONNECT Packet contains Username and Password fields. Implementations can choose how to make use of the content of these fields. They may provide their own authentication mechanism, use an external authentication system such as LDAP or OAuth tokens, or leverage operating system authentication mechanisms.
Implementations passing authentication data in clear text, obfuscating such data elements or requiring no authentication data should be aware this can give rise to Man-in-the-Middle and replay attacks. Section 5.4.5 Privacy of Application Messages and Control Packets introduces approaches to ensure data privacy.
A Virtual Private Network (VPN) between the Clients and Servers can provide confidence that data is only being received from authorized Clients.
An implementation might allow for authentication where the credentials are sent in an Application Message from the Client to the Server.
Solace Implementation Note
A Solace server supports TLS/SSL Client Certificates, OAuth v2 (including OpenID Connect), LDAP, RADIUS, and internal database authentication to authenticate MQTT Clients. See the “User Name” section of this document for more information on authentication.
An implementation may restrict access to Server resources based on information provided by the Client such as User Name, Client Identifier, the hostname/IP address of the Client, or the outcome of authentication mechanisms.
Solace Implementation Note
Solace ACLs are applied to MQTT Clients based on the MQTT User Name used to authenticate a connection. ACLs provide:
- Source IP-based connection access control. In the case of WebSocket, the X-Forwarded-For HTTP header field (if present) is used to identify the originating IP address.
- Publisher access controls on a per-topic basis.
- Subscriber access controls on a per-topic basis.
- Subscriber access controls on a per-share-name basis for shared subscriptions.
The MQTT protocol is not trust symmetrical: it provides no mechanism for the Client to authenticate the Server.
Where TLS is used, SSL Certificates sent from the Server can be used by the Client to authenticate the Server. Implementations providing MQTT service for multiple hostnames from a single IP address should be aware of the Server Name Indication extension to TLS defined in section 3 of RFC 6066 .This allows a Client to tell the Server the hostname of the Server it is trying to connect to.
An implementation might allow for authentication where the credentials are sent in an Application Message from the Server to the Client.
A VPN between Clients and Servers can provide confidence that Clients are connecting to the intended Server.
Applications can independently include hash values in their Application Messages. This can provide integrity of the contents of Publish Control Packets across the network and at rest.
The use of VPNs to connect Clients and Servers can provide integrity of data across the section of the network covered by a VPN.
TLS can provide encryption of data sent over the network. There are valid TLS cipher suites that include a NULL encryption algorithm that does not encrypt data. To ensure privacy Clients and Servers should avoid these cipher suites.
An application might independently encrypt the contents of its Application Messages. This could provide privacy of the Application Message both over the network and at rest. This would not provide privacy for other properties of the Application Message such as Topic Name.
Client and Server implementations can provide encrypted storage for data at rest such as Application Messages stored as part of a Session.
The use of VPNs to connect Clients and Servers can provide privacy of data across the section of the network covered by a VPN.
Application designers might need to consider appropriate strategies to achieve end to end non-repudiation.
Client and Server implementations using TLS should provide capabilities to ensure that any SSL certificates provided when initiating a TLS connection are associated with the hostname of the Client connecting or Server being connected to.
Client and Server implementations using TLS can choose to provide capabilities to check Certificate Revocation Lists (CRLs ) and Online Certificate Status Protocol (OCSP) to prevent revoked certificates from being used.
Physical deployments might combine tamper-proof hardware with the transmission of specific data in Application Messages. For example a meter might have an embedded GPS to ensure it is not used in an unauthorized location. is a standard for implementing mechanisms to authenticate a device’s identity using a cryptographically bound identifier.
Server implementations might monitor Client behavior to detect potential security incidents. For example:
- Repeated connection attempts
- Repeated authentication attempts
- Abnormal termination of connections
- Topic scanning (attempts to send or subscribe to many topics)
- Sending undeliverable messages (no subscribers to the topics)
- Clients that connect but do not send data
Server implementations might disconnect Clients that breach its security rules.
Server implementations detecting unwelcome behavior might implement a dynamic block list based on identifiers such as IP address or Client Identifier.
Deployments might use network level controls (where available) to implement rate limiting or blocking based on IP address or other information.
Client or Server authentication credentials, such as User Name and Password, that are lost or considered compromised should be revoked and/or reissued.
In the case of long lasting connections:
- Client and Server implementations using TLS should allow for session renegotiation to establish new cryptographic parameters (replace session keys, change cipher suites, change authentication credentials).
- Servers may disconnect Clients and require them to re-authenticate with new credentials.
Solace Implementation Note
TLS resumption is available only on PubSub+ Appliances.
Clients connected to a Server have a transitive trust relationship with other Clients connected to the same Server and who have authority to publish data on the same topics.
Implementations of Clients should be aware that some environments will require the use of SOCKSv5 proxies to make outbound Network Connections. Some MQTT implementations could make use of alternative secured tunnels (e.g. SSH) through the use of SOCKS. Where implementations choose to use SOCKS, they should support both anonymous and user-name password authenticating SOCKS proxies. In the latter case, implementations should be aware that SOCKS authentication might occur in plain-text and so should avoid using the same credentials for connection to a MQTT Server.
Implementers and solution designers might wish to consider security as a set of profiles which can be applied to the MQTT protocol. An example of a layered security hierarchy is presented below.
188.8.131.52 Clear communication profile
When using the clear communication profile, the MQTT protocol runs over an open network with no additional secure communication mechanisms in place.
184.108.40.206 Secured network communication profile
When using the secured network communication profile, the MQTT protocol runs over a physical or virtual network which has security controls e.g., VPNs or physically secure network.
220.127.116.11 Secured transport profile
18.104.22.168 Industry specific security profiles
It is anticipated that the MQTT protocol will be designed into industry specific application profiles, each defining a threat model and the specific security mechanisms to be used to address these threats. Recommendations for specific security mechanisms will often be taken from existing works including: