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.
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.
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.
That's because the bank isn't generally using mutual TLS client authentication to verify your account details through your browser. You login with a password and other authentication factors .
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.
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.
Comments
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.
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.
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.
That's because the bank isn't generally using mutual TLS client authentication to verify your account details through your browser. You login with a password and other authentication factors .
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.
None of this makes sense.
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.
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.
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.