Bambu Lab - Setting the Record Straight About Our Security Update
91 comments
·January 20, 2025parasubvert
blutack
- 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.
sho_hn
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.
parasubvert
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.
Maskawanian
MQTT is not inherently insecure. Much like HTTP, there is a encrypted version that runs on port 8883.
parasubvert
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.
blutack
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.
Maskawanian
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.
scblock
The list of fake concerns they list are not the real and very valid concerns I have seen. This addresses nothing.
the_mitsuhiko
> 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.
vvanders
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.
the_mitsuhiko
That is obviously correct, but this is a meaningful improvement over what their initial plan was.
TechIsCool
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...
sho_hn
Why should I switch to "developer mode" to talk to a computer I own on my own network?
parasubvert
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.
progbits
But when you buy the printer you still need to give it internet access / connect via their app, right?
BeefWellington
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.
the_mitsuhiko
I'm not sure why you would need to give it internet access. I think even the firmware updates work via SD card.
fearoffish
Would you be able to elaborate on the ones you’ve seen?
iLoveOncall
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?
geerlingguy
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
ipv6ipv4
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.
wildzzz
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.
rpearl
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.
Jzush
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.
sitkack
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
VogonPoetry
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?
blutack
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.
parasubvert
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.
blutack
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.
parasubvert
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.
iLoveOncall
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.
nullc
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.
LeFantome
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.
ChrisArchitect
Related:
BambuLab new firmware to cut access to third-party API and tools
TechIsCool
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.
vvanders
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.
axegon_
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.
reimertz
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.
locusm
Have you taken a look at the Prusa Core One?
sarchertech
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.
igor47
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?
sho_hn
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.
parasubvert
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.
aweiland
Prusa
KMnO4
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).
the_mitsuhiko
Prusa Core One exists.
pmichaud
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.
Hizonner
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?
karunamurti
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.
hn8726
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?
ClassyJacket
The threat of Bambu not being able to remotely brick your printer in 5 years when they want to sell you a new one
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.