Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
which is still there if you are not using lets encrypt, because they can strongarm them to make a fake cert for your domain, and install a proxy repackaging HTTPS traffic with the fake certificate. all browsers trust the lets encrypt root certificate, so they won't see anything suspicious.
the only thing there today to detect this (but not avoid) is certificate transparency logs. all modern certificates are required to be added to this log, for the CA to remain compliant. but browsers are not checking the logs, that would be a lot of additional traffic and how do they decide if a certificate was created maliciously? also, lets encrypt could afford being noncompliant, browser vendors can't realistically just distrust their root certificate, many sites would become inaccessible.
Oh snap! That definitely sounds possible. Found more info about it.
tl;dr: Either the attack is ineffective against some browsers that check the certificate transparency logs (like Chrome), or the attack is visible and the CA will lose all its credibility (hopefully being removed from the browsers).
it seems Firefox started doing the CT validation too, without needing to contact the CT log service: https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Certificate_Transparency#browser_requirements
and details: https://wiki.mozilla.org/SecurityEngineering/Certificate_Transparency
this sounds important:
this also means, it can't truly verify SCT's that were issued since the last browser update?
Maybe I'm mistaken but aren't the logs cryptography verifiable? (As in you can't create a rouge cert without it creating a trace)
apparently certs can have a cryptographic proof of having been included in the CT logs. but what do browsers do if the letsencrypt cert has no such proof?
You can test that on this site:
https://no-sct.badssl.com/