Bambu Lab - Setting the Record Straight About Our Security Update(blog.bambulab.com)
blog.bambulab.com
Bambu Lab - Setting the Record Straight About Our Security Update
https://blog.bambulab.com/updates-and-third-party-integration-with-bambu-connect/
119 comments
- 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.
- 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.
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.
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.
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.
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.
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?
[deleted]
> prints a huge cube to waste all my filaments?
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.
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.
The list of fake concerns they list are not the real and very valid concerns I have seen. This addresses nothing.
> This addresses nothing.
This does in-fact address quite a bit, because they have change their stance with this update. Previously even LAN only mode required to go via their bambu connect system, now you can switch it to developer mode and talk freely via MQTT to the printer.
This does in-fact address quite a bit, because they have change their stance with this update. Previously even LAN only mode required to go via their bambu connect system, now you can switch it to developer mode and talk freely via MQTT to the printer.
You could already talk freely to the MQTT on the printer and it was already secured with a unique password. This feels like making it a second class feature that could disappear at a future point.
That is obviously correct, but this is a meaningful improvement over what their initial plan was.
That doesn't seem obvious to me. It's not unthinkable their plan is:
- Want to introduce x, but we are worried what our userbase thinks.
- Introduce something way more ridiculous y that subsumes x.
- Rollback y but not x because of backlash.
Now they look like a company that listens to their users and they got what they wanted.
- Want to introduce x, but we are worried what our userbase thinks.
- Introduce something way more ridiculous y that subsumes x.
- Rollback y but not x because of backlash.
Now they look like a company that listens to their users and they got what they wanted.
They’ve suffered real brand damage. Any of the changes (original, or these) seem like they would win over unconvinced potential customers, yet they’ve actively turned some away.
Ah the classic door in the face technique
https://en.wikipedia.org/wiki/Door-in-the-face_technique
https://en.wikipedia.org/wiki/Door-in-the-face_technique
I don't really see what having a "developer mode" offers here beyond the existing solution. The current mqtt is already locked down with a unique password and AFAIK the endpoint was read-only anyway.
Don't get me wrong I'm glad they're responding to feedback but the feedback shouldn't have been required in the first place.
I'm all for better security on products(esp ones that heat up to 300C!) but interoperability with open standards makes it a better product overall and given the direction we've seen in the IoT space I think they've done quite a bit of damage(even if not intentionally) by not taking more care in this area.
Don't get me wrong I'm glad they're responding to feedback but the feedback shouldn't have been required in the first place.
I'm all for better security on products(esp ones that heat up to 300C!) but interoperability with open standards makes it a better product overall and given the direction we've seen in the IoT space I think they've done quite a bit of damage(even if not intentionally) by not taking more care in this area.
Developer mode is just "how it works today" mode. It's insecure, and uses private APIs, and thus shouldn't be used, but people will anyway, so they're listening to their customers.
> Developer mode is just "how it works today" mode.
For LAN mode yes, but for how the printer works — not exactly. Right now you can print from a 3rd party slicer (Orca Slicer) and at the same time use Bambu Handy mobile app to for example monitor the print. LAN mode disables the cloud connection (always has). Which means that with the revised changes you have to choose either a 3rd party slicer _or_ active cloud connection
For LAN mode yes, but for how the printer works — not exactly. Right now you can print from a 3rd party slicer (Orca Slicer) and at the same time use Bambu Handy mobile app to for example monitor the print. LAN mode disables the cloud connection (always has). Which means that with the revised changes you have to choose either a 3rd party slicer _or_ active cloud connection
Hmm, seems pretty clear that OrcaSlicer will eventually adapt to use Bambu Connect regardless, which will preserve active cloud connections.
Adapting to Bambu Connect means passing the print files to another app, and it's unclear if that app will work without a cloud account. Plus Orca does lose functionality like controlling the printer directly from the slicer, and one of the critiques of the new system is needing a separate app in the first place.
If you mean that OrcaSlicer will reimplement Bambu Connect protocols inside — I doubt that will happen, since Bambu Connect is not open source, so this would involve reverse engineering the protocols and potentially including Bambu Connect certificates.
If you mean that OrcaSlicer will reimplement Bambu Connect protocols inside — I doubt that will happen, since Bambu Connect is not open source, so this would involve reverse engineering the protocols and potentially including Bambu Connect certificates.
Didn't we hear this tune from Sony in the Playstation 3 days with Developer mode and then it slowly faded away after a couple years of application/product releases...
Why should I switch to "developer mode" to talk to a computer I own on my own network?
You don't need to. You can use their Bambu Connect client in LAN mode.
Or you can turn off security and use "developer mode", aka. "how things work today" mode, if you want to do things the old / insecure way.
Or you can turn off security and use "developer mode", aka. "how things work today" mode, if you want to do things the old / insecure way.
But when you buy the printer you still need to give it internet access / connect via their app, right?
You do not need to give it internet access for LAN mode to function, but you lose a LOT of features that the cloud app and mobile app give you. For example, you can no longer do anything with the camera in LAN mode, even from the official Bambu Studio app. So no timelapses or ability to check in on it from even just elsewhere in my house.
There's also other limitations of it in features I don't really use, for example IIRC the RFID stuff they do with their print spools stops working.
There's also other limitations of it in features I don't really use, for example IIRC the RFID stuff they do with their print spools stops working.
I'm not sure why you would need to give it internet access. I think even the firmware updates work via SD card.
They just introduced firmware updates via SD card in the most recent released version, prior to that you had to put the printer online and associate it with an account to get firmware updates.
But yes today there is no need to use their cloud services unless you want to control the printer with their phone app. And the printer works totally fine completely isolated from the internet.
The now aborted proposed update would have required using a binary shim from bambu with an embedded 1 year lifetime SSL cert to speak the the printer at all, even when in lan mode.
But yes today there is no need to use their cloud services unless you want to control the printer with their phone app. And the printer works totally fine completely isolated from the internet.
The now aborted proposed update would have required using a binary shim from bambu with an embedded 1 year lifetime SSL cert to speak the the printer at all, even when in lan mode.
Bambu Companion (unfortunately iPhone only) does more than Handy and works on LAN. Using it today in fact! https://www.youtube.com/watch?v=LZpDQN9zgUI
Would you be able to elaborate on the ones you’ve seen?
These companies always pick the most ridiculous tinfoil hat bullshit list of complaints to debunk when trying to explain why they want to close off their API. The real reason almost always comes down to money. The mention of Panda Touch is very telling. While I'm sure Bambu doesn't want to maintain documentation for a non-public (is that the right term)? API, they definitely don't want other companies making money off their ecosystem.
who cares if Panda Touch/BigTreeTech was making money off the ecosystem? it did nothing more than sell more bambu printers. It's not net-zero--money for BigTreeTech is not coming out of Bambu's pockets; I seriously doubt it was net-negative for Bambu.
Because the writing on the wall is that this was always meant to be a subscription based, continual revenue stream for Bamboo Labs. They are just edging that direction.
Whether or not it’s simply greed or that they didn’t make as much selling the printers as they had thought. The next step to closing an API and killing 3rd party interactions is almost always so they can introduce some form of continuous monetization scheme.
That was always something that rubbed me the wrong way with Bamboo Labs. They threw an absolutely obscene amount of money at influencers. Essentially buying a ringing endorsement from nearly the whole hobbyist community and made their brand a household name.
The time was right to pull the switch.
Whether or not it’s simply greed or that they didn’t make as much selling the printers as they had thought. The next step to closing an API and killing 3rd party interactions is almost always so they can introduce some form of continuous monetization scheme.
That was always something that rubbed me the wrong way with Bamboo Labs. They threw an absolutely obscene amount of money at influencers. Essentially buying a ringing endorsement from nearly the whole hobbyist community and made their brand a household name.
The time was right to pull the switch.
Having 2nd and 3rd party support only make an ecosystem more robust.
This whole kerfuffle only sours me to them. I like the printer but the desktop software quality is low and features in LAN mode are not available for what one can only think of as a shity move to Hoover up data for the enshitification
This whole kerfuffle only sours me to them. I like the printer but the desktop software quality is low and features in LAN mode are not available for what one can only think of as a shity move to Hoover up data for the enshitification
What if this is not about closing off an API. Maintaining a stable API is difficult - especially if mistakes were made in earlier designs (no versioning, bad abstraction, wrong protocol...) and there is a plan to fix things in the future.
Only the maintainer of an API knows what the future plans are. Not making future plans public is the way to avoid Osbourne incidents and to actually deliver real things, not just vacuous promises.
From my dabbling with MQTT, Tasmota and home built sensors; MQTT has no versioning and limited hierarchy in the pub / sub model. I'm not surprised Bambu didn't want a 3rd Party product to "integrate" with it. (Disclaimer, I don't know what it is used for, I don't have the products)
In my experience, if you need to fix something that has an undesigned API or needs interfaces or communications methods to change, what you do is build a "New Interface" with what you want and temporarily bridge it to the old one. The desired plan is, once everyone moves to the new interface, the old things can be sunset.
Sadly, this is the utopian view. From what I've seen, 3rd Parties often give the middle finger and just keep using the old stuff. The 3rd parties or customers then complain bitterly when the "New Interface" only comes out - the "blame", rightly or wrongly, is usually directed at the software update. Shouldn't 3rd Parties also be held to account and have a duty to maintain their integrations?
Building, supporting and evolving products is challenging - I've rarely see people put the right structure in place for v2.0, v3.0 when frantically working to get v1.0 out. Mistakes will be made and they are very, very expensive to fix (reputation, engineering time, QA) in the future.
From the statement made, I await a response from Panda Touch - will they commit to fixing their product and inform their customers?
Only the maintainer of an API knows what the future plans are. Not making future plans public is the way to avoid Osbourne incidents and to actually deliver real things, not just vacuous promises.
From my dabbling with MQTT, Tasmota and home built sensors; MQTT has no versioning and limited hierarchy in the pub / sub model. I'm not surprised Bambu didn't want a 3rd Party product to "integrate" with it. (Disclaimer, I don't know what it is used for, I don't have the products)
In my experience, if you need to fix something that has an undesigned API or needs interfaces or communications methods to change, what you do is build a "New Interface" with what you want and temporarily bridge it to the old one. The desired plan is, once everyone moves to the new interface, the old things can be sunset.
Sadly, this is the utopian view. From what I've seen, 3rd Parties often give the middle finger and just keep using the old stuff. The 3rd parties or customers then complain bitterly when the "New Interface" only comes out - the "blame", rightly or wrongly, is usually directed at the software update. Shouldn't 3rd Parties also be held to account and have a duty to maintain their integrations?
Building, supporting and evolving products is challenging - I've rarely see people put the right structure in place for v2.0, v3.0 when frantically working to get v1.0 out. Mistakes will be made and they are very, very expensive to fix (reputation, engineering time, QA) in the future.
From the statement made, I await a response from Panda Touch - will they commit to fixing their product and inform their customers?
> What if this is not about closing off an API. Maintaining a stable API is difficult
That's why any sane software uses a stable public API and an internal one that can be closed off or has breaking changes all the time.
> MQTT has no versioning and limited hierarchy in the pub / sub model
It's currently handled like this: https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md. Would it be a far stretch to add an "api_version":x field and a "internal_" prefix for some commands?
That's why any sane software uses a stable public API and an internal one that can be closed off or has breaking changes all the time.
> MQTT has no versioning and limited hierarchy in the pub / sub model
It's currently handled like this: https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md. Would it be a far stretch to add an "api_version":x field and a "internal_" prefix for some commands?
The main concern that was raised was that you couldn't send print jobs from other slicers anymore, and this article explains why this isn't the case in the section titled "How Bambu Connect Works", taking OrcaSlicer as an example.
How does it not address the concerns of people?
How does it not address the concerns of people?
Judging by the PR thread in OrcaSlicer's GitHub repo, not all users are happy with the proposed fix, requiring users to install Bambu Connect on their computers (which currently doesn't run on Linux, IIRC?) to be able to use the new OrcaSlicer to Bambu workflow... https://github.com/SoftFever/OrcaSlicer/pull/8103
Tellingly, this pull request is coming from a Bambu Lab employee. I think the OrcaSlicer maintainers should tell Bambu Lab to pound sand with this change.
> I think the OrcaSlicer maintainers should tell Bambu Lab to pound sand with this change.
Hum, the alternative is OrcaSlicer stops working with Bambu printers...
Hum, the alternative is OrcaSlicer stops working with Bambu printers...
OrcaSlicer is a fork of Bambu's slicer. It defeats the whole impetus of the project to not support Bambu Lab printers.
Orca is used for a number of other printers too — and don't forget Bambu Slicer is a fork of Prusa Slicer is a fork of Slic3r... it's open source forks all the way down that rabbit hole!
You mean Bambu Lab broke compatibility with OrcaSlicer and every other slicer out there.
I don't know if the OrcaSlicer maintainers feel this way. But if they feel that Bambu Lab is stabbing them in the back, they don't have to jump when Bambu Lab tells them to (that's pretty much the raison d'être of open source).
I don't know if the OrcaSlicer maintainers feel this way. But if they feel that Bambu Lab is stabbing them in the back, they don't have to jump when Bambu Lab tells them to (that's pretty much the raison d'être of open source).
I'm guessing most of OrcaSlicer's users are using bambu printers and if they upgrade to the firmware that requires bambu connect it's quite likely that the OrcaSlicer maintainers will have some interest in keeping the slicer working.
The alternative is that users have to manually use bambu connect and that seems inferior to what the PR enables.
The alternative is that users have to manually use bambu connect and that seems inferior to what the PR enables.
> I'm guessing most of OrcaSlicer's users are using bambu printers and if they upgrade to the firmware that requires bambu connect it's quite likely that the OrcaSlicer maintainers will have some interest in keeping the slicer working.
Yes. That's where the maintainers need to decide if they are Bambu Lab's lackeys or if they have a say in their beloved project. Part of that is thinking about at what point the project becomes pointless as a meaningful BambuSlicer alternative.
> The alternative is that users have to manually use bambu connect and that seems inferior to what the PR enables.
Everything is going to be inferior to using BambuSlicer. That is Bambu's real intent.
The OrcaSlicer maintainers probably have the most leverage (what little there may be) on Bambu Lab. I think that is why Bambu Lab is keen to offer the PR on GitHub. The maintainers should exercise whatever leverage they have while they still can.
Yes. That's where the maintainers need to decide if they are Bambu Lab's lackeys or if they have a say in their beloved project. Part of that is thinking about at what point the project becomes pointless as a meaningful BambuSlicer alternative.
> The alternative is that users have to manually use bambu connect and that seems inferior to what the PR enables.
Everything is going to be inferior to using BambuSlicer. That is Bambu's real intent.
The OrcaSlicer maintainers probably have the most leverage (what little there may be) on Bambu Lab. I think that is why Bambu Lab is keen to offer the PR on GitHub. The maintainers should exercise whatever leverage they have while they still can.
> Yes. That's where the maintainers need to decide if they are Bambu Lab's lackeys or if they have a say in their beloved project.
I understand your anger, but I don't think that properly describes the situation. As a maintainer of an open source project your users are who you are about. If your users want support for bambu connect, then you are likely to implement it. Whatever Bambu does is whatever Bambu does, you need to accept it.
> Part of that is thinking about at what point the project becomes pointless as a meaningful BambuSlicer alternative.
Why would OrcaSlicer become pointless if it supports Bambu Connect? It also supports the Bambu network plugin.
> Everything is going to be inferior to using BambuSlicer. That is Bambu's real intent.
What would Bambu's motivation be to do that? I don't think they would have built Bambu Connect if the goal is not to support third party slicers to directly send things to the printer. Note that most 3d printers on the market didn't or still don't have integration into slicers.
I understand your anger, but I don't think that properly describes the situation. As a maintainer of an open source project your users are who you are about. If your users want support for bambu connect, then you are likely to implement it. Whatever Bambu does is whatever Bambu does, you need to accept it.
> Part of that is thinking about at what point the project becomes pointless as a meaningful BambuSlicer alternative.
Why would OrcaSlicer become pointless if it supports Bambu Connect? It also supports the Bambu network plugin.
> Everything is going to be inferior to using BambuSlicer. That is Bambu's real intent.
What would Bambu's motivation be to do that? I don't think they would have built Bambu Connect if the goal is not to support third party slicers to directly send things to the printer. Note that most 3d printers on the market didn't or still don't have integration into slicers.
I generally agree with your view on OrcaSlicer. I think we have a difference on what is better for the users and the project itself. I think it is better for the users if the maintainers take a stand against Bambu's dictat.
> Whatever Bambu does is whatever Bambu does, you need to accept it.
And maybe it is time to take your ball and go home.
> What would Bambu's motivation be to do that?
What is Bambu's motivation for being cloud first when it is not technically necessary? Why can't OrcaSlicer be a first class citizen like BambuSlicer? Instead it has to go through Bambu Connect which is inherently clunky and less featureful. It's simple. Control, and vendor lock-in. Possibly, Bambu sees this as a way to curtail print farm automation software from other vendors.
> Whatever Bambu does is whatever Bambu does, you need to accept it.
And maybe it is time to take your ball and go home.
> What would Bambu's motivation be to do that?
What is Bambu's motivation for being cloud first when it is not technically necessary? Why can't OrcaSlicer be a first class citizen like BambuSlicer? Instead it has to go through Bambu Connect which is inherently clunky and less featureful. It's simple. Control, and vendor lock-in. Possibly, Bambu sees this as a way to curtail print farm automation software from other vendors.
> But if they feel that Bambu Lab is stabbing them in the back, they don't have to jump when Bambu Lab tells them to (that's pretty much the raison d'être of open source).
The raison d'être of Orca Slicer is to slice files for 3D printers. They don't manufacture printers. They have no raison d'être if they don't support one of the major players in the 3D printing space.
The raison d'être of Orca Slicer is to slice files for 3D printers. They don't manufacture printers. They have no raison d'être if they don't support one of the major players in the 3D printing space.
OrcaSlicer is sponsored by Qidi and BigTree Tech. If anything, Bambu Lab is taking them for a ride, like it is taking the rest of the open source community for a ride.
It's clear you like your Bambu Lab printer/s. But I think you are letting it cloud your judgement. Bambu Lab is being predatory here.
It's clear you like your Bambu Lab printer/s. But I think you are letting it cloud your judgement. Bambu Lab is being predatory here.
Bambu Lab isn't being predatory. They're making a sensible change to their security.
But, because people don't understand security technology tradeoffs, everything becomes a conspiracy.
But, because people don't understand security technology tradeoffs, everything becomes a conspiracy.
If this were about security, it wouldn't matter what piece of software was implementing the well documented security protocol. BambuSlicer, or OrcaSlicer, it would be all the same because the underlying protocol would be the security guarantee. This is rudimentary security tradecraft.
Bambu Lab is introducing something else. Most charitably, it could be described as security through obscurity, which is never secure. More realistically, Bambu Lab is introducing vendor lock-in under the pretext of security. Vendor lock-in is what this change actually achieves.
Bambu Lab is introducing something else. Most charitably, it could be described as security through obscurity, which is never secure. More realistically, Bambu Lab is introducing vendor lock-in under the pretext of security. Vendor lock-in is what this change actually achieves.
Controlling the software lifecycle of a client library or executable, to be able to update its x509 certs as part of an upgrade cycle, is ... not security through obscurity. It's pretty standard practice, especially if your customer base knows very little about maintianing certs/keys.
It's about a vendor trying to control an experience for its users balancing its UX and maintenance costs.
There's no real vendor lock-in here beyond the usual conspiracy "Bambu Lab is better therefore they're evil unless they give it all away for free to their competition", that's a pile of nonsense. Orca Slicer and 3rd party slicers will continue to work with the new approach if they can work out the details of the PR that uses Bambu Connect.
It's about a vendor trying to control an experience for its users balancing its UX and maintenance costs.
There's no real vendor lock-in here beyond the usual conspiracy "Bambu Lab is better therefore they're evil unless they give it all away for free to their competition", that's a pile of nonsense. Orca Slicer and 3rd party slicers will continue to work with the new approach if they can work out the details of the PR that uses Bambu Connect.
Somehow you can securely access your bank account with any browser of your choosing, and not a bank provided browser, but 3D printers need obscure proprietary security protocols to be secure. That doesn't make sense.
ppl always get caught up on the x509. They're actually a good thing and are absolutely necessary to prevent mitm since they use self-signed certs.
BambuStudio also works that way.
The issue is introducing further measures which don't provide any security benefit to the user (can be spoofed): only allowing critical commands from BambuConnect.
The issue is introducing further measures which don't provide any security benefit to the user (can be spoofed): only allowing critical commands from BambuConnect.
> Hum, the alternative is OrcaSlicer stops working with Bambu printers...
Which is fine, no? Plenty of other good printers available.
Which is fine, no? Plenty of other good printers available.
Um no? First, Bambu is the best, by far. Secondly, Orca Slicer is a fork of Bambu Studio and the vast majority of its users are Bambu customers that want extra features.
> Bambu is the best, by far.
Nah, this is influencer-generated bro science sentiment. They do nothing special, and hardly never come out on top in any serious independent print quality tests.
Their primary competitive advantage right now the AMS bundle being very competitively priced.
Nah, this is influencer-generated bro science sentiment. They do nothing special, and hardly never come out on top in any serious independent print quality tests.
Their primary competitive advantage right now the AMS bundle being very competitively priced.
Related:
BambuLab new firmware to cut access to third-party API and tools
https://news.ycombinator.com/item?id=42760491
BambuLab new firmware to cut access to third-party API and tools
https://news.ycombinator.com/item?id=42760491
This also?
Reverse Engineering Bambu Connect - https://news.ycombinator.com/item?id=42764602 - Jan 2025 (316 comments)
Reverse Engineering Bambu Connect - https://news.ycombinator.com/item?id=42764602 - Jan 2025 (316 comments)
Does anyone know or can see an actual concrete security concern with the current implementation of LAN mode?
https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md
Right now, the printer's local MQTT server can only be accessed from the local IP using an 8 digit password obtained through through the physical display.
I can't personally see any fundamental issue with this design assuming the implementation is correct, but I'm curious if others can.
https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md
Right now, the printer's local MQTT server can only be accessed from the local IP using an 8 digit password obtained through through the physical display.
I can't personally see any fundamental issue with this design assuming the implementation is correct, but I'm curious if others can.
To me this whole thing feels like they're trying to pass audit to sell Bambu printers to corporations that require secure communications. Mutual TLS with client certs is nearly universal, which is what they're trying to do with Bambu Connect. On the other hand, MQTT isn't a very secure protocol, plus the printer also uses FTP which is mostly banned on corporate networks these days.
I wasn't aware of any specific vulnerabilities in the basic MQTT design (assuming it's over TLS).
I agree that MTLS for embedded m2m/IOT auth against MQTT is pretty standard (see AWS IOT, Azure etc) but do paper printers used in enterprise which have displays typically require MTLS for printing?
Surely any corporation with a security team would VLAN and null route these things anyway - only the enterprise targeted X1E model has an ethernet port, all the others are WiFi only.
I agree that MTLS for embedded m2m/IOT auth against MQTT is pretty standard (see AWS IOT, Azure etc) but do paper printers used in enterprise which have displays typically require MTLS for printing?
Surely any corporation with a security team would VLAN and null route these things anyway - only the enterprise targeted X1E model has an ethernet port, all the others are WiFi only.
I don't think their MQTT was over TLS traditionally (maybe they added this), it used to be that you just sent a message over unauthenticated MQTT and FTP'd your 3MF; the FTP had a password but that also was sent in the clear. https://github.com/darkorb/bambu-ftp-and-print
Most corps these don't want to deal with the hassle of VLANs and black holes for insecure devices.
Most corps these don't want to deal with the hassle of VLANs and black holes for insecure devices.
People have been using MQTT with TLS for years[1][2][3]. Long before the company and line of printers existed. It's not really an excuse to say "well they didn't use it" -- they should have simply offered people the necessary configuration options to enable it.
[1]: https://mosquitto.org/blog/2018/05/version-1-5-released/ [2]: https://forums.raspberrypi.com/viewtopic.php?t=287326 [3]: https://esp32.com/viewtopic.php?t=9747
[1]: https://mosquitto.org/blog/2018/05/version-1-5-released/ [2]: https://forums.raspberrypi.com/viewtopic.php?t=287326 [3]: https://esp32.com/viewtopic.php?t=9747
Everything was sent in plaintext early on.
But since 2022/2023 it's TLS: https://wiki.bambulab.com/en/security-incidents-cloud-traffi...
Look up old results about "BambuLab MQTT" on Google.
They use an online MQTT server instead of the local one for the following functions: initiating printing, heating the nozzle, and heating the heatbed. (see https://www.allaboutbambu.com/2024/06/14/p1p-p1s-new-firmwar...)
On https://forum.bambulab.com/t/bambu-lab-mqtt-limitations/8344... you can see their MQTT server got DDOSed by some faulty 3rd party "client".
I don't think it's so much about security of the users as much as it is about their own.
They use an online MQTT server instead of the local one for the following functions: initiating printing, heating the nozzle, and heating the heatbed. (see https://www.allaboutbambu.com/2024/06/14/p1p-p1s-new-firmwar...)
On https://forum.bambulab.com/t/bambu-lab-mqtt-limitations/8344... you can see their MQTT server got DDOSed by some faulty 3rd party "client".
I don't think it's so much about security of the users as much as it is about their own.
That article is referring to conflicting controls when using their cloud stuff.
In lan mode it doesn't use anything remote and works just fine completely isolated.
> you can see their MQTT server got DDOSed by some faulty 3rd party "client"
Right, when you use 'cloud mode' then bambu controls the printer, and your own control has to go through them.
In lan mode it doesn't use anything remote and works just fine completely isolated.
> you can see their MQTT server got DDOSed by some faulty 3rd party "client"
Right, when you use 'cloud mode' then bambu controls the printer, and your own control has to go through them.
> Right now, the printer's local MQTT server can only be accessed from the local IP using an 8 digit password obtained through through the physical display.
The problem is hackers don't need to play by the rules (accessing the display).
8 digits that never change is a joke in terms of security, it could be brute-forced within hours/days by sending a network request for each possible combination.
mitm: afaik Bambu Studio/Connect/Handy validate the printer's certificate during the TLS handshake, but most third party software probably doesn't (barely found documentation about it).
And there are a few other (although not as fundamental) weaknesses like no mutual authentication, access control or revocation of specific clients. Due to the nature of MQTT, every client can see messages sent by other clients once authenticated.
The problem is hackers don't need to play by the rules (accessing the display).
8 digits that never change is a joke in terms of security, it could be brute-forced within hours/days by sending a network request for each possible combination.
mitm: afaik Bambu Studio/Connect/Handy validate the printer's certificate during the TLS handshake, but most third party software probably doesn't (barely found documentation about it).
And there are a few other (although not as fundamental) weaknesses like no mutual authentication, access control or revocation of specific clients. Due to the nature of MQTT, every client can see messages sent by other clients once authenticated.
Bambu lab printers are truly awesome in terms of what they can do for a very reasonable price. Having said that, I have never upgraded mine nor have I ever connected it to the internet and never will. Nor will I update it. If it takes me 15 minutes to get an ssh client running on an esp8266 that can connect to an
poorly secured server and execute shell commands, there is no way I'm letting a proprietary chinese hardware and software anywhere near my home network. But this is just a side hobby of mine, so I can live with carrying around an SD card. But I can see how something like that can be a major blow to business owners. I am not entirely sure if this blog post is just a response or sneaky backpedaling from bambu labs after the backlash they received over the last few days.
The play here is obviously that they want 3rd party services to use Bambu Connect instead of direct protocol integration. They will make Connect easy and direct too much work. That is what all the Panda talk was about. That way, when Bambu inevitably changes the model ( eg. Subscription ), we will have to pay to get access to the ecosystem. But Bambu will be able to claim that it is not them. We still support developer mode they will say, it is the evil third parties that do not.
We need to make sure that dev mode becomes the de facto default. Don’t fall for connect.
We need to make sure that dev mode becomes the de facto default. Don’t fall for connect.
Meanwhile Jeff Geerling already put a video out on his second channel that he won’t recommend a bambu lab printer anymore although he was happy with his printer. And this update didn’t convince him to change his mind.
“Developer mode” isn’t a solution. You buy hardware and it should work 100% without cloud connectivity. Otherwise it’s not your hardware.
“Developer mode” isn’t a solution. You buy hardware and it should work 100% without cloud connectivity. Otherwise it’s not your hardware.
Absolutely!
Local first, everything that should likely run locally should be enabled.
You can’t use the desktop software to see the contents of the SD card, you have to enable cloud access.
I own two Bambu printers, great hardware, and ok software. No longer recommending them.
Local first, everything that should likely run locally should be enabled.
You can’t use the desktop software to see the contents of the SD card, you have to enable cloud access.
I own two Bambu printers, great hardware, and ok software. No longer recommending them.
There is little I find more hilarious than the "<talking head> has put out a video on their <youtube/tiktok/facebook> that says <thing>" comment reply.
I summarise all these replies in my head as "Influencer I've never heard of influences"
I agree with your re: Developer mode though.
I summarise all these replies in my head as "Influencer I've never heard of influences"
I agree with your re: Developer mode though.
This is not the case though, Jeff Geerling is not a no-name influencer. He actually does stuff, contributes to Fedora and AlmaLinux (IIRC). The most influencer-y stuff would be his playing with funny Raspberry Pi setups, but calling that "influencing" would be uncharitable. That's a hobby.
Yes I'm sure a small subsection of people have heard of him/look up to him for his achievements. I've no doubt he's a smart intelligent person. I'm not having a go at Jeff.
My point was the hilarious cult worship of these people. "X posted a video about Y gasp" when 1 in 10,000 know who X is.
Influencer influences! Film at 11!
My point was the hilarious cult worship of these people. "X posted a video about Y gasp" when 1 in 10,000 know who X is.
Influencer influences! Film at 11!
I use LAN mode for my P1S currently in a shed with a local AP and no internet access and it works fine.
https://www.youtube.com/watch?v=91kfolYkRNM
Says even then you have to use their app and cloud service to set up the printer.
Says even then you have to use their app and cloud service to set up the printer.
It's not true, my P1S+AMS has never touched the Internet and I was able to set it up fine on an isolated wifi network out of the box.
I don't think this is correct. I'm fairly certain you can enable LAN only mode without signing in on the printer.
Yeah, what is the point of developer mode for a device you’re not “allowed” to develop for anyway?
Neither LAN mode nor Developer mode requires cloud connectivity. Keep spreading the FUD though.
I am surprised that the use of a messaging queue through MQTT is considered a misuse of their technology when in reality it appears that the other application just was using an internal API that could change without notice. I also could see how certificate based authentication could be viewed by some as a time based expiration on the firmware.
Yeah that's a huge bummer if so, I've got both a HA automation that shows the printer status without needing to have an app installed and I've got a secondary filtration system that's fully automated which would be a PITA if I had to manage manually.
Totally understand if it's something that could change/break in future updates but the language about it being "exploited" is a bummer, you would think extending/documenting that would actually drive further adoption of the printers by building a more robust ecosystem around them.
Totally understand if it's something that could change/break in future updates but the language about it being "exploited" is a bummer, you would think extending/documenting that would actually drive further adoption of the printers by building a more robust ecosystem around them.
Is there firmware for Bambu printers beyond the X1 that just skips all the stupid stuff this company does (while keeping the good features)? Like most companies, it seems that they shouldn’t be trusted with control over hardware that you own.
This stuff isn’t gonna stop until we regulate it.
I bought a miku baby monitor specifically because they were the only manufacturer that had the feature I wanted that promised to never charge monthly fees to use it.
Well then they went bankrupt and a company bought them, forced an over the air update that disabled every feature that made the thing worth buying (for $399), and sent out a letter demanding monthly payment to reenable the “advanced” features.
Market forces won’t fix this. Recurring revenue is just too tempting. It also doesn’t matter how well intentioned a company is, the moment they go out of business, someone will buy their assets and force monthly fees on their former customers.
I bought a miku baby monitor specifically because they were the only manufacturer that had the feature I wanted that promised to never charge monthly fees to use it.
Well then they went bankrupt and a company bought them, forced an over the air update that disabled every feature that made the thing worth buying (for $399), and sent out a letter demanding monthly payment to reenable the “advanced” features.
Market forces won’t fix this. Recurring revenue is just too tempting. It also doesn’t matter how well intentioned a company is, the moment they go out of business, someone will buy their assets and force monthly fees on their former customers.
This is what Louis Rossmann has been doing, he's even been hiring lobbiests and getting results.
Sad attempt at damage control.
Meanwhile, trust continues to be eroded.
Meanwhile, trust continues to be eroded.
Seems like the maker community, esp. YouTube influencers, uniformly recommend bambu. Curious-- do folks here have other recommendations? Equivalent quality, speed, maybe even price, but more committed to free software?
If you want a more trustworthy review, check out Maker Muse' recent review on current-crop bedslingers. Interestingly, unlike the standard influencer talking points, they came to the conclusion that the Prusa is easiest to set up and operate (while not being negative on Bambu).
I tend to trust Maker Muse because he's over the years repeatedly shown screenshots of emails by compannies trying to bribe, pressure or threaten him, which gave me some faith that he's generally refused these advances.
I tend to trust Maker Muse because he's over the years repeatedly shown screenshots of emails by compannies trying to bribe, pressure or threaten him, which gave me some faith that he's generally refused these advances.
Generally speaking, no. Prusa comes close - they're dedicated to community and OSS, and are quality parts... but are almost 2x the price and tend to be missing comparable features.
The other competition doesn't quite have the UX and quality of Bambu Lab. That's changing slowly, but it's reality today IMO.
The challenge is that the 3d Printing community is maturing from a hobbyist/tinker phase into a consumer phase with Bambu Lab leading the way. Bambu Lab has mostly threaded the needle by balancing proprietary UX with practical ability to tinker, swap parts, etc.
But as with most hobby communities, if someone doesn't understand a motivation of a change, they immediately ascribe it to a conspiracy.
Bambu Lab wanting to improve printer security is an obvious thing to anyone who has dealt with corporate network security in the past... today it is effectively an insecure toy that would only be deployed on black holed lab networks. They're trying to make it more modern via Mutual TLS authenticated file transfer rather than a cobbled together mix of FTP and MQTT.
The other competition doesn't quite have the UX and quality of Bambu Lab. That's changing slowly, but it's reality today IMO.
The challenge is that the 3d Printing community is maturing from a hobbyist/tinker phase into a consumer phase with Bambu Lab leading the way. Bambu Lab has mostly threaded the needle by balancing proprietary UX with practical ability to tinker, swap parts, etc.
But as with most hobby communities, if someone doesn't understand a motivation of a change, they immediately ascribe it to a conspiracy.
Bambu Lab wanting to improve printer security is an obvious thing to anyone who has dealt with corporate network security in the past... today it is effectively an insecure toy that would only be deployed on black holed lab networks. They're trying to make it more modern via Mutual TLS authenticated file transfer rather than a cobbled together mix of FTP and MQTT.
How do normal paper printers work on such networks? From what I gather there is some standardised solution to that, wherein here bambu requires their own "connect" software, correct?
I think that big enterprises are full of old systems that are put on vans, vpns, conditional access rules etc., so it's weird to me that ftp is such a problem?
There is also a point in their tos: 7.4 - boils down to "your printer will block printing until you accept critical security patches" that directly contradicts the linked blog post
I think that big enterprises are full of old systems that are put on vans, vpns, conditional access rules etc., so it's weird to me that ftp is such a problem?
There is also a point in their tos: 7.4 - boils down to "your printer will block printing until you accept critical security patches" that directly contradicts the linked blog post
Normal paper printers concentrate print services to a Windows or Linux print server that authenticates users before they submit a job. All the direct ports on the printer are firewalled and restricted to the print server.
The main issue is that paper printers are a terrible legacy technology that didn't evolve much and are grandfathered into corporate security, whereas any new technology or new vendors have a much higher bar to pass before they're let on networks. Yes, there are many workarounds like VLANs, firewalls and black hole routes etc but they're usually treated as exceptions these days.
The TOS is meant to cover worst case scenarios, such as, the x509 certificates on the printer expire, or a major vulnerability is found. The printer is a hybrid cloud connected or LAN connected service and thus it's reasonable to warn users they need to update periodically because Bambu doesn't want to be exposed by for unpatched backdoor attacks etc. This is a similar issue with MacOS or Windows where you cant use your web browser securely after a few years of missing updates, or other connected devices where you must consent to automatic updates to use the device (Google Nest or Amazon Ring devices come to mind). Bambu is actually being better than most device companies in that they are just requiring this for crucial security updates and they don't require an internet connection: you can patch it via SD Card.
The main issue is that paper printers are a terrible legacy technology that didn't evolve much and are grandfathered into corporate security, whereas any new technology or new vendors have a much higher bar to pass before they're let on networks. Yes, there are many workarounds like VLANs, firewalls and black hole routes etc but they're usually treated as exceptions these days.
The TOS is meant to cover worst case scenarios, such as, the x509 certificates on the printer expire, or a major vulnerability is found. The printer is a hybrid cloud connected or LAN connected service and thus it's reasonable to warn users they need to update periodically because Bambu doesn't want to be exposed by for unpatched backdoor attacks etc. This is a similar issue with MacOS or Windows where you cant use your web browser securely after a few years of missing updates, or other connected devices where you must consent to automatic updates to use the device (Google Nest or Amazon Ring devices come to mind). Bambu is actually being better than most device companies in that they are just requiring this for crucial security updates and they don't require an internet connection: you can patch it via SD Card.
As a Prusa user who never used a Bambu Lab printer, what features am I missing out?
Prusa then
Prusa
Prusa does not have an equivalent printer to the P1S/X1C. Even their Mk4s is twice the price of an A1 and is missing some basic features that come standard on all Bambu Lab printers (such as a camera).
Prusa Core One exists.
It exists, but hasn't started shipping yet. It also is Prusa's step away from open source, so it could end up being just like the BBL.
It’s such clownery to try to lock down a thing you’re trying to sell to a community of tinkerers. The brand damage (the article fighting strawmen does little to reduce it) can’t be worth whatever upside they’re seeing unless they really are positioning themselves to use their unjustified power for profit (which will, of course, result in greater brand damage).
FWIW, I was really interested in the Bambu models until I found out about their shitty corporate behavior.
FWIW, I was really interested in the Bambu models until I found out about their shitty corporate behavior.
We were about to to buy a Bambu Lab printer but then learnt there will be new printers coming out in Q1 so naturally wanted to wait.
I need to educate myself on this a bit more on this issue, but it feels like the rest of the printer industry is just catching up with the X1C (looking at Creality K2 Plus)..
Do I wait for next-gen printers from Bambu Labs which I imagine will be quite revolutionary, or do I buy we buy a Creality K2 Plus, which basically is a X1C.
I need to educate myself on this a bit more on this issue, but it feels like the rest of the printer industry is just catching up with the X1C (looking at Creality K2 Plus)..
Do I wait for next-gen printers from Bambu Labs which I imagine will be quite revolutionary, or do I buy we buy a Creality K2 Plus, which basically is a X1C.
Have you taken a look at the Prusa Core One?
But bigger!
Uh-huh. So exactly what threat or threats is the "security upgrade" meant to address, what alternatives were considered, and where the heck is the "security" in sticking a barely obfuscated private key in a publicly distributed binary?
The security threat is real, they got ddos attempt to their mqtt service last year from 3rd party apps.
The fix is not good though, distributing private key.
I genuinely don't understand how these changes could possibly protect them from ddos though — their cloud APIs are still public, and the Bambu Connect app has to do stuff there as well. What could've changed with the proposed changes?
The threat of Bambu not being able to remotely brick your printer in 5 years when they want to sell you a new one
That diagram they have is unfathomable and the arrows are confusing. It would probably have been best to do a separate LAN mode diagram to explain if there are any cloud dependencies whatsoever.
I'm pretty pissed that they baited and switched me--I bought a bambu printer on holiday sale under the previous terms, and they are now going to change the terms. Feels fraudulent.
[deleted]
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.