Disclaimer
Allsecuritysuggestionsandguidelinesinthistalkarecollectedfromreal-worldprojectsandexperiences.
Whenindoubthowtoapplythesetechniquesinyourownprojects,pleaseconsultasecurityprofessionalyoutrust.
ObligatoryDisclaimer:
MQTT Protocol Characteristics
MessagingProtocol
Binary
Publish / Subscribe
Data Agnostic
Lightweight
Easy
Publish / Subscribe
temperature sensor
MQTT-Broker
laptop
mobile device
publish: “21°C“publish: “21°C“
publish: “21°C“
subscribe
subscribe
The mantra of any good security engineer is: 'Security is a not a product, but a process.' It's more than designing strong cryptography into a system; it's designing the entire system such that all security measures, including cryptography, work together.
- Bruce Schneier
“
Reduced Attack Surface
— Client initiates TCP connection
— Client doesn’t need (and shouldn’t be) addressable from outside
— IPv6 Privacy Mode should be used
— NATs can further decrease attack surface
Secure communication is when two entities are communicating and do not want a third party to listen in. For that they need to communicate in a way not susceptible to eavesdropping or interception.
- Wikipedia on “Secure Communication”
“
TLS
— Cryptographic protocol
— Provides a secure communication channel between client and server
— TLS handshake initiates TLS session
— Client validates X509 certificate from server
TLS Handshake
Source:W
ikim
ediaCom
mon
s:https://com
mon
s.wikim
edia.org/w
iki/F
ile%3A
Full_TLS_1.2_Ha
ndshake.svg
Best Practices
1 Always use TLS if possible
2 Use Certificates from trusted CAs
3 Always validate the X509 certificate chain
4 Use highest TLS version andsecure cipher suites
TLS
— Encrypted communication
— Widely available
— Session Resumption Possible
— Prohibits Man-In-The-Middle attacks
— CPU, RAM & Network Overhead
ADVANTAGES DISADVANTAGES
TLS Session Resumption
— Reuse an already negotiated TLS session
— Not all TLS libraries and MQTT brokers implement session resumption
— Session IDs &Session Tickets
X509 Client Certificates
— Client sends certificate as part of the TLS handshake
— The server is able to verify the identity of the client and can abort the handshake
— Authentication on Transport Layer
— Some brokers can use certificates for authorization
X509 Client Certificate Provisioning + Revocation
— How to deploy certificates to MQTT clients?
— Works great if PKI is already in place
— Certificate Revocation Lists for small deployments
— Online Certificate Status Protocol for online certificate validation
MQTT Ports
8883Official IANA Port
MQTT + TLSMQTT + TCP
1883Official IANA Port
80 / 443Standard HTTP Ports
MQTT + Websockets
Firewall Best Practices
— Only listen on defined ports
— Only allow traffic from a specific IP range if possible
— Block all protocols except TCP *
— Create iptables rules for common attacks
*ICMPv6maybeneededforIPv6
OS Best Practices (Linux)
— Keep libraries and software updated
— Disallow Root Access and use SSH Keys for SSH
— Setup SELinux
— Install Tools like Fail2Ban, Snort, OSSEC
Broker specific security mechanisms
— Authentication
— Authorization
— Throttling
— Message Size Restrictions
Criteria for Broker selection
— What security features does the broker have out of the box?
— Does the broker have a pluggable security mechanism
— Is TLS supported?
— Do security features thwart the broker?
Authentication is the act of confirming the truth of an attribute of a single piece of data or entity.
- Wikipedia on “Authentication”“
CONNECT Response Codes
Response Code Description
0 ConnectionAccepted
4ConnectionRefused,badusernameor
password
5 ConnectionRefused,notauthorized
Authentication Information
— Username + Password
— Client Identifier
— IP Address
— X509 Client certificate
Authorization and MQTT
— Authorization can restrict Topics a client can publish or subscribe to.
— Black and Whitelists
— Message characteristics also possible to restrict (Retained, QoS)
OAuth 2.0
— Only Client Credentials Flow Applicable to MQTT
— Designed for HTTP but also usable for MQTT
— Uses JWT for Access Tokens on CONNECT
— Online (JWKS) and Offline Validation (SignatureValidation) Possible
OAuth 2.0 Advantage over Credentials
— MQTT Brokers will never see a password - Only Authorization Servers which issue Access Tokens
— Online and Offline Validation Possible
— Access Tokens only have a limited lifetime and can get revoked
— Brokers are just Resource Servers - Access Tokens could also be valid for other Resource Servers
— Authorization information can get encoded in the JWT by using custom claims
Payload Encryption - Advantages
— A completely secure end-to-end encryption of application data can be achieved
— Works well on constrained devices where no TLS can be used.
— Adds another layer of security for topics which are used for delivering confidential information
— Encryption / decryption can be resource intensive on constrained devices
— A secure provisioning of the keys to the MQTT clients must be implemented.
— Doesn’t prevent from man-in-the-middle attacks and replay attacks.
ADVANTAGES DISADVANTAGES
Mechanisms
Checksum MAC Digital Signature
DataIntegrity ✔ ✔ ✔Authentication ✘ ✔ ✔Non-Repudiation ✘ ✘ ✔
Key None Symmetric Assymetric
DataIntegrity:Therecipientcanmakesurethatthedatawasnotmodified(accidentally).
Authentication:Therecipientcanmakesurethatthemessageoriginatesfromatrustedsender,becauseonlytrustedpartieshaveaccesstothekeyforcreatingandverifyingthestamp.
Non-Repudiation:Onlythesenderofthemessage–whohasaccesstotheprivatekey–isabletocreatethestamp.Otherpartiescanverifythesignaturewiththepublickeybuttheyarenotabletocreatethestampthemselves.
A key concept is that security is an enabler, not a disabler... security enables you to keep your job, security enables you to move into new markets, security enables you to have confidence in what you're doing.
- Gene Spafford
“