- cross-posted to:
- technology@beehaw.org
- cross-posted to:
- technology@beehaw.org
cross-posted from: https://lemmy.ml/post/14100831
"No, seriously. All those things Google couldn’t find anymore? Top of the search pile. Queries that generated pages of spam in Google results? Fucking pristine on Kagi – the right answers, over and ov
Free certificates expose your subdomains. It’s not more secure if you don’t transact data in a meaningful way such as the example I provided.
I don’t mean to insinuate that the example I provided is the majority of cases, and in the majority of cases, I do support sites with SSLs being indexed higher than websites without them, but I think the interstitial this website is not secure with the requirement of the advanced click followed by The continue anywaysclick…
Idk
Especially in 2018. Like, when we look at it from today’s perspective, it’s very easy to agree. And I do agree. But in 2018, it was not this way. Anyone who was a web developer with a bunch of clients, such as myself, was all the sudden in a very interesting hot seat. Not only did I need to try to upsell my clients, but I needed to convince them that not doing so was quite literally at their peril. It was difficult. And certain cases, it was impossible.
Expose your subdomains as in having all of them bundled into one certificate?
AFAIK, you absolutely can request different certs for each subdomain (in fact, that’s what I’ve been doing for a while).
No, as in they are public record.
If you use a wildcard let’s encrypt SSL to encrypt www.mydomain.com and VPS.mydomain.com and secret.mydomain.com and allmyporn.mydomain.com, and Plex.mydomain.com, and gitlab.mydomain.com
Then it is public record that mydomain.com has associated with it the CNAMES “www” “VPS” “secret” “allmyporn” “Plex” and “gitlab”.
It can be looked up by anyone here. Just type in “%.yourdomain”
That is to say if you use a wildcard letsencrypt SSL on all your subdomains for you self hosting project, you’re more exposed than want to be.
If your subdomains being public is a security issue then I’d argue something else is wrong. Otherwise you’re using security through obscurity.
But I appreciate the insight and I see how this was a harder sell back when it happened. Thanks!
Not necessarily. Let’s say you’re a known contributor to a closed source project. You don’t want people knowing you have a locally hosted gitlab instance at gitlab.mydomain.com, for example.
If that’s the case, you shouldn’t have one on your domain. If someone wants to know your subdomains, they can still brute force them