3 ms·

It happened to me - I was working on an application for the pre-paid electricty system in Texas: the server-side code connects to a data-source over a TLS conne

It happened to me - I was working on an application for the pre-paid electricty system in Texas: the server-side code connects to a data-source over a TLS connection (complete with client-side certificates too), except the server-side used a self-signed certificate, and my code didn't have admin/root rights on the client hardware so it had to use in-app certification verification code. I had to hard-code the root CA's fingerprints directly into my code so it would be baked into the signed binary (this was a project requirement). That thing is going to fall-apart if the root CA ever changes - fortunately it won't expire until 2099. (Yes, I gave the client a strongly worded statement of my misgivings - and all the other bad code-smells in the project)

pauldino 10y ago
So basically you're pinning the server certificate chain into your signed client code? Actually that sounds like a good thing! https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning https://www.owasp.org/index.php/Certificate_and_Public_Key_P...
- jacquesm 10y ago
  Except that that likely ended up baked into a system that is hard or impossible to upgrade. So when the certificate is revoked or changed the system stops working.
- ygjb 10y ago
  Pinning is a good thing, assuming you have built in a reliable upgrade path (oh hey, browsers update themselves automagically now so yay!) but when you have occasionally connected devices that have low bandwidth that have a long deploy lifecycle, it's not always feasible, or even a good idea. It's even worse if said device is embedded and has severe hardware constraints for compliance and regulatory reasons, and those same reasons prevent you from deploying patches on the regular. Layer in some "built by the lowest bidder" and "accumulation of 30-odd years of poor practices for smart payment cards" and you have a big mess of a situation to unravel. Oh yeah, and lest you think this is not an issue because this is browser related, may I introduce you to the world of services that proxy legacy green terminal applications into web front ends, ranging from IBM HATS to bespoke AJAXy things that unwrap screen scraped terminal emultor content from XMLHttpRequests. Jeez. Remembering why I used to drink more when I worked in fintech :)

pauldino 10y ago

So basically you're pinning the server certificate chain into your signed client code? Actually that sounds like a good thing! https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning https://www.owasp.org/index.php/Certificate_and_Public_Key_P...

jacquesm 10y ago
Except that that likely ended up baked into a system that is hard or impossible to upgrade. So when the certificate is revoked or changed the system stops working.
ygjb 10y ago
Pinning is a good thing, assuming you have built in a reliable upgrade path (oh hey, browsers update themselves automagically now so yay!) but when you have occasionally connected devices that have low bandwidth that have a long deploy lifecycle, it's not always feasible, or even a good idea. It's even worse if said device is embedded and has severe hardware constraints for compliance and regulatory reasons, and those same reasons prevent you from deploying patches on the regular. Layer in some "built by the lowest bidder" and "accumulation of 30-odd years of poor practices for smart payment cards" and you have a big mess of a situation to unravel. Oh yeah, and lest you think this is not an issue because this is browser related, may I introduce you to the world of services that proxy legacy green terminal applications into web front ends, ranging from IBM HATS to bespoke AJAXy things that unwrap screen scraped terminal emultor content from XMLHttpRequests. Jeez. Remembering why I used to drink more when I worked in fintech :)