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?

> For Security Professionals (us): Stop being gatekeepers and start being enablers. Put down the "How do you not know this?" attitude and pick up the "Let me explain why this matters" approach.

Eeeehhhh… gatekeeping is, IMO, not quite the right term.

On the one hand, gatekeeping is restricting access until conditions are met, regardless of how spurious and irrational those conditions are. And usually, despite some pretty insane conditions. Questioning the fundamental competency of someone who ought to know even just a little better is challenging why they aren’t already possessing access, not preventing access in the first place.

On the other hand, most people in the IT industry love to talk about all the little shinies they are obsessed about. So while they may not be the best teachers in the first place, tickle their passionate shinies hard enough and they will talk your ear clean off, down the hallway, drop it through the lift and have it staggering bloody and beaten onto the sidewalk outside before you can get a word in edgewise. So getting people in IT to be advocates for the work subjects they are passionate about is not the problem - it’s training them how to deliver that information effectively to someone not in the know and not initially passionate about it.

On the gripping hand, there are plenty of people in almost every industry for whom ”How do you NOT know about this core component of your job??” is a very valid criticism to lob with great enthusiasm at them. A verbal shock like this can be very useful for disturbing a person out of their complacency, especially if they already see themselves as an SME. The real trick is following that statement up with something that can truly inspire and encourage them to willingly reach for competency in that component.

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 am gonna be that guy but;

    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.

Which is why AI seemingly replacing junior engineers, because AI does the same thing, faster and cheaper...

Meanwhile, I as an engineer, see less and less appreciation and importance in my organization about "knowing" these stuff.

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.