Wie geht man mit Domänen um, deren Namen durch Zertifikatstransparenz nicht veröffentlicht werden sollen?

Question

Ich habe eine Reihe von Domänennamen, die intern verwendet werden, und ich möchte nicht, dass diese nach außen gelangen (da dies einem Angreifer umfassende Kenntnisse über den Aufbau des internen Netzwerks verschaffen würde). AngesichtsZertifikatstransparenzes scheint, als würde es an Dynamik gewinnen. Was ist der allgemeine Konsens über die beste Möglichkeit, private Domänennamen zu haben? Selbst signierte Zertifikate? Wildcard-Zertifikate? Etwas anderes?

Answer 1

Ich habe eine Reihe von Domänennamen, die intern verwendet werden

Für ausschließlich interne Zwecke können Sie eine private Zertifizierungsstelle einrichten, deren Zertifikat auf internen Systemen installieren und selbst interne Zertifikate ausstellen.

Wenn deininterne BenutzungServer werden irgendwie extern verwendet, sie funktionieren nicht, es sei denn, die externen Clients fügen eine Ausnahme für Ihr Zertifikat hinzu. Das wird externe Angreifer nicht davon abhalten, die internen Domänen zu entdecken und anzugreifen. Verwenden Sie in diesem Fall ein Platzhalterzertifikat. Die Verwendung eines selbstsignierten oder internen CA-Zertifikats wird die externen Benutzer verärgern und Sie nicht vor Angreifern schützen (wie die meisten DRM-Schemata).

Answer 2

Wenn das Durchsickern von Hostnamen Teil Ihres Bedrohungsmodells ist, ist CT wahrscheinlich nicht die einzige Quelle für ein solches Durchsickern. Denken Sie an E-Mail-Header, Protokolle, Überwachung, Compiler usw. Viele Tools könnten Systemnamen (ob Hostnamen oder nur Teile von Zertifikaten) irgendwann in öffentlich zugängliche Bereiche weitergeben. Arbeiten Sie stattdessen an den zugrunde liegenden Gründen, warum diese vertraulich bleiben sollen.

Sie müssen sie nicht verstecken, wenn nichts Geheimnisvolles an ihnen ist. Wenn sie Informationen preisgeben, liegt das normalerweise daran, dass Sie die Namen verwenden, um

1. helfen Administratoren bei der Navigation in Ihrem eigenen Netzwerk oder
2. Helfen Sie Ihren Kollegen, sich zu merken, welche URL sie eingeben müssen.
3. ein System vor dem kommerziellen Betrieb intern testen

Für alle 3 Probleme gibt es bessere Lösungen. Das Hauptproblem bei 1. ist, dass Systemnamen nach einer Reihe von Änderungen normalerweise nicht mehr mit den Systemrollen übereinstimmen. Das Hauptproblem bei 2. ist, dass Ihre Mitarbeiter URLs ohnehin nie von Hand eingeben sollten – denken Sie an Betrügereien mit falsch geschriebenen Domänen. Codenamen lösen 3.

Empfehlung: Benennen Sie Ihre internen Server nach einem konsistenten, ansonsten aber zufälligen Schema.Vermitteln Sie System <> Rollenbeziehungen auf ganz andere Weise. Normalerweise sprechen Sie Ihre Mitarbeiter mit Namen an, nicht mit ihren Rollen – tun Sie das auch für Ihre internen Server.

Unser internes Wiki wird unter gehostet lake.example.org. Lake bedeutet nichts, es unterscheidet sich nur ausreichend von cube.example.org(der Protokollsammlung). Der böse Angreifer weiß jedoch nur, dass es 8 interne Domänen gibt, was angesichts der Größe der Organisation nicht überraschend ist. Wenn er mehr wissen möchte, muss er uns besuchen und die Namensschilder lesen.

Answer 3

Sofern ich nichts übersehen habe, scheint dies eine ziemlich einfache Entscheidung zu sein.

Wenn Sie der Meinung sind, dass Ihnen der Schutz der Daten, die über Certificate Transparency offengelegt werden, wichtiger ist als der Komfort von Zertifikaten, die von einer öffentlich vertrauenswürdigen Zertifizierungsstelle signiert wurden, haben Sie folgende Möglichkeiten:

• Keine Zertifikate verwenden (unklug und mit moderner Software nicht durchführbar)

oder

• Betreiben Sie Ihre eigene Zertifizierungsstelle und bewältigen Sie die Unannehmlichkeiten, die damit verbunden sind, Clients so einzurichten, dass sie dieser vertrauen.