I shall join the ranks of the idiots then, cause the question "Are the certificates on these IoT devices centrally managed?" makes no sense to me either, just not because I wouldn't know what certificates are.
Centrally managed? Like are these devices enrolled into some centralized management system, and so is the question whether that system also manages the OS root cert store? (And would have been followed up with whether it blocks TLS traffic that it's unable to intercept?) Or is it maybe whether the vendor's applications deployed to these devices use that or carry their own?
But then I read on, and PKI and HTTPS comes up. Is centrally managed then referring to PKI being a centralized trust system, and so is the question really "are you using CA issued domain certs"? Why the contrived phrasing then?
And then there's a mention of an internal domain name. Internal as in private? Sounds a bit suspect that the guys who don't know what a certificate is would have a private DNS with a private CA to boot, but it sure would be centralized alright.
I think it's inquisitive that the first common point reached was HTTPS: yes/no? -> yes. But then even that was seemingly a bit too new info: in the portrayed discussion it is first also asked whether HTTP is in picture. This makes me question, just what did the author even know about these devices when they prompted their centrally managed certificates question.
Maybe a better question at that stage would have been, "So, how do these devices communicate, and what to?", letting them explain it in their own terms first?
In a normal OS under normal conditions, the certificate store is centrally managed by the OS vendor. The answer then is “yes”.
But it's possible to install a certificate of your own in which case the answer is probably “no” because when it expires you're going to have to to every one of those machines and install the replacement.
Or imagine an embedded computer that doesn't even have an OS. Then the certificate store just has whatever the developer put into it when they built the image. Again the answer is “no”. If you're lucky you can still rebuild the image and reflash the devices even though the engineer who did the work was fired as a cost–cutting measure. If you're not lucky then that VP’s cost–cutting has actually added a lot of cost.
Unfortunately a lot of documentation and tooling for TLS apis are horrible.
For example when working with Apple's Network.Framework, I have to drop to C and use functions like "sec_protocol_options_add_tls_application_protocol". Maybe the new beta framework is better.
Or if I want to get a certificate hash on the command line in a usable format,
I'd have to run
"openssl x509 -in server.crt -noout -fingerprint -sha256 | sed 's/://g' | cut -d= -f2"
Networking and security is still a dark art and it shouldn't be.
Great read! The analogy between physics and infosec is spot-on—both rely on understanding fundamental principles that are often overlooked. The "AES256-over-HTTP" anecdote is both hilarious and terrifying, highlighting how abstraction can hide critical gaps. As a dev, I see similar issues when devs prioritize speed over security basics. Curious—what’s your go-to approach for teaching devs about PKI or mTLS without overwhelming them?
>Now, I'm not blaming developers. Modern software engineering is built on abstraction layers, and that's actually amazing! We've gone from assembly language to high-level frameworks, from bare metal to cloud-native platforms. A developer can slap a @RestController annotation on a Java class and magically have an HTTPS endpoint without knowing anything about TLS handshakes or certificate chains.
Well, you should blame the developer if they don't know the basics of computer science (TLS handshake being the basics)
very good philosphy, near the end author says "Think of yourself as a physics teacher, not a physics textbook."
Very good.
As for appearing surprised that many people do not care, so it is.
Everyone has a relative that after 30 years still doesn't know how to use the airco controls?
I read somewhere it all follows some sort of gaussian/normal distribution, like in 11 peole there might be 1 knowledgeable, 2 interested, 5 pretending to listen, 2 bored, 1 sneaking out.
Sometimes it's you or me who sneaks out.
the underlying connection the author is making between physics and security is knowing the low level laws governing the systems you are dealing with, or at least being aware of them. if anything the functional programming bit could have been left out.
The low level laws "governing" security are just procedural rules made up by humans. There could be a thousand ways to "secure" something but the author is just following convention here.
The axioms of functional programming and physics are not arbitrary conventions. They are fundamental to reality.
At its foundation modern security is based on ideas from information theory and cryptography that were discovered, not invented. Arguably just as fundamental as the postulates of general relativity or quantum mechanics.
Doesn't change a thing. All things are derived from fundamental principles.
IT Security is an arbitrary methodology derived from fundamental principles, but it doesn't change the fact that it's arbitrary.
I can make up dozens of ways to make something "secure" that doesn't follow convention. Why isn't he using biometric data like saliva DNA testing to verify identity? And why are they using a channel that anyone can peek at? Send the signals and credentials over a blinking laser light and therefore we know if the laser is disrupted we have someone trying to peek at the encrypted signal.
See what I'm saying, I can arbitrarily come up with dozens of ways to make things not only just as secure, but MORE secure. IT security is mostly memorization of convention. These conventions are derived from fundamentals, they are not principles themselves. There are thousands of orthogonal methodologies to achieve the same level of secureness but the set we use for IT are just an arbitrary selection out of an infinite amount of possibilities.
but that's not the analogy the article was making at all! it was making an analogy with using technology based on underlying physical principles, where you could either be cognizant or ignorant of those principles, and similarly you could use something like https while either knowing or not knowing what the lower level pieces it relied on were.
Yeah and I'm saying it's a bad analogy. Because the principles of security are made up. They aren't fundamental. They are arbitrary and they exist by convention.
Usually concepts that are arbitrary I wouldn't call "principles" because they aren't principles. Just convenient rules to follow. A principle is much deeper.
I think that technical people tend to see their area of expertise the most fundamental one, from which everything else derives.
This guy specialized in security and so he thinks that the concepts that he learned underlying everything, and everything else is just application.
But he's making the same mistake as everyone else. Everybody has gaps in their knowledge, it's just that he chooses to talk down to people who have their in their knowledge in _his_ area of expertise. Physicists do this a lot (I should know: I trained as a physicist so I know a lot of physicists). "Physics is really everything, everything else could be deducted from physics in principle, so no point spending time thinking about it". He carried this attitude into the next area of expertise he learned.
I'm with the project manager. "How does the gorb fleem the leemaflop?" Don't know, don't care, you do your job and I do mine. Time is finite and I'd rather spend my time on things I find intellectually stimulating, not IT security. The irony is, if everybody could reliably answer those questions, he wouldn't have a job. I find the lack of understanding quite disgusting frankly.
I shall join the ranks of the idiots then, cause the question "Are the certificates on these IoT devices centrally managed?" makes no sense to me either, just not because I wouldn't know what certificates are.
Centrally managed? Like are these devices enrolled into some centralized management system, and so is the question whether that system also manages the OS root cert store? (And would have been followed up with whether it blocks TLS traffic that it's unable to intercept?) Or is it maybe whether the vendor's applications deployed to these devices use that or carry their own?
But then I read on, and PKI and HTTPS comes up. Is centrally managed then referring to PKI being a centralized trust system, and so is the question really "are you using CA issued domain certs"? Why the contrived phrasing then?
And then there's a mention of an internal domain name. Internal as in private? Sounds a bit suspect that the guys who don't know what a certificate is would have a private DNS with a private CA to boot, but it sure would be centralized alright.
I think it's inquisitive that the first common point reached was HTTPS: yes/no? -> yes. But then even that was seemingly a bit too new info: in the portrayed discussion it is first also asked whether HTTP is in picture. This makes me question, just what did the author even know about these devices when they prompted their centrally managed certificates question.
Maybe a better question at that stage would have been, "So, how do these devices communicate, and what to?", letting them explain it in their own terms first?
The difference here is that you know enough to ask the follow-up questions
In a normal OS under normal conditions, the certificate store is centrally managed by the OS vendor. The answer then is “yes”.
But it's possible to install a certificate of your own in which case the answer is probably “no” because when it expires you're going to have to to every one of those machines and install the replacement.
Or imagine an embedded computer that doesn't even have an OS. Then the certificate store just has whatever the developer put into it when they built the image. Again the answer is “no”. If you're lucky you can still rebuild the image and reflash the devices even though the engineer who did the work was fired as a cost–cutting measure. If you're not lucky then that VP’s cost–cutting has actually added a lot of cost.
Unfortunately a lot of documentation and tooling for TLS apis are horrible.
For example when working with Apple's Network.Framework, I have to drop to C and use functions like "sec_protocol_options_add_tls_application_protocol". Maybe the new beta framework is better.
Or if I want to get a certificate hash on the command line in a usable format, I'd have to run "openssl x509 -in server.crt -noout -fingerprint -sha256 | sed 's/://g' | cut -d= -f2"
Networking and security is still a dark art and it shouldn't be.
Great read! The analogy between physics and infosec is spot-on—both rely on understanding fundamental principles that are often overlooked. The "AES256-over-HTTP" anecdote is both hilarious and terrifying, highlighting how abstraction can hide critical gaps. As a dev, I see similar issues when devs prioritize speed over security basics. Curious—what’s your go-to approach for teaching devs about PKI or mTLS without overwhelming them?
>Now, I'm not blaming developers. Modern software engineering is built on abstraction layers, and that's actually amazing! We've gone from assembly language to high-level frameworks, from bare metal to cloud-native platforms. A developer can slap a @RestController annotation on a Java class and magically have an HTTPS endpoint without knowing anything about TLS handshakes or certificate chains.
Well, you should blame the developer if they don't know the basics of computer science (TLS handshake being the basics)
I agree that programmers should know it, but I don't think Diffie-Hellman key exchange is core computer science.
It’s definitely possible to properly implement TLS without fully understanding the exact mechanics
very good philosphy, near the end author says "Think of yourself as a physics teacher, not a physics textbook." Very good. As for appearing surprised that many people do not care, so it is.
Everyone has a relative that after 30 years still doesn't know how to use the airco controls?
I read somewhere it all follows some sort of gaussian/normal distribution, like in 11 peole there might be 1 knowledgeable, 2 interested, 5 pretending to listen, 2 bored, 1 sneaking out. Sometimes it's you or me who sneaks out.
The relationship between physics, functional programming and security feels forced.
Like I can see functional programming and physics but security just feels arbitrary.
the underlying connection the author is making between physics and security is knowing the low level laws governing the systems you are dealing with, or at least being aware of them. if anything the functional programming bit could have been left out.
The low level laws "governing" security are just procedural rules made up by humans. There could be a thousand ways to "secure" something but the author is just following convention here.
The axioms of functional programming and physics are not arbitrary conventions. They are fundamental to reality.
At its foundation modern security is based on ideas from information theory and cryptography that were discovered, not invented. Arguably just as fundamental as the postulates of general relativity or quantum mechanics.
Doesn't change a thing. All things are derived from fundamental principles.
IT Security is an arbitrary methodology derived from fundamental principles, but it doesn't change the fact that it's arbitrary.
I can make up dozens of ways to make something "secure" that doesn't follow convention. Why isn't he using biometric data like saliva DNA testing to verify identity? And why are they using a channel that anyone can peek at? Send the signals and credentials over a blinking laser light and therefore we know if the laser is disrupted we have someone trying to peek at the encrypted signal.
See what I'm saying, I can arbitrarily come up with dozens of ways to make things not only just as secure, but MORE secure. IT security is mostly memorization of convention. These conventions are derived from fundamentals, they are not principles themselves. There are thousands of orthogonal methodologies to achieve the same level of secureness but the set we use for IT are just an arbitrary selection out of an infinite amount of possibilities.
but that's not the analogy the article was making at all! it was making an analogy with using technology based on underlying physical principles, where you could either be cognizant or ignorant of those principles, and similarly you could use something like https while either knowing or not knowing what the lower level pieces it relied on were.
Yeah and I'm saying it's a bad analogy. Because the principles of security are made up. They aren't fundamental. They are arbitrary and they exist by convention.
Usually concepts that are arbitrary I wouldn't call "principles" because they aren't principles. Just convenient rules to follow. A principle is much deeper.
I think that technical people tend to see their area of expertise the most fundamental one, from which everything else derives.
This guy specialized in security and so he thinks that the concepts that he learned underlying everything, and everything else is just application.
But he's making the same mistake as everyone else. Everybody has gaps in their knowledge, it's just that he chooses to talk down to people who have their in their knowledge in _his_ area of expertise. Physicists do this a lot (I should know: I trained as a physicist so I know a lot of physicists). "Physics is really everything, everything else could be deducted from physics in principle, so no point spending time thinking about it". He carried this attitude into the next area of expertise he learned.
I'm with the project manager. "How does the gorb fleem the leemaflop?" Don't know, don't care, you do your job and I do mine. Time is finite and I'd rather spend my time on things I find intellectually stimulating, not IT security. The irony is, if everybody could reliably answer those questions, he wouldn't have a job. I find the lack of understanding quite disgusting frankly.
Yeah, he is talking a bit down to everybody.