Best systemd hardening is switching to OpenRC or runit
Do you have any references for doing similar system hardening under either of those?
Readit Newsmcpherrinm commented on SystemD Service Hardening roguesecurity.dev/blog/sy... · Posted by u/todsacerdoti
mcpherrinm commented on Vaultwarden commit introduces SSO using OpenID Connect github.com/dani-garcia/va... · Posted by u/speckx
Who needs it except entreprises for the 99.99% usecase?
Everyone from the single-user homelab to the biggest companies should have SSO.
mcpherrinm commented on Cloudflare 1.1.1.1 Incident on July 14, 2025 blog.cloudflare.com/cloud... · Posted by u/nomaxx117
That sounds good in principle, but is there a more private configuration that doesnt send DNS resolutions to cloudfare, google et al. ie. avoid BigTech tracking, and not wanting DOH.
dnsmasq with a list of smaller trusted DNS providers sounds perfect, as long as it is not considered bad etiquette to spam multiple DNS providers for every resolution?
But where to find a trusted list of privacy focused DNS resolvers. The couple I tried from random internet advice seemed unstable.
I've reviewed the privacy policy and performance of various DoH servers, and determined in my opinion that Cloudflare and Google both provide privacy-respecting policies.
I believe that they follow their published policies and have reasonable security teams. They're also both popular services, which mitigates many of the other types of DNS tracking possible.
https://developers.google.com/speed/public-dns/privacyhttps://developers.cloudflare.com/1.1.1.1/privacy/public-dns...
mcpherrinm commented on Running a Certificate Transparency log words.filippo.io/run-sunl... · Posted by u/Metalnem
I wonder how much putting a CDN in front of this would reduce this.
According to the readme, it seems like the bulk of the traffic is highly cacheable, so presumably you could park something a CDN in front and substantially reduce the bandwidth requirements.
Yes, the static-ct api is designed to be highly cacheable by a CDN.
That is one of the primary motivations of its design over the previous CT API, which had some relatively flexible requests that led to less good caching.
mcpherrinm commented on Getting ready to issue IP address certificates community.letsencrypt.org... · Posted by u/Bogdanp
Lots of people on HN are not the target audience for any given post, yet are still interested.
(And my point applies to all writing and speaking, not just this post.)
If it was a blog post or announcement, we’d have surely included more context, and not a forum post really intended for limited distribution.
You just used HN without expanding that acronym! :)
I believe you only have to pay to put your app on the App Store. I’ve made apps for my iPhone before and never had to pay.
It's the "for longer than a week" bit - Unless you have a paid developer account, you can only sign apps to sideload that last one week.
There's some tools to automate "refreshing" the app, but that requires you have some other computer that pushes a new app every week.
The "1 week" restriction is usually fine when you're developing (as you typically are continually rebuilding and updating when actively working on an app) but is clearly intended to avoid being a way to sideload apps without the developer account "nearby".
mcpherrinm commented on Why SSL was renamed to TLS in late 90s (2014) tim.dierks.org/2014/05/se... · Posted by u/Bogdanp
No: while the handshake is unencrypted, it is authenticated. An attacker can’t modify it.
What an attacker can do is block handshakes with parameters they don’t like. Some clients would retry a new handshake with an older TLS version, because they’d take the silence to mean that the server has broken negotiation.
well, unless both client and server have sufficiently weak crypto enabled that an attacker can break it during the handshake.
Then you can MITM, force both sides to use the weak crypto, which can be broken, and you're in the middle. Also not really so relevant today.
mcpherrinm commented on Why SSL was renamed to TLS in late 90s (2014) tim.dierks.org/2014/05/se... · Posted by u/Bogdanp
Man in the middle interfering with TLS handshakes?
The handshake is unencrypted so you can modify the messages to make it look like the server only supports broken ciphers. Then the man in the middle can read all of the encrypted data because it was badly encrypted.
A surprising number of servers still support broken ciphers due to legacy uses or incompetence.
No: while the handshake is unencrypted, it is authenticated. An attacker can’t modify it.
What an attacker can do is block handshakes with parameters they don’t like. Some clients would retry a new handshake with an older TLS version, because they’d take the silence to mean that the server has broken negotiation.
mcpherrinm commented on Why SSL was renamed to TLS in late 90s (2014) tim.dierks.org/2014/05/se... · Posted by u/Bogdanp
If a protocol is widely used wrongly, I consider it a flaw in the protocol. But overall, SSL standardization has gone decently well. I always bring it up as a good example to contrast with XMPP as a bad example.
Well, my only real point is that it’s not the version negotiation in TLS that’s broken. It’s the workaround for intolerance of newer versions that had downgrade attacks.
Fortunately that’s all behind us now, and transitioning from 1.2 to 1.3 is going much smoother than 1.0 to 1.2 went.
mcpherrinm commented on Why SSL was renamed to TLS in late 90s (2014) tim.dierks.org/2014/05/se... · Posted by u/Bogdanp
Wait, but didn't TLS 1.0 have significant improvements over SSL 3.0? The article makes it seems that just a couple of things were tweaked just to make it different for the sake of being different.
The main difference is in the padding. When the POODLE attack was pre-announced as only affecting SSL3 and not TLS1.0, that was enough to predict it was going to be a padding oracle.
I think it’s fair to say they’re very similar, with a few “bug fixes”. It’s been a while since I’ve thought about either though, and might be forgetting a few things. I’ve only ever implemented SSL3 and TLS1.0 together, so there may be some details I’m forgetting.