4 ms·

Don't take this as a snarky comment, but that sounds quite literally as "skill issue". Not in you personally, but in the environment you work in. > PKI isn’t a

by znpy 1y ago

Don't take this as a snarky comment, but that sounds quite literally as "skill issue". Not in you personally, but in the environment you work in. > PKI isn’t a solved problem. PKI is largely a solved issue nowadays. Software like Vault from hashicorp (it's FIPS compliant, too: https://developer.hashicorp.com/vault/docs/enterprise/fips https://developer.hashicorp.com/vault/docs/enterprise/fips) let you create a cryptographically-strong CA and build the automation you need. It's been out for years now, integrating the root CA shouldn't be much of an issue via group policies (in windows, there are equivalents for mac os and gnu/linux i guess). > Just because someone’s homelab is fully cert’d through Caddy and LE that they slapped together over a weekend two years ago, doesn’t mean the process is trivial or easy for the masses. Quite the contrary: it means that the process is technically so trivial the masses can do it in an afternoon and live off it for years with little to no maintenance. Hence, if a large organization is not able to implement that, the issue is in the organization, not in the technology.

ecb_penguin 1y ago
> but that sounds quite literally as "skill issue". Not in you personally, but in the environment you work in. You have no idea the environment they work in. The "skill issue" here is you thinking your basic knowledge of Vault matters. > Software like Vault from hashicorp (it's FIPS compliant, too: https://developer.hashicorp.com/vault/docs/enterprise/fips https://developer.hashicorp.com/vault/docs/enterprise/fips) let you create a cryptographically-strong CA and build the automation you need. They didn't tell you their needs, but you're convinced this vendor product solves it. Are you a non-technical CTO by chance? > there are equivalents for mac os and gnu/linux i guess You guess? I'm sensing a skill issue. Why would you say it's solved for their environment, "I guess??" > Quite the contrary: it means that the process is technically so trivial the masses can do it in an afternoon and live off it for years with little to no maintenance. I'm sensing you work in a low skill environment if you think "home lab trivial" translates to enterprise and defense. > Hence, if a large organization is not able to implement that, the issue is in the organization, not in the technology. Absolutely meaningless statement.
- znpy 1y ago
  > You have no idea the environment they work in. The "skill issue" here is you thinking your basic knowledge of Vault matters. I've deployed Vault both at home and in two different companies, doing anything from pki, mutual-tls, secret storage and other stuff. > > Software like Vault from hashicorp (it's FIPS compliant, too: https://developer.hashicorp.com/vault/docs/enterprise/fips https://developer.hashicorp.com/vault/docs/enterprise/fips) let you create a cryptographically-strong CA and build the automation you need. > They didn't tell you their needs, but you're convinced this vendor product solves it. It was an example from the ecosystem of available tools but in general yes, Vault can do that. Mentioning FIPS compliance was about letting you know that the software can be used also in governative environments. It's not just a "homelab toy". > Are you a non-technical CTO by chance? Senior cloud engineer here. Worked anywhere from not-so-small companies (250 people, 100 engineers) to faangs (tens of thousands of engineers). > > there are equivalents for mac os and gnu/linux i guess > You guess? I'm sensing a skill issue. You're attacking me on a personal level because you can't argue otherwise. That's a common logical fallacy ("Ad Hominem" - https://www.britannica.com/topic/ad-hominem https://www.britannica.com/topic/ad-hominem). You basically have skill issue at debating =) > Why would you say it's solved for their environment, "I guess??" When you account Windows, Mac OS and Linux you're accounting for pretty much the totality of the desktop computing landscape. The last two macbooks I had for work came with the mac os equivalent of group policies with certificates installed etc etc. Enterprise-tier Linux distributions can do that as well (eg: Red Hat Enterprise Linux). > I'm sensing you work in a low skill environment if you think "home lab trivial" translates to enterprise and defense. Again, worked anywhere from companies with 250 people to FAANGs. You have skill issue at sensing, it seems. To get back to the point: homelab "triviality". In a way, yes. Large enterprises and even more defense can spend all the money not just for software but even for consulting from various company that can bring the skills to implement and maintain all the services that are needed, and train your people at that. Things become non trivial not on the base of technical issue, but on the base of organizational issues... If we talk government and defense... Do you know the US government has dedicated cloud regions (eg: https://aws.amazon.com/govcloud-us/ https://aws.amazon.com/govcloud-us/)? Do you really think that cloud providers offer those services at loss? Do you really think a few vault enterprise licenses are the issue there? And by the way, Vault is just an example of one of the possible solutions. It was meant to be an example but you clearly missed the point. > > Hence, if a large organization is not able to implement that, the issue is in the organization, not in the technology. > Absolutely meaningless statement. I think it's very meaningful. It's not 1995, cryptography isn't arcane anymore. We had hardware crypto acceleration in cpu since at least 2010 (AES-NI). The tooling is well established on both servers and clients. The skills are on the market ready to be hired (either via employment or via contracting). The issue is not technical in nature. Oh and by the way: I've worked closely with engineers working for the US government. I wasn't close to the US government (because I am not an US citizen) but they were. They were "close enough" that they had to work in a SCIF and could only interact with me via phone. The systems they were working on... Those systems had their own private CA (among other things). It's feasible. It's not a technical issue. If it's not done then it's an organizational issue.
LeifCarrotson 1y ago
> It's been out for years now, integrating the root CA shouldn't be much of an issue via group policies (in windows, there are equivalents for mac os and gnu/linux i guess). How do you do this on a proprietary device from the late 90s that runs a WindRiver VXWorks RTOS with 1 MB of SRAM? The updated (full color!) Panelview HMI is running Windows CE 6.0, so it's perhaps more likely to be compatible, but I don't think the same group policies exist on that platform. The masses can do it in an afternoon because they can choose to only install modern equipment that's compatible with the new requirements. Some of the "heavy iron" castings for the machines we have to work with were built more than a century ago, and only later automated with tubes and relays, and then again with the first PLCs that could do the job. But now "SSL everywhere" policies and certificate expiration timelines that don't make a distinction between firewalled OT networks and Internet-facing webservers don't allow anything to run for a decade without major, risky rewrites that cost tens of thousands of dollars for highly specialized engineering services and minimal downtime. Sure, adding a cert to the SCADA server is trivial, it runs Windows Server and has a NIC that can access the Internet, but on the other NIC...there's a menagerie of 30 years of industrial oddities. If your homelab is still working after 2 years, that's great, but if it's not running after 100 years would you call that an organizational failure?
- Muromec 1y ago
  >How do you do this on a proprietary device from the late 90s that runs a WindRiver VXWorks RTOS with 1 MB of SRAM? You dont and you are not supposed to bend security posture backwards to accomodate insecure devices that should be in the landfill by now
- wrs 1y ago
  Put a modern reverse proxy in front of the legacy thing and turn off cert verification in the proxy? Or if the problem is the reverse, tell the legacy thing to use a forward proxy configured like it’s 2001 as its router.
- znpy 1y ago
  > How do you do this on a proprietary device from the late 90s that runs a WindRiver VXWorks RTOS with 1 MB of SRAM? You weight the cost of incurring in that thing getting hacked against the cost of that thing being rebuilt on modern hardware with modern technologies and enough processing power to do TLS. Then you pick the "rebuild route". Easy. Anyway, it's crazy how on this forum it goes from "REWRITE EVERYTHING IN RUST!!! ANYTHING THAT'S NOT RUST IS INHERENTLY UNSAFE" to the complete opposite of "why doesn't anybody think of the poor WindRiver VXWorks RTOS!!". > Sure, adding a cert to the SCADA server is trivial, it runs Windows Server and has a NIC that can access the Internet, but on the other NIC...there's a menagerie of 30 years of industrial oddities. Not gonna lie, all i hear is "i'm annoyed i was able to ignore the problem for 30 years but now i have to actually fix it".

by znpy 1y ago

ecb_penguin 1y ago

> but that sounds quite literally as "skill issue". Not in you personally, but in the environment you work in. You have no idea the environment they work in. The "skill issue" here is you thinking your basic knowledge of Vault matters. > Software like Vault from hashicorp (it's FIPS compliant, too: https://developer.hashicorp.com/vault/docs/enterprise/fips https://developer.hashicorp.com/vault/docs/enterprise/fips) let you create a cryptographically-strong CA and build the automation you need. They didn't tell you their needs, but you're convinced this vendor product solves it. Are you a non-technical CTO by chance? > there are equivalents for mac os and gnu/linux i guess You guess? I'm sensing a skill issue. Why would you say it's solved for their environment, "I guess??" > Quite the contrary: it means that the process is technically so trivial the masses can do it in an afternoon and live off it for years with little to no maintenance. I'm sensing you work in a low skill environment if you think "home lab trivial" translates to enterprise and defense. > Hence, if a large organization is not able to implement that, the issue is in the organization, not in the technology. Absolutely meaningless statement.

znpy 1y ago
> You have no idea the environment they work in. The "skill issue" here is you thinking your basic knowledge of Vault matters. I've deployed Vault both at home and in two different companies, doing anything from pki, mutual-tls, secret storage and other stuff. > > Software like Vault from hashicorp (it's FIPS compliant, too: https://developer.hashicorp.com/vault/docs/enterprise/fips https://developer.hashicorp.com/vault/docs/enterprise/fips) let you create a cryptographically-strong CA and build the automation you need. > They didn't tell you their needs, but you're convinced this vendor product solves it. It was an example from the ecosystem of available tools but in general yes, Vault can do that. Mentioning FIPS compliance was about letting you know that the software can be used also in governative environments. It's not just a "homelab toy". > Are you a non-technical CTO by chance? Senior cloud engineer here. Worked anywhere from not-so-small companies (250 people, 100 engineers) to faangs (tens of thousands of engineers). > > there are equivalents for mac os and gnu/linux i guess > You guess? I'm sensing a skill issue. You're attacking me on a personal level because you can't argue otherwise. That's a common logical fallacy ("Ad Hominem" - https://www.britannica.com/topic/ad-hominem https://www.britannica.com/topic/ad-hominem). You basically have skill issue at debating =) > Why would you say it's solved for their environment, "I guess??" When you account Windows, Mac OS and Linux you're accounting for pretty much the totality of the desktop computing landscape. The last two macbooks I had for work came with the mac os equivalent of group policies with certificates installed etc etc. Enterprise-tier Linux distributions can do that as well (eg: Red Hat Enterprise Linux). > I'm sensing you work in a low skill environment if you think "home lab trivial" translates to enterprise and defense. Again, worked anywhere from companies with 250 people to FAANGs. You have skill issue at sensing, it seems. To get back to the point: homelab "triviality". In a way, yes. Large enterprises and even more defense can spend all the money not just for software but even for consulting from various company that can bring the skills to implement and maintain all the services that are needed, and train your people at that. Things become non trivial not on the base of technical issue, but on the base of organizational issues... If we talk government and defense... Do you know the US government has dedicated cloud regions (eg: https://aws.amazon.com/govcloud-us/ https://aws.amazon.com/govcloud-us/)? Do you really think that cloud providers offer those services at loss? Do you really think a few vault enterprise licenses are the issue there? And by the way, Vault is just an example of one of the possible solutions. It was meant to be an example but you clearly missed the point. > > Hence, if a large organization is not able to implement that, the issue is in the organization, not in the technology. > Absolutely meaningless statement. I think it's very meaningful. It's not 1995, cryptography isn't arcane anymore. We had hardware crypto acceleration in cpu since at least 2010 (AES-NI). The tooling is well established on both servers and clients. The skills are on the market ready to be hired (either via employment or via contracting). The issue is not technical in nature. Oh and by the way: I've worked closely with engineers working for the US government. I wasn't close to the US government (because I am not an US citizen) but they were. They were "close enough" that they had to work in a SCIF and could only interact with me via phone. The systems they were working on... Those systems had their own private CA (among other things). It's feasible. It's not a technical issue. If it's not done then it's an organizational issue.

LeifCarrotson 1y ago

> It's been out for years now, integrating the root CA shouldn't be much of an issue via group policies (in windows, there are equivalents for mac os and gnu/linux i guess). How do you do this on a proprietary device from the late 90s that runs a WindRiver VXWorks RTOS with 1 MB of SRAM? The updated (full color!) Panelview HMI is running Windows CE 6.0, so it's perhaps more likely to be compatible, but I don't think the same group policies exist on that platform. The masses can do it in an afternoon because they can choose to only install modern equipment that's compatible with the new requirements. Some of the "heavy iron" castings for the machines we have to work with were built more than a century ago, and only later automated with tubes and relays, and then again with the first PLCs that could do the job. But now "SSL everywhere" policies and certificate expiration timelines that don't make a distinction between firewalled OT networks and Internet-facing webservers don't allow anything to run for a decade without major, risky rewrites that cost tens of thousands of dollars for highly specialized engineering services and minimal downtime. Sure, adding a cert to the SCADA server is trivial, it runs Windows Server and has a NIC that can access the Internet, but on the other NIC...there's a menagerie of 30 years of industrial oddities. If your homelab is still working after 2 years, that's great, but if it's not running after 100 years would you call that an organizational failure?

Muromec 1y ago
>How do you do this on a proprietary device from the late 90s that runs a WindRiver VXWorks RTOS with 1 MB of SRAM? You dont and you are not supposed to bend security posture backwards to accomodate insecure devices that should be in the landfill by now
wrs 1y ago
Put a modern reverse proxy in front of the legacy thing and turn off cert verification in the proxy? Or if the problem is the reverse, tell the legacy thing to use a forward proxy configured like it’s 2001 as its router.
znpy 1y ago
> How do you do this on a proprietary device from the late 90s that runs a WindRiver VXWorks RTOS with 1 MB of SRAM? You weight the cost of incurring in that thing getting hacked against the cost of that thing being rebuilt on modern hardware with modern technologies and enough processing power to do TLS. Then you pick the "rebuild route". Easy. Anyway, it's crazy how on this forum it goes from "REWRITE EVERYTHING IN RUST!!! ANYTHING THAT'S NOT RUST IS INHERENTLY UNSAFE" to the complete opposite of "why doesn't anybody think of the poor WindRiver VXWorks RTOS!!". > Sure, adding a cert to the SCADA server is trivial, it runs Windows Server and has a NIC that can access the Internet, but on the other NIC...there's a menagerie of 30 years of industrial oddities. Not gonna lie, all i hear is "i'm annoyed i was able to ignore the problem for 30 years but now i have to actually fix it".