The Publish-Subscribe messaging pattern is a solution to message dissemination and delivery problems. Instead of directly transmitting a message to an end receiver (e.g. the way the traditional request-response pattern works), a publisher publishes the message under a relevant topic to an intermediary server (broker). Receivers communicate their demand for receiving specific messages with the broker, not necessarily from specific publishers by subscribing to certain topics. Since the publisher and subscriber are not aware of the other party, the broker is responsible for capturing published messages, binding the subscriptions to the topics, and delivering the messages to the interested recipients.
Figure 1. Publish-Subscribe Architecture
Communication protocols based on the Publish-Subscribe pattern have been used to connect different information systems and software components since the late 1980s. Such technologies, with the help of message queuing methods, have evolved around the main feature of the publish-subscribe pattern that is decoupling sender (publisher) and receiver (subscriber). This property enables message producers and consumers to communicate across time, space, and synchronization [1]. Such dissociation of publishers and subscribers, combined with content-based routing protocols, facilitates many-to-many communications.
STRIDE threat modeling and solution discussion
The decoupled multicast nature and many-to-many communications in the publish-subscribe pattern introduce the system components to various threats such as unwanted traffic flood, node compromise attacks, data tampering, privacy violation, and so on. We have identified the potential risks based on Microsoft’s STRIDE model [2]. Figure 2 illustrates the relations of STRIDE threats to possible attacks and potential solutions in a publish-subscribe ecosystem.
Figure 2. STRIDE in publish-subscribe
Spoofing identity
An adversary can access, guess, or rebuild a legitimate user’s credentials to impersonate an authenticated entity in the system. In a publish-subscribe environment, publishers, subscribers, and brokers are subject to spoofing attacks. An illegitimate publisher may connect to the system as an authentic one. The broker (or a network of brokers) gives it permission to publish to restricted topics, and the subscribers accept its messages as if they were from an authentic publisher. A disguised subscriber as well can subscribe to restricted topics and receive potentially confidential messages. A malicious broker can also introduce itself as a legitimate one to the system. If messages are not end-to-end encrypted, the fake broker is able to read the messages, or push crafted messages to certain critical topics, on behalf of authenticated publishers. Moreover, it may modify routing settings or drop messages. This negatively affects confidentiality, integrity, and availability of the information system.
Some publish-subscribe protocols support mutual authentication by TLS (using a certificate/private key) [3] or Simple Authentication and Security Layer (SASL) mechanisms [4]. TLS might be too heavy for constrained nodes since it imposes a fair amount of cryptographic computations on both broker and client. Although brokers might be resourceful nodes and capable of taking the cost, publishers are usually thin nodes which are designed for specific purposes. For example, a battery-powered smoke detector that sends the measurement results to a local receiver might not have enough resources to maintain a TLS connection.
Tampering with Data
Data tampering involves unauthorized modification of stored or in-flight data. After the authentication phase, nodes in a publish-subscribe system generally communicate with each other via data and acknowledgement messages. If either is maliciously changed, the integrity of the message is at risk. Four types of communications can be involved in such a system:
- Publisher – Broker
- Broker – Broker (message routing)
- Broker – Subscriber
- Publisher – Subscriber (via broker)
The authenticity and integrity of messages can be verified at the transport or message level. TLS, as a transport level protection, when coupled with proper certificate validation can be used to protect against tampering. Message-level mechanisms such as Digital Signature or MAC (Message Authentication Code) may ensure that an attacker cannot modify messages during transit, and to mitigate the risk of a replay attack; especially if using TLS is not feasible, or there are untrusted clients in the environment which can access restricted topics. For example, adding a Digital Signature or keyed-hash message authentication code (HMAC) of a published message content to the message helps the receiver to validate the message.
Since Digital Signature mechanisms are asymmetric, the key provisioning needs make decoupling publishers and subscribers challenging. It is a good choice if a single publisher (which holds the private key) publishes to a certain topic. On the other hand, HMAC employs a shared key (that should be securely exchanged before the connection, e.g., embedded in a tamper-proof hardware module) with which holders can both sign and verify messages. HMAC calculations are typically faster than Digital Signature ones and consume fewer resources on constrained devices. The disadvantage is that all nodes that have the shared key can sign any message (lack of non-repudiation).
Repudiation
Repudiation threats involve situations where there is no evidence a user has taken an action in the system. For example, if a publisher posts an illegal message to a topic, there should be enough proof that the publisher has sent the message by intention.
Since Digital Signatures use asymmetric cryptography, no one other than the holder of the private key can sign malicious messages unless the private key is leaked. Therefore, Digital Signatures provide non-repudiation.
Although HMAC uses symmetric algorithms, if the subscriber stores the shared key in a tamper-proof hardware security module that calculates the tag and never releases the key, it can provide non-repudiation as well.
Information Disclosure
Information disclosure is about accessing confidential information by unauthorized individuals. In a publish-subscribe environment, sensitive messages can be exposed while in transfer among publisher-broker-subscriber or at rest.
TLS can provide strong protection by encrypting the transport layer. Publishers and subscribers must validate the broker’s certificate, and establish a secure channel to it. In cases where even brokers are not allowed to access the message content, or clients are not able to handle TLS, end-to-end encryption is required. Although, this opposes the nature of publish-subscribe systems in which publishers and subscribers are supposed to be decoupled.
In addition to protecting the communication channels, brokers must store the session information and in-flight messages in a secure database that is either encrypted by the broker application or is on a protected file system. Moreover, brokers must restrict access to system feedback and status topics. For example, it is bad practice if a broker publicly publishes the server status, detailed error messages, metadata, and so forth. Additionally, by implementing access control mechanisms such as role-based access control (RBAC), brokers can explicitly specify users’ or roles’ access to each topic.
Denial of Service
Denial of service (DoS) attacks prevent the system from providing service to legitimate users. Publish-subscribe networks are susceptible to such attacks due to their centralized nature. Slow publishers or subscribers, verbose publishers, mishandled exceptions, large messages, etc. may overwhelm the broker and exhaust its available resources. Both malicious and benign nodes in a network can cause DoS. Implementing proper authentication and encryption mechanisms significantly protects against deliberate attempts. To prevent resource exhaustion caused by bad broker implementation or configurations, the broker should:
- Return a reply code and close the connection to avoid ambiguous states after an error occurrence. For example, syntax errors, oversized data, and failed authentication attempts.
- Close the connections and release the resources after a configurable amount of time.
- Check if a publisher or subscriber is authorized to request higher guaranteed delivery levels.
- Mirror topic queues across multiple nodes.
- Monitor memory and disk usage and dedicated resources accordingly.
- Set general and client-specific resource consumption limits (E.g., number of concurrent connections, message size, publish rate to certain topics, etc.).
Elevation of privilege
An unauthorized user gains access to privileged functions and takes actions beyond its allowed expected behavior. For example, a temperature sensor that is programmed to publish the recorded temperature can be tricked to send a delete device command. Such attacks are possible if there are not enough authorization schemes and device access control mechanisms in place.
References
[1] Patrick Th. Eugster, Pascal A. Felber, Rachid Guerraoui, and Anne-Marie Kermarrec. 2003. The many faces of publish/subscribe. ACM Comput. Surv. 35, 2 (June 2003), 114-131. DOI=https://dl.acm.org/doi/10.1145/857076.857078
[2] The STRIDE Threat Model, https://docs.microsoft.com/en-us/previous-versions/commerce-server/ee823878(v=cs.20)
[3] The Transport Layer Security (TLS) Protocol Version 1.2, https://datatracker.ietf.org/doc/html/rfc5246
[4] Simple Authentication and Security Layer (SASL), https://datatracker.ietf.org/doc/html/rfc4422
[5] OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0, https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html