We put everything you need to know about MQTT and MQTT 5, the basic concepts, features and facts, into one comprehensive E-Book. You may download it here bit.ly/3XsgQK5
Great series, thanks. At 3:54, you say 'never use a leading slash'. You had a leading slash in your example in video #4 (/hans/will). Not sure whether that's a typo or whether wills are different? See th-cam.com/video/vVJk5rES5vY/w-d-xo.html
It's absolutely recommended to use wildcards! Wildcards are one of the essential MQTT features and are used in virtually all deployments I know of. Be sure to use proper permissions in your production system, though. If you're not sure how to there is the MQTT Security Essentials series on the HiveMQ blog that can get you started
@@DominikObermaier ahhh I see. So if proper security is in place there's no chance for a hacker to subscribe to all topics on a broker by using a wildcard. Does HiveMQ have any information on provisioning/updating certificates and keys for IoT devices? This is an important topic I haven't seen too much information about, amazon has good resources on how they approach this problem (docs.aws.amazon.com/iot/latest/developerguide/iot-provision.html), but I would love to see HiveMQ's approach. From what I understand, devices & brokers pub/sub to a secure topic with an existing TLS connection that will return updated keys & certs. Thanks again for the videos you and your team make, they are helpful and demonstrate HiveMQ as a leader in this field.
also, are there any useful added benefits to using a VPN server on an IoT gateway device -- assuming proper baseline security measures are taken like the ones mentioned in the HiveMQ security blog series.
@@michaels8297 A VPN itself doesn't bring any advantage in MQTT scenarios MQTT is secure over the public Internet if you're using TLS. The benefits of VPNs, which is the "private network" between device and server is not necessary as it just adds overhead and actually with MQTT you want to make sure that the devices itself are not addressible as devices open network connections exclusively themselves (and is never server initiated).
@@michaels8297 If you want to use standards based MQTT, i would strongly recommend to use a full MQTT implementation. Neither AWS nor Azure support standards compliant MQTT and you get factually locked into their services on the device side. Provisioning key and certs is something that usually isn't done over MQTT itself. For device credentials, OAuth 2.0 is popular. HiveMQ e.g. supports JWT with offline validation as well as live introspection on the Auth server (besides a lot of other mechanisms). This is usually highly use case and industry specific, but I am a strong believer in flexibility and a strict "no magic" approach. btw, feel free to reach out to me directly if you want to have a deeper conversation about the tech aspects, I love to chat about that.
![CAMPปลิ้น | EP.82[1/2] แก๊ง 3 สาวเพื่อนซี้บุก CAMPปลิ้นครั้งนี้ห้ามเสียอาการ](http://i.ytimg.com/vi/_6WUjXHe1TM/mqdefault.jpg)
We put everything you need to know about MQTT and MQTT 5, the basic concepts, features and facts, into one comprehensive E-Book. You may download it here bit.ly/3XsgQK5
Heyyyyyy.......cant wait...cant wait.... for more ...quite simple explanation
More to come soon :)
Great series, thanks. At 3:54, you say 'never use a leading slash'. You had a leading slash in your example in video #4 (/hans/will). Not sure whether that's a typo or whether wills are different? See th-cam.com/video/vVJk5rES5vY/w-d-xo.html
so, how would I go about viewing the topic levels say, under msh/US/.
Did a # wildcard can be use in the middle of a topic name?
For exemple:
a/b/#/z
so it would match with:
a/b/z
a/b/c/z
a/b/c/d/e/z
No, you can't use a # wildcard in the middle, it must only be at the end. A + wildcard (which matches a single topic level) is allowed, though
Thank you, this really helped me out.
Glad it helped!
Mqtt topics are in simple string??
Thank you for reaching out! Could you please submit your question to community.hivemq.com? One of our team members will be able to help you out there.
So in production it is recommended to not allow wildcards?
It's absolutely recommended to use wildcards! Wildcards are one of the essential MQTT features and are used in virtually all deployments I know of. Be sure to use proper permissions in your production system, though. If you're not sure how to there is the MQTT Security Essentials series on the HiveMQ blog that can get you started
@@DominikObermaier ahhh I see. So if proper security is in place there's no chance for a hacker to subscribe to all topics on a broker by using a wildcard. Does HiveMQ have any information on provisioning/updating certificates and keys for IoT devices? This is an important topic I haven't seen too much information about, amazon has good resources on how they approach this problem (docs.aws.amazon.com/iot/latest/developerguide/iot-provision.html), but I would love to see HiveMQ's approach. From what I understand, devices & brokers pub/sub to a secure topic with an existing TLS connection that will return updated keys & certs. Thanks again for the videos you and your team make, they are helpful and demonstrate HiveMQ as a leader in this field.
also, are there any useful added benefits to using a VPN server on an IoT gateway device -- assuming proper baseline security measures are taken like the ones mentioned in the HiveMQ security blog series.
@@michaels8297 A VPN itself doesn't bring any advantage in MQTT scenarios MQTT is secure over the public Internet if you're using TLS. The benefits of VPNs, which is the "private network" between device and server is not necessary as it just adds overhead and actually with MQTT you want to make sure that the devices itself are not addressible as devices open network connections exclusively themselves (and is never server initiated).
@@michaels8297 If you want to use standards based MQTT, i would strongly recommend to use a full MQTT implementation. Neither AWS nor Azure support standards compliant MQTT and you get factually locked into their services on the device side. Provisioning key and certs is something that usually isn't done over MQTT itself. For device credentials, OAuth 2.0 is popular. HiveMQ e.g. supports JWT with offline validation as well as live introspection on the Auth server (besides a lot of other mechanisms). This is usually highly use case and industry specific, but I am a strong believer in flexibility and a strict "no magic" approach. btw, feel free to reach out to me directly if you want to have a deeper conversation about the tech aspects, I love to chat about that.