notakio

I think it maps to the proclivity of the engineer to want to understand the multiple layers that apply to whatever they're working on. The more curious, the more likely that engineer is to gain a better understanding of the whole, and therefore presumably be able to do better engineering.

When I worked at a particular fruit company in Cupertino, my boss had been asked repeatedly by the developer teams to provide a tour of the data center we'd recently finished building out, which housed the servers their code ran on.

He gave them a lengthy, grueling, hyper-detailed tour of the entire facility, encompassing the HVAC systems, electrical systems, network and computing systems, finishing with about 20 minutes where he had them stand inside a hot aisle that he was just outside of, giving a fantastic soliloquy on the importance of code efficiency, and the consequences of ignoring it. It was hilarious to watch from the comfort of the cold aisle, knowing full well what he was doing.

I simply meant that if you monitor a given application using on-system network tools, you quickly get an accurate idea of what/who that application talks to. And browsers are super-chatty to all sorts of destinations that are not immediately apparent to an end user who is just clicking around the web.

Besides lsof and netstat?

We're still good now.

Whoops. I used hyperbole, and it went undetected. Here: s/the deciding factor/a deciding factor/g. We're good now.

One should be wary of anyone selling you a solution to your problems they know nothing about. Naturally, the only way to be entirely secure is to shutdown all the applications and decommission all the computers, a solution which the business side tends to finds unreasonable. Thus the tender balance between business needs and business risk emerges as the deciding principle.

But the numbers are the numbers in heterogenous environments, regarding security problems by platform. And if it rains perpetual Windows-based incidents on your security staff, and you don't consider the numbers when evaluating what you will and will not do, compute/services-wise, then you are statistically likely to see the same rate of incidents, at whatever cost that comes to the business, indefinitely.

If every car in your neighborhood that gets broken into is manufactured by a single manufacturer, it is in your interest in asking why that is, and perhaps considering that fact when shopping for a new car.

Very curious. Just based on the incidents we see, and analyze over time, almost all of them are compromised Windows systems. When I say "almost", I'll provide these stats: ~4500 Windows incidents over 5 years, vs. two Linux incidents.

Similarly, looking at vulnerability counts by vendor doesn't paint a rosy picture of our largest vendor Microsoft, either. But it pales in comparison to the incident statistics, which speak for themselves.

To Microsoft's credit, they've managed to turn their weaknesses into a secondary industry, wherein they now no longer sell just the disease, they also sell the cure. "Oh, your Windows systems have security problems? Have we told you about our expansive security solutions? They're only an additional $your_budget_doubled per year!"

No, LetsEncrypt was not an EFF project to begin with. Look, it works how it's documented to work. If you wish it worked some other way, to solve your particular suggested workflow, you're likely free to fork it and make it work that way.

Good luck.

No, it's not the LetsEncrypt people who make certbot. Certbot is an EFF project, managed by separate people. Additionally, most of the DNS implementations will require the use of a specific plug-in/library for your selected DNS platform, and those, also, are developed separately.

Regarding "the DNS record they had you add to begin with is still there", it generally isn't. Part of the automation process for certbot using the DNS-01 challenge is the removal of the DNS record, following successful validation of said record. In any complex DNS environment, leaving TXT records around just increases the debris.

This is compounded by their propensity to rename everything at periodic intervals.

For the Microsoft.com domain, proper, there seem to be no existing CAA rules, allowing each and every CA on earth to issue certificates based on whatever criteria the CA requires. What could possibly go wrong with that approach?

I have not. I'm afraid I am a gaming luddite, though for no particular reason other than having a lengthy list of mental "to-dos" in front of it.