Bambu Lab - Setting the Record Straight About Our Security Update
blog.bambulab.com
blog.bambulab.com
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.
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.
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.
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.
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.
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.
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.
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.
- 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.
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.
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
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.
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.
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.
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.
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.
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
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?
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?
How does it not address the concerns of people?
Hum, the alternative is OrcaSlicer stops working with Bambu printers...
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).
The alternative is that users have to manually use bambu connect and that seems inferior to what the PR enables.
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.
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.
> 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.
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.
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.
But, because people don't understand security technology tradeoffs, everything becomes a conspiracy.
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.
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.
Interestingly some banks do use x509 client authentication for corporate accounts or high net worth accounts but they expect you to know how to import the key to your browser. And almost all banking mobile apps use this to call their server APIs to ensure only the Bank's mobile apps (or partners) can call their APIs.
In Bambu Labs' case, they've had many DDOS attacks and other issues with their security and so they're forcing a constraint on the approved software clients that can access their printers and/or cloud service via client authentication. BambuConnect being the catch all proxy software for most.
Bambu is forcing its customers to use its cloud offerings when many users want to use the machine on their LAN without the cloud guff. Many for security reasons. Bambu essentially tells its customers to pound sand, they are forced to use cloud. Now Bambu is claiming it has a cloud DDOS problem and therefore it is going to lock down what users can do further. I'm sorry, that's just silly. Let me connect to the printer locally, and your cloud DDOS problems go away.
The DDOS problem itself doesn't sound particularly compelling as a justification for this action, either. If every user action is authenticated, you know which users are abusing the system - throttle them or kick them out. Adding a TLS certificate for mutual authentication is going to reduce the DDOS overhead by a negligible amount.
> forcing a constraint on the approved software clients
Which will do nothing against a determined DDOSer since they will always be able to extract the certificates from Bambu Connect, or BambuSlicer.
Finally, if the issue is airtight security for the on-prem printer and preventing a hacker external or internal to the LAN from exploiting them. Maybe Bambu can take a page from the Matter smart home specs. if they are out of ideas. These are solved problems. Cloud not necessary. Software lockdown not necessary.
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.
Which is fine, no? Plenty of other good printers available.
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.
BambuLab new firmware to cut access to third-party API and tools
Reverse Engineering Bambu Connect - https://news.ycombinator.com/item?id=42764602 - Jan 2025 (316 comments)
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.
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.
Most corps these don't want to deal with the hassle of VLANs and black holes for insecure devices.
[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
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.
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.
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.
We need to make sure that dev mode becomes the de facto default. Don’t fall for connect.
“Developer mode” isn’t a solution. You buy hardware and it should work 100% without cloud connectivity. Otherwise it’s not your hardware.
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.
I summarise all these replies in my head as "Influencer I've never heard of influences"
I agree with your re: Developer mode though.
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!
Says even then you have to use their app and cloud service to set up the printer.
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.
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.
Meanwhile, trust continues to be eroded.
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.
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.
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
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.
FWIW, I was really interested in the Bambu models until I found out about their shitty corporate behavior.
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.