It is a matter of priorities. In my experience, while saving in financial costs, tiering between HDD and SSD frequently comes at great sanity/frustration cost for those maintaining it. It can make sense commercially if there’s a team (internal or external) to take care of things going sideways.
Agreed. I’ve been planning on building a home NAS and really wish SSDs were already there.
Storage tiering between HDD and SSD has always been a nightmare and generally worth just avoiding.
I’ve kept away from VMWare most of my career. I’d personally push for something KVM/QEMU based, if possible, whether it be Proxmox, LXD, or a RHEL offering. If you are in a fully MS shop, probably Hyper-V.
How so?
I think that, perhaps, the user is trying to use Lemmy as Reddit, rather than using some of the fantastic quality of life improvements that evaporated with the API nonsense.
For example, blocking users and communities (and soon instances). Some users and communities, even if I enjoy them or the instances that they are on, sometimes are just too toxic for me. And that isn’t to say that the comms and users necessarily are (sometimes they are) but, that sometimes engaging with some comms and users either causes undue stress or temptation to get involved in an Internet fight. That’s not behavior that is good for us, even if it sometimes feels good in the moment.
I’m hoping (and have suggested) that a “timeout” feature gets added to allow one to readily self-regulate and disengage when they find that interactions are approaching the sorts that are algorithmically encouraged on commercial social media platforms. The outrage machine is just terrible and I’ve found myself much happier and in a better headspace since leaving such platforms. Added bonus is that transphobia actually gets taken seriously on most instances and, while it doesn’t technically impact my as a cis guy, I’m much happier knowing that people are able to feel safer to be themselves (or come to terms with themselves).
As for the complaint about people being more likely pedantic or correct people on technical details, I love that - finding out that I’m wrong about something is fantastic because that means that I learned something. When there’s topics, like tech, where there are often correct and incorrect answers and they change or get added to regularly, one really needs to leave the ego at the door. We’re all humans (and bots and human facsimiles), which means we’ll be wrong from time to time. It’s a fact of life, effectively in environments where there are a lot of knowledge-workers and the medium of communication is directly related to the topics.
Personally, I’d like to see more comms regarding to digital circuit design and open-source silicon.
Oh fun. Thanks for sharing! Have a great day, yourself!
Use of a CA (private CA would be my thought in this case) gives you greater ability to manage certs without needing to manually revoke and the ability to verify authenticity. You’re already doing most of the work to run a private CA, TBH. Just, instead of signing from the machine, you add your private CA’s intermediate cert to the trusted CAs on your hosts, and generate CSRs on your new hosts for your CA to sign.
Signing from the machine that uses a cert gives it greater authority and increases the “blast radius” if it gets compromised.
Your man in the middle argument is invalid, no matter how much you write.
It really isn’t and it’s a significant part of why PKI exists in the first place. I’ve been doing this stuff professionally for over a decade and am very familiar with ISO27001, SOC2, and CIS standards, as well as generally just finding that a healthy dose of paranoia in computing keeps things more secure. Understanding how and why PKI works and is architected as it is is something that I recommend that everyone involved in technology explore.
Just trust youur self signed certs and you users see no difference.
This is problematic if a service needs to be redeployed, the cert expires, or becomes compromised, leaking its keys. In the former two scenarios, the new cert needs to be added on all of your end users’ machines. If you have just a few users, sure, that’s easy enough but, tedious and unnecessary. If it is a case of the latter, you now need to revoke the cert on all systems that have trusted it and deploy a new one. Again, tedious and prone to human error. Plus, you have to hope that you detect this quickly, otherwise a malicious host can harvest a lot of potentially-sensitive information, a situation easily prevented with a trusted CA.
That’s even more secure than blindly trusting the idiots from verisign.
I’m not suggesting that a public CA is the best choice for everyone or every situation. For internal use, a well-managed private CA or LE is probably a better choice, purely from a cost perspective.
I’d also like to understand why you are so hostile towards Verisign and feel better qualified in cert management. Were you or someone close to you caught up in their 2010 breach?
Don’t act so smug.
Not sure where this hostility is coming from. I am primarily explaining how these statements are not in line with intended use of security technologies and best practices. If you don’t like currently accepted security best practices, that’s absolutely your prerogative.
That’s bullshit.
Nope. That’s the basics of PKI and scalable, secure, low-trust environments.
You are the one who issued the cert. You can add it to your list of trusted certificates. You just have to check that this is the right certificate.
You can indeed do these things. But, are you and your users going to verify every cert for every request and response? That’s a lot of unnecessary cognitive load and tedium, both of which are known to compromise judgement. Are you going to automate it? Ok then how are you going to verify the authenticity of a given cert?
Your man in the middle scare comes from users who ignore cert warnings and continue without checking anything.
Humans are not rational actors. Does everyone read the entire EULA? Not even close.
The problem with your statement, and why it is fallacious, is that you are not accounting for humans besides yourself. I’d even argue that you should also take your human nature into account because we all make mistakes.
Robust security postures do not require everyone to act perfectly but accept and plan for the fact that we’re fallible. That is why chains and webs of trust were created, so that humans and automated services can take an approach of deference towards a less mutable “expert” on whether a claim of authenticity is trustworthy - giving them the capability and responsibility of deciding this for themselves introduces unnecessary targets for exploits.
Oh! Then you are doing it right. That was basically my entire objection - having A chain of trust is necessary to effectively and securely use certs because you have a mechanism to validate, rather than trust the cert that is presented as authentic. :)
Certs do more than encryption in transit. They are also used for protection against MitM and authentication. Self-signing removes the ability to verify a cert’s authenticity.
You do SSL mutual auth between services using self signed certs
If you do, you remove the ability to prove that a service is what it claims to be as this requires accepting its provided cert - that is, authenticate it. You have to trust somewhere, even in a “zero trust” environment. Using self-signed certs for services to communicate means that you have to either have manual involvement every time a service comes up or accept the authenticity of a self-signed cert automatically. Either would be a compromise in security over use of a private CA, not an improvement.
Again, that works if your only concern is data across the pipes being encrypted during transmission but, it removes nearly all of the other additional security provided by PKI and increases your threat surface. It can be acceptable in some cases, like dev envs or as temporary measures but, with the constant increase in malicious traffic and activity, we’ve got to aim for better.
And if you’re not using a trusted CA, you are unable to protect against MitM and other forgery attacks, as well as needing to rely upon a mechanism like TOFU in order to avoid auth fatigue and other human error, which is not great.
Could you explain your statement further?
Correct. If using actual pki with a trusted root and private CA, you’re just fine.
I took the statement to mean ad-hoc self-signed certs, signed by the server that they are deployed on. That works for EiT but defeats any MitM protection, etc.
So is using “pass” as the password to all of your sensitive systems. Still not best, or even good practice.
Not pictured: Using a CA to properly administer certs because self-signed certs are not secure.
Ouch. Have you tried simply being born insanely wealthy? /s