5 ms·

I hide mine behind letsencrypt, just dont put nextcloud.yourdomain.com but put it under a path like yourdomain.com/shortPhrase/nextcloud where shortPhrase is so

by antocv 7y ago

I hide mine behind letsencrypt, just dont put nextcloud.yourdomain.com but put it under a path like yourdomain.com/shortPhrase/nextcloud where shortPhrase is something like noway pizde and so on. Then dont share your links publicly.

organsnyder 7y ago
How does Let's Encrypt "hide" anything? Quite the contrary—the list of certs granted is publicly available (as it is for all CAs, I believe).
- jamespo 7y ago
  Get a wildcard
- Xylakant 7y ago
  TLS hides the path from a potential attacker that could observe traffic. Putting your nextcloud instance on a nonstandard path might help in this case, but - if I read the issue correctly - not in this cases
  - labawi 7y ago
    I haven't studied the issue, but it requires to access/execute php, no? If configuration requires a path to get further than a canned reply from nginx (403, 404, static page..), then it should reduce attack surface a lot. You should not be able to get anywhere near php without the path.
    - antocv 7y ago
      Exactly.
- gsich 7y ago
  Or use a wildcard cert.
- antocv 7y ago
  Lets Encrypt does not per se, but TLS does is what I mean with letsencrypt, thats why I said dont put a domain name for your nextcloud instance - because even if you get a wildcard cert, the domain names are public, and every lookup you do of your subdomain is visible to all ISPs, so even if you call it zyrkon.yourdomain.com someone can still attempt to make requests to it like /index.php?a Put your services, on a shared domain name, only yourdomain.com and under a sub-path, like yourdomain.com/thisISAlmostLikeaPassword/nextcloud the subpath is hidden by TLS, unless you make it public by posting it on the internet. And also if you arent careful, like using google "auto-suggest" or just using any Google products, then they will at least know about your path.
  - teddyh 7y ago
    > thisISAlmostLikeaPassword Why not just add real HTTP authentication to the site instead? One should always be wary of password-like mechanisms like secret paths, secret ports, etc. since none of these things are made to be secret, and could be disclosed by something unforeseen. (Paths, for instance, are saved in your browser history/cache, your HTTP caching proxy, if any, and also in the server’s access logs.)
    - antocv 7y ago
      Of course the site has its normal login/password, for example nextcloud has authentication. But you see, for what we are discussing here, you could have exploited it even without authenticating, and especially it would have been easier for scanners to find it and exploit, if it was on its own domain. Defense in depth. For some services, yes I do basic http auth, besides their own shitty auth.
  - heavyset_go 7y ago
    If you're worried about your ISP or people snooping on your traffic, then this scheme can be trivially defeated with a downgrade attack or looking at your address bar.
    - antocv 7y ago

by antocv 7y ago

organsnyder 7y ago

How does Let's Encrypt "hide" anything? Quite the contrary—the list of certs granted is publicly available (as it is for all CAs, I believe).

jamespo 7y ago
Get a wildcard
Xylakant 7y ago
TLS hides the path from a potential attacker that could observe traffic. Putting your nextcloud instance on a nonstandard path might help in this case, but - if I read the issue correctly - not in this cases
- labawi 7y ago
  I haven't studied the issue, but it requires to access/execute php, no? If configuration requires a path to get further than a canned reply from nginx (403, 404, static page..), then it should reduce attack surface a lot. You should not be able to get anywhere near php without the path.
  - antocv 7y ago
    Exactly.
gsich 7y ago
Or use a wildcard cert.
antocv 7y ago
Lets Encrypt does not per se, but TLS does is what I mean with letsencrypt, thats why I said dont put a domain name for your nextcloud instance - because even if you get a wildcard cert, the domain names are public, and every lookup you do of your subdomain is visible to all ISPs, so even if you call it zyrkon.yourdomain.com someone can still attempt to make requests to it like /index.php?a Put your services, on a shared domain name, only yourdomain.com and under a sub-path, like yourdomain.com/thisISAlmostLikeaPassword/nextcloud the subpath is hidden by TLS, unless you make it public by posting it on the internet. And also if you arent careful, like using google "auto-suggest" or just using any Google products, then they will at least know about your path.
- teddyh 7y ago
  > thisISAlmostLikeaPassword Why not just add real HTTP authentication to the site instead? One should always be wary of password-like mechanisms like secret paths, secret ports, etc. since none of these things are made to be secret, and could be disclosed by something unforeseen. (Paths, for instance, are saved in your browser history/cache, your HTTP caching proxy, if any, and also in the server’s access logs.)
  - antocv 7y ago
    Of course the site has its normal login/password, for example nextcloud has authentication. But you see, for what we are discussing here, you could have exploited it even without authenticating, and especially it would have been easier for scanners to find it and exploit, if it was on its own domain. Defense in depth. For some services, yes I do basic http auth, besides their own shitty auth.
- heavyset_go 7y ago
  If you're worried about your ISP or people snooping on your traffic, then this scheme can be trivially defeated with a downgrade attack or looking at your address bar.
  - antocv 7y ago