6 ms·
SAN isn't a practical solution for cases where you don't want to expose which subdomains exist, or where you allocate them dynamically.
by Nullabillity 10y ago
SAN isn't a practical solution for cases where you don't want to expose which subdomains exist, or where you allocate them dynamically.
- icebraining 10y agoA good example is the Sandstorm platform, which fits both cases.
- aroch 10y agoUnless 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.
- kentonv 10y agoWell 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/#why-sandstorm-needs-wildcard-dns https://docs.sandstorm.io/en/latest/administering/wildcard/#...
- aroch 10y agoThat doesn't prevent domain enumeration for your application though. Once you publish an application, anyone using it can find the address its hosted behind
- icebraining 10y ago> 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.
- aroch 10y agoAt which point we're back to my original point of why does the information disclosure matter?
- kentonv 10y agoDefense-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.
- kentonv 10y agoIt'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.
- collinmanderson 10y agoIsn't that insecure because hostnames are sent in the clear? (both in TLS handshake and DNS lookup?)
- icebraining 10y agoThe 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/#why-a-new-hostname-for-every-session-rather-than-for-every-document https://docs.sandstorm.io/en/latest/administering/wildcard/#...
- kentonv 10y agoRight, 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.
- Jweb_Guru 10y agoIf it doesn't count as secure unless there's perfect information transparency, most of cryptography is based on "security through obscurity."
- deleted 10y ago[deleted]
- LinuxBender 10y agoI 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.
- deleted 10y ago[deleted]
- devy 10y agoWildcard certificates have significant constraints of single level of the subdomain matching and security risks[1], putting side the debate of the real benefits of "not exposing subdomains". [1]: https://tools.ietf.org/html/rfc6125#section-7.2 https://tools.ietf.org/html/rfc6125#section-7.2