Hacker News Reader

Comment by c0nsumer | Hacker News Reader

I've been following along with a lot of this, because having picked up one of their printers about a month ago, I was immediately very nonplussed with the security. It took some work to get it running isolated on an IoT VLAN, yet still usable from my main machine.

Thus, on first blush, I welcome security improvements from them, but I'm also anxious to see what they hold.

I do wonder where this is going with the keys, because I've seen a lot of "OH LOOK WE HAVE THE KEYS" but nothing about what the keys are used for or how they are useful. Or if they are even useful.

Hopefully there'll be more interesting news about this soon and some solid, technical info.

View on HN

My understanding is that if I want to print via LAN, I have to auth against Bambu's internet servers, which is most definitely something I don't want.

Actually for my use case this doesn't work at all -- my printers are region locked to China, but I'm not currently in China so I can't connect to those servers -- meaning (I think!) if I upgrade their firmware, I can't print via LAN on my own local network... which just leaves a bad taste in my mouth.

These are great printers, but there's no need for that.

Can you link to some specific detail on that, because I keep seeing that claim, but without any technical info.

I have a P1S which currently can print completely isolated from the internet. Unfortunately (or maybe not?) the new firmware isn't available for my printer, so I can't dig into it myself yet.

But I'd really like to see some sort of "when I try to do X it tries to connect to Y" or "I used to be able to do X, and now Y is required as demonstrated here".

Something more than the current hearsay and pitchforks echo chamber.

From their blog post: https://blog.bambulab.com/firmware-update-introducing-new-au...

"Critical Operations That Require Authorization

The following printer operations will require authorization controls:

    Binding and unbinding the printer.
    Initiating remote video access.
    Performing firmware upgrades.
    Initiating a print job (via LAN or cloud mode).
    Controlling motion system, temperature, fans, AMS settings, calibrations, etc."

Now, PERHAPS, I can do that authentication locally... but given the plugin required for OrcaSlicer it doesn't seem likely

Yep -- I read that, but that doesn't spell out auth back to BBL's servers, just auth.

And keep in mind that OrcaSlicer already used Bambu Network Plugin to communicate with their printers. (It prompted you to download this on install of OrcaSlicer if you picked one of their printers.)

The move to Connect means that OrcaSlicer needs to send the print data to Connect via a protocol handler instead of to the plugin. Connect will then send it on to the printer itself, and from what I've seen it'll do that over LAN. (But I can't test because my printer doesn't support this yet.) I see this as akin to a print driver vs. printer-specific support built into an app. Not a bad thing at all, if done right.

The plugin already did (very minimal) auth via the Access Code and can do it with the printer and Bambu Network Plugin completely isolated from the internet. (I've done this.) So I'd like to know specifics of what's changing here.

"Operation Guide for Bambu Connect

Start by logging in to the Bambu Lab account or click Discover to find LAN mode printers."

https://wiki.bambulab.com/en/software/bambu-connect

At the very least - it looks like you'd need to log-in to the cloud account to print on the LAN, which really begs the question.... why?

> it looks like you'd need to log-in to the cloud account to print on the LAN

The text you quoted directly contradicts what you are saying. It says login OR discover to find LAN mode printers.

You’re right! Sorry obviously I was one coffee short of comprehension!

what else would it be auth'ing against if not Bambu servers?

Perhaps some... other or better way of authenticating to the printer? Previously there was just a single, essentially fixed, numeric string that gave complete access to the printer, and communication was via TLS with a self-signed cert.

I don't want to hypothesize about what it could be doing, I want to see what it's actually doing (or see some actual info from folks about what they've seen) so I can decide if I'm comfortable with that or not.

The bambu cloud service has a very low value-add and they are trying to make it mandatory. the speculation is that they are trying to add a subscription model for print farms, which 3rd party slicers enable.

the printer itself?

I don't have a definitive source readily available, but from talking to people who were investigating the technical aspects, connection between the printer and slicer software will be mutually authenticated using a certificate that will issued by Bambu Cloud, issued only to blessed 1st party software, and verified by the printer upon connection over the local network.

So your blessed Bambu Studio instance connects to Bambu Cloud and requests a certificate, the server issues the certificate to you (or not), and then Bambu Studio may use it to connect to the printer on your LAN.

The certificates have an expiration time of 1 year, meaning that the printer functionality would severely degraded (missing network connectivity), at most 1 year after they take the servers offline or stop issuing certificates for any reason.

Not a definitive source for what I said, but it contains some information: https://hackaday.com/2025/01/19/bambu-connects-authenticatio...

I sorta get what you're saying, and the flowchart here (https://blog.bambulab.com/updates-and-third-party-integratio...) somewhat agrees.

But where I disagree is with that cert stuff.

1) That cert is on the /client/ side, not in the printer. It has nothing to do with printer functionality, only with talking to the printer.

2) Expired certs do not mean things automatically get rejected. Using and allowing expired or self-signed certs is routine in the IoT world where certs on devices can't readily be updated. But again, that cert isn't from the printer.

3) Expired certs, just like the self-signed certs that are so commonly used, still result in things being encrypted on the wire. And often that's the point.

It seems to me that someone found/exported the cert, and is trying to make all sorts of WHAT-IF or THIS-COULD-MEAN-THE-WORST claims but are lacking some significant understanding. Without understanding the architecture and the rest of the code, and perhaps seeing that cert be used, this is just an artifact found in the distributed beta application.

> That cert is on the /client/ side, not in the printer. It has nothing to do with printer functionality, only with talking to the printer.

What do you mean, if my software can't talk to the printer then that affects printing functionality.

I mean that the extracted cert that's going around is from the client (Bambu Connect) side. Everything it would get used for is a function of the client and how it talks /to/ the printer.

Even if it is used to sign some communications, it doesn't matter if it's expired or not on the server side (the printer side), unless the server chooses not to accept it. And then updating it would be a matter of updating Connect; the client.

There's no reason -- other than hyperbole -- to infer that a certificate which expires on the client side will cause the printer to stop doing anything.

For a web-y example, think of how a website which needs a client cert for auth -- like lots of gov't stuff -- would handle a client cert expiring. It'd either accept it anyway, or reject it. But it wouldn't mean the website breaks. And thus claims of that client certificate's expiration being a killswitch for printers is simply wrong.

It's vendor lock-in (or DRM), not security. Security would be a protocol based on a user specific secret that doesn't inherently require locking down anything to Bambu Lab only software (think username/password). Vendor lock-in is about locking the user into using Bambu Lab software, which is what we see here.

You would never allow your bank account to be secured with something akin to Bambu Lab's "security fix".

- what the key is used for: signing critical operations, most notably print and gcode commands: https://git.devminer.xyz/archive/bambu-connect/src/commit/47..., list of known MQTT commands: https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md

- what the firmware does: verify these operations, meaning it can reject MQTT messages with an invalid/missing signature from third party software

- the big flaw with that approach: by extracting the key, third party software can get full access again

- improvement to security: none (that obfuscation layer doesn't prevent anything if the printer/cloud were vulnerable)

authentication stays the same as before: https://git.devminer.xyz/archive/bambu-connect/src/commit/47...

Reply on news.ycombinator.com