Hacker News Reader

Comment by aroch | Hacker News Reader

Unless all your subdomains are unique (e.g. coming out of a PRNG) AND there are no public DNS entries for them, subdomain enumeration by DNS or IP space is super easy. Not using SAN because of info disclosure concerns is security through obscurity.

View on HN

Well yes, that's the idea: Say you have a wildcard DNS entry and you cryptographically-randomly-generate hostnames in it, as an added layer of defense against CSRF bugs in the applications running on these hosts.

https://docs.sandstorm.io/en/latest/administering/wildcard/#...

That doesn't prevent domain enumeration for your application though. Once you publish an application, anyone using it can find the address its hosted behind

> publish

Sandstorm is a platform for personal computing; each person runs their own applications, much like in a PC. Also, applications don't get hostnames; each document (or equivalent) in the application gets its own hostname.

It's even finer-grained than that. Each session gets a hostname -- if you open the same document twice, it's at a different hostname each time. This also implies that different users get different hostnames, so you can't discover the host another user sees even if you have access to the same document.

Isn't that insecure because hostnames are sent in the clear? (both in TLS handshake and DNS lookup?)

The hostnames aren't authentication, just another layer of defense, mostly against JavaScript attacks (e.g. from hacked applications): https://docs.sandstorm.io/en/latest/administering/wildcard/#...

Right, this is about mitigating the damage when apps have a bug -- risk management. Instead of being exploitable from anywhere on the internet, the bug becomes exploitable only by attackers who have a passive network MITM, which, while possible, is a very high barrier.

For such applications, there are plenty of relatively inexpensive paid options for wildcard certs. I don't think this is something Let's Encrypt should solve. I'd rather see them invest more time into supporting dynamic dns provider domains better, which imho is a much larger issue for small/hobby/free projects.

I'm ready to pay a reasonable amount for a wildcard cert to use with some hobby projects. Is there a trustworthy cheap wildcard cert provider which is not Comodo?

Have you checked StartSSL? They've worked fine for me.

What's the problem with dynamic dns provider domains?

I mean domains on no-ip, freedns, dyndns and the like.. that are subdomains are more likely to hit the default limits with Let's Encrypt... I'd like to see some auto-whitelisting for some of the more popular ones.

I thought sandstorm was a self-hosted thing. Why do the certs need to be signed by a public CA at all? A self-signed certificate is fine (and in some ways better than a public CA) when you can verify the source yourself because you generated it.

Sure, you can use a self-signed cert, if you don't mind going through the process of installing the cert into every browser that you'll use to access the server.

But Sandstorm is designed for sharing and collaboration. For example, you might write a document in Etherpad which you want other people to comment on. It may be tough to get the right certificate into all your friends' and family's browsers.

(Note that Sandstorm actually provides free wildcard certificates if you are OK with using a subdomain of sandcats.io.)

At which point we're back to my original point of why does the information disclosure matter?

Defense-in-depth against CSRF attacks, which are still way too common. Sandstorm can't security-review the apps for you but it can mitigate most vulnerabilities.

I would like to add that security through obscurity is not bad when it used as layers in the security cake. Delicious red velvet cake with cool fluffy chocolate frosting and a side of ice cream.

If it doesn't count as secure unless there's perfect information transparency, most of cryptography is based on "security through obscurity."

Reply on news.ycombinator.com