The relationship between physics, functional programming and security feels forced.

Like I can see functional programming and physics but security just feels arbitrary.

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.

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?

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)

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.