3

I have a set of domain names that are used internally and I do not wish them to leak to the outside world (as that would give an attacker advanced knowledge of the layout of the internal network). Given Certificate Transparency seems like it is gaining momentum, what is the general consensus on the best way to have private domain names? Self signed certs? Wild card certs? Something else?

| improve this question | | | | |
  • 1
    Either, wildcard certificates or private PKI. – Crypt32 Feb 20 '18 at 16:49
12
+200

I have a set of domain names that are used internally

For internal only uses, you can set a private CA, install its certificate on internal systems, and issue internal certificates yourself.

If your internal use servers are somehow used externally, they will not work unless the external clients add an exception for your certificate. That will not stop external attackers from discovering the internal domains and attacking them. In this case, use a wildcard certificate. Using a self-signed or internal CA certificate will annoy the external users and do nothing to protect you against attackers (like most DRM schemas).

| improve this answer | | | | |
6

If leaking host names is part of your threat model, then CT is probably not the only source of such leakage. Think of email headers, logs, monitoring, compilers, .. lots of tools could eventually spill system names (whether host names or just part of certificates) into publicly accessible spaces. Rather, work on the underlying reasons for wanting them stay confidential.

You will not have to hide them if there is nothing secret about them. If they do reveal some information, that is usually because you are using the names to

  1. help admins navigate your own network or
  2. help coworkers to remember what URL to type.
  3. test a system internally before commercial operation

For all 3 problems, there are better solutions. The main problem of 1. is that system names usually end up not matching system roles after a number of changes. The main problem with 2. is that your coworkers should not ever by typing URLs by hand anyway - think of misspelled-domain type scams. Code names solve 3.

Recommendation: Name your internal servers with a consistent, but otherwise random scheme. Convey system <> role relationships through entirely different means. You usually do address your coworkers by their names, not by their roles - do that for your internal servers similarly.

Our internal wiki is hosted at lake.example.org. Lake doesnt mean anything, its just sufficiently different from cube.example.org (the log collection). But the evil attacker only knows there are 8 internal domains, which is not surprising for the size of the organization. If he wants to know more, he will have to come visit us & read the name tags.

| improve this answer | | | | |
  • That would still leak information an attacker could use to plan (number of machines and their names). – Chas. Owens Feb 21 '18 at 16:24
  • @Chas.Owens to some degree also work hours, timing of it upgrades etc. – anx Feb 23 '18 at 16:53
  • 1
    So you're saying I should rename the dont-forget-our-root-password-is-bacon123.example.com server? – ceejayoz Mar 19 '18 at 1:09
3

This seems like a pretty simple decision unless I'm missing something.

If you decide the privacy of the data that would be exposed via Certificate Transparency to be more valuable than the convenience of having certificates signed by a publicly trusted CA, you either:

  • Don't use certificates (unwise and unfeasible with modern software)

or

  • Run your own CA and deal with the inconvenience of setting up clients to trust it.
| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.