People seem to be missing that FTP and MQTT are generally insecure protocols. I think FTP is probably the bigger issue than MQTT. This kind of stuff is common in home IOT networks but would never pass security audit on a corporate network.
Bambu is growing up, serving more corporations beyond the hobby community, and probably has been asked to beef their security up to make it easier to deploy their printers securely.
Moving to Mutual TLS via a controlled client like Bambu Connect is a pretty industry standard approach to secure, authenticated communication that doesn't require an internet connection, it is done with digital signatures offline.... and thus it can be done over a LAN. It's how many web APIs inside a corporate network are secured. It's how web browsers are secured. Microsoft, Mozilla, Google, Apple, etc. all send you revised certs/keys regularly in your OS or browser patches. Client authentication via x.509 cert signature or subject verification isn't super common on the public web but it does happen a lot with mobile apps or thick client apps, or some websites, e.g. SAP's many websites often use it to verify you're a customer.
- You can't print from Office you need to export to a PDF
- Then use our SecurePrintTM application to send your PDF to the printer. It uses a hard coded mTLS key to talk to our cloud so it's super safe.
- Also SecurePrintTM sends all your PDFs through our servers where we could read them because we control all the keys. We promise we won't though. Don't worry, they are mTLS encrypted on the way to our cloud!
I do understand your point - the current implementation of LAN mode would not be suitable for enabling on a network with very high security requirements. I just don't understand how Bambu think this improves things.
Why not add user controlled OAuth/mTLS to the X1E? Hell, make it additional paid extra. Right now, it seems like their new approach is worse for everyone.
The way things are going, I doubt that 3D printers with always-on requirements and without hardware kill switches for phone-home connectivity are going to be very interesting to any corporations interested in keeping business secrets or staying compliant with data privacy regulations.
It's much more likely that Bambu is doing these moves to control their hobbyist userbase more tightly and make things easier for them, as they've seen other consumer electronics companies get away with similar moves.
It's a risky game however - this is going to land them on ban lists for West-based gov or edu installations even faster than DJI.
Moving to mTLS authentication is going to get Bambu on a ban list? That's incredibly hyperbolic.
Though, if you're right, between the Huwaei ban, DJI ban and the TikTok ban, it's becoming clearer the U.S. no longer really believes in a free market if it doesn't own the market. There may be legitimate reasons to enact a ban, but it sure looks convenient that they're banning all the tech that is that is clearly superior to U.S-owned alternatives.
That... doesn't make things particularly secure. First of all MQTT doesn't require authentication. Secondly FTP is involved which is generally deprecated on most sensible servers and networks. Finally, sending passwords in the clear over an encrypted wire to an end device has been an obsolete technique for over 20 years. People still do it, but they shouldn't. It's the reason we have Kerberos, OAuth2/OIDC, and x509 client authentication with Mutual TLS.
If MQTT is fundamentally insecure, someone needs to inform the AWS IoT and Azure IoT teams.
While they are at it, they need to change their user admin consoles to only allow access via mTLS rather than sending "plain text" passwords over HTTPS as part of their OAuth 2.0 logins.
Yes, hyperbole, but there are many threat models and mTLS isn't some magic panacea, there are tough issues around key deployment and management which Bambu obviously haven't thought through.
Just like HTTP, there will always be someone who manages to misconfigure or turn off all the security. That doesn't make the protocol bad or irrelevant.
The majority of deployed MTLS certificates I've seen in the wild are used in IoT contexts to auth against MQTT servers because of the many advantages MQTT has over HTTPS for that use case.
I didn't say "inherently" or "fundamentally" insecure in my post. I said "generally". Generally, it's hard to deploy MQTT in a secure way, as it has many options that are insecure. In particular, you'll want to use mTLS, which itself is tricky to deploy due to the need for client cert verification. MQTT without mTLS is also prone to DDOS with less widely known techniques for mitigation than HTTPS.
The public HTTP web generally doesn't need client authentication, most just want server authentication, and thus it's a bit easier to deploy and use 3rd party services to mitigate DDOS attacks.
Nah, you made an absolute statement that MQTT was insecure, that was demonstrated to be incorrect. If HTTP can be made secure by relying on a secure transport, then MQTT can as well.
Additionally, MQTT does allow for authentication. I've personally set up brokers many times that will not allow anonymous connections.
Misconfiguration of services, does not constitute an error in the protocol itself.
I clearly don't understand what kind of security are we talking about in this particular case of using a 3D printer. A protection from what – someone comes to my home, connects to my wifi with my password, and then – prints a huge cube to waste all my filaments? Where's the real threat here?
Comments
People seem to be missing that FTP and MQTT are generally insecure protocols. I think FTP is probably the bigger issue than MQTT. This kind of stuff is common in home IOT networks but would never pass security audit on a corporate network.
Bambu is growing up, serving more corporations beyond the hobby community, and probably has been asked to beef their security up to make it easier to deploy their printers securely.
Moving to Mutual TLS via a controlled client like Bambu Connect is a pretty industry standard approach to secure, authenticated communication that doesn't require an internet connection, it is done with digital signatures offline.... and thus it can be done over a LAN. It's how many web APIs inside a corporate network are secured. It's how web browsers are secured. Microsoft, Mozilla, Google, Apple, etc. all send you revised certs/keys regularly in your OS or browser patches. Client authentication via x.509 cert signature or subject verification isn't super common on the public web but it does happen a lot with mobile apps or thick client apps, or some websites, e.g. SAP's many websites often use it to verify you're a customer.
- Hey here is our new laser printer
- You can't print from Office you need to export to a PDF
- Then use our SecurePrintTM application to send your PDF to the printer. It uses a hard coded mTLS key to talk to our cloud so it's super safe.
- Also SecurePrintTM sends all your PDFs through our servers where we could read them because we control all the keys. We promise we won't though. Don't worry, they are mTLS encrypted on the way to our cloud!
I do understand your point - the current implementation of LAN mode would not be suitable for enabling on a network with very high security requirements. I just don't understand how Bambu think this improves things.
Why not add user controlled OAuth/mTLS to the X1E? Hell, make it additional paid extra. Right now, it seems like their new approach is worse for everyone.
The way things are going, I doubt that 3D printers with always-on requirements and without hardware kill switches for phone-home connectivity are going to be very interesting to any corporations interested in keeping business secrets or staying compliant with data privacy regulations.
It's much more likely that Bambu is doing these moves to control their hobbyist userbase more tightly and make things easier for them, as they've seen other consumer electronics companies get away with similar moves.
It's a risky game however - this is going to land them on ban lists for West-based gov or edu installations even faster than DJI.
Moving to mTLS authentication is going to get Bambu on a ban list? That's incredibly hyperbolic.
Though, if you're right, between the Huwaei ban, DJI ban and the TikTok ban, it's becoming clearer the U.S. no longer really believes in a free market if it doesn't own the market. There may be legitimate reasons to enact a ban, but it sure looks convenient that they're banning all the tech that is that is clearly superior to U.S-owned alternatives.
MQTT is not inherently insecure. Much like HTTP, there is a encrypted version that runs on port 8883.
That... doesn't make things particularly secure. First of all MQTT doesn't require authentication. Secondly FTP is involved which is generally deprecated on most sensible servers and networks. Finally, sending passwords in the clear over an encrypted wire to an end device has been an obsolete technique for over 20 years. People still do it, but they shouldn't. It's the reason we have Kerberos, OAuth2/OIDC, and x509 client authentication with Mutual TLS.
If MQTT is fundamentally insecure, someone needs to inform the AWS IoT and Azure IoT teams.
While they are at it, they need to change their user admin consoles to only allow access via mTLS rather than sending "plain text" passwords over HTTPS as part of their OAuth 2.0 logins.
Yes, hyperbole, but there are many threat models and mTLS isn't some magic panacea, there are tough issues around key deployment and management which Bambu obviously haven't thought through.
https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.h...
Just like HTTP, there will always be someone who manages to misconfigure or turn off all the security. That doesn't make the protocol bad or irrelevant.
The majority of deployed MTLS certificates I've seen in the wild are used in IoT contexts to auth against MQTT servers because of the many advantages MQTT has over HTTPS for that use case.
I didn't say "inherently" or "fundamentally" insecure in my post. I said "generally". Generally, it's hard to deploy MQTT in a secure way, as it has many options that are insecure. In particular, you'll want to use mTLS, which itself is tricky to deploy due to the need for client cert verification. MQTT without mTLS is also prone to DDOS with less widely known techniques for mitigation than HTTPS.
The public HTTP web generally doesn't need client authentication, most just want server authentication, and thus it's a bit easier to deploy and use 3rd party services to mitigate DDOS attacks.
Nah, you made an absolute statement that MQTT was insecure, that was demonstrated to be incorrect. If HTTP can be made secure by relying on a secure transport, then MQTT can as well.
Additionally, MQTT does allow for authentication. I've personally set up brokers many times that will not allow anonymous connections.
Misconfiguration of services, does not constitute an error in the protocol itself.
OK, please continue deploying MQTT ports on the public internet. I'm sure it's super common and completely safe.
Neither Bambu nor the parent poster did this. I'm not sure what you're talking about.
I clearly don't understand what kind of security are we talking about in this particular case of using a 3D printer. A protection from what – someone comes to my home, connects to my wifi with my password, and then – prints a huge cube to waste all my filaments? Where's the real threat here?
Of course not. Just the one(s) currently loaded in the printer. They can't pull a filament out of the cupboard and load it via MQTT.