GOpenCDR-Sicherheits- und Offenlegungsrichtlinie

Wie diese Richtlinie zu der von Gelhaus Solutions steht

GOpenCDR fällt unter die Richtlinie zur Offenlegung von Schwachstellen von Gelhaus Solutions, und alles darin gilt auch hier: wie Sie melden, die Reaktionszeiten, der sichere Hafen, Nennung und Kennungen. Diese Seite ergänzt, was für einen Namensraum besonders ist: was abgedeckt ist, was am meisten zählt und was ein Test nie tun darf, denn eine Root und ihre Resolver dienen Menschen, die nie zugestimmt haben, Teil eines Tests zu sein.

GOpenCDR gehört zum Geltungsbereich des CVE-Numbering-Authority-Programms von Gelhaus Solutions, und Kennungen werden vergeben, wie es die Offenlegungsrichtlinie beschreibt.

Wie Sie melden

Schreiben Sie an egelhaus@ennogelhaus.de oder reichen Sie die Meldung über GAdvisory ein. Beide Wege erreichen dieselbe Person und setzen dasselbe Verfahren in Gang. Verschlüsseln Sie alles Heikle mit dem Schlüssel, der für ennogelhaus.de über WKD veröffentlicht ist; sein Fingerabdruck steht in der Offenlegungsrichtlinie. Bitte eröffnen Sie kein öffentliches Issue.

Schreiben Sie „GOpenCDR“ in den Betreff und zusätzlich „dringend“, wenn die Meldung Schlüsselmaterial, die Root oder die IANA-Regel betrifft. Solche Meldungen werden zuerst gelesen.

Die security.txt von GOpenCDR unter https://cdr.gplatform.org/.well-known/security.txt verweist auf diese Seite, ebenso die Fußzeile jeder GOpenCDR-Seite.

Was abgedeckt ist

• Das Portal, die API und RDAP unter cdr.gplatform.org.
• Die DNS-Ebene: der Signierer, die Erzeugung und Veröffentlichung der Zonen, unsere autoritativen Server, der Mirror-Agent, der Prober und gocdrctl.
• Das Transparenzlog, seine Prüfpunkte und die Werkzeuge, die sie prüfen.
• Der öffentliche Resolver, den wir betreiben, dns.cdr.gplatform.org.
• Die Veröffentlichung von Vertrauensankern und Ankerpaketen.
• Die Browsererweiterung und die Desktop- und Mobil-Clients.
• Die GOpenCDR-Zertifizierungsstelle und ihr Certificate-Transparency-Log.

Worüber wir am liebsten hören

1. Alles, was einen Resolver, der GOpenCDR folgt, für einen Namen antworten lassen könnte, der in der IANA-Root existiert, oder was eine der drei Ebenen schwächt, die diese Regel durchsetzen: die Prüfschranke der Root, die Sperrliste und den Mirror-Agenten.
2. Jeden Weg, eine Signatur anders als über den vorgesehenen Pfad des Signierers zu erhalten, einen Schlüssel auszulesen oder zu exportieren oder den Signierer etwas signieren zu lassen, das die Prüfschranke hätte ablehnen müssen.
3. Jeden Weg, eine Änderung an der Root ohne die nötige Freigabe durchzubringen, einen eigenen Antrag selbst freizugeben oder die 24-stündige Wartezeit einer allein erteilten Freigabe zu überspringen.
4. Jeden Weg, das Transparenzlog unterschiedlichen Menschen unterschiedliche Geschichten zeigen zu lassen oder eine Prüfung einen Eintrag oder Prüfpunkt annehmen zu lassen, den sie ablehnen müsste.
5. Jeden Weg, eine Zone auszuliefern, die ihre ZONEMD- oder DNSSEC-Prüfung nicht besteht, oder einen Mirror eine solche annehmen zu lassen.
6. Jeden Weg, sich als Mirror-Agent auszugeben, eine seiner signierten Anfragen zu wiederholen oder ohne Anmeldung an TLD-Zonendateien zu gelangen.
7. Registrantendaten, die offenliegen, wo RDAP sie schwärzen sollte, und jeden Weg in das Konto eines anderen.
8. Jedes Zertifikat der GOpenCDR-Zertifizierungsstelle für einen Namen außerhalb ihrer Namensbeschränkungen und jeden Weg um diese herum.

Regeln für Tests

Der Namensraum dient Menschen, die nie zugestimmt haben, dass an ihnen getestet wird. Deshalb gelten hier eigene Regeln, zusätzlich zu denen der Offenlegungsrichtlinie.

• Testen Sie an Ihrem eigenen Konto, Ihren eigenen Namen und Ihrem eigenen Mirror. Für die Test-TLD gelhaus bitten Sie um eine Einladung zum Testen.
• Keine Dienstverweigerung. Führen Sie keine Lasttests durch, fluten Sie nichts und versuchen Sie nicht, unsere Resolver, unsere autoritativen Server, die API oder das Portal zu erschöpfen, und verwenden Sie keinen davon, um Datenverkehr gegen irgendwen zu reflektieren oder zu verstärken.
• Vergiften Sie keine Caches und kapern Sie keine Namen in Resolvern, die Sie nicht selbst betreiben, unsere eingeschlossen.
• Testen Sie nicht die IANA-Root, andere Namensräume oder Infrastruktur von TLD- oder Mirror-Betreibern ohne deren Erlaubnis.
• Greifen Sie nur auf das zu, was Sie brauchen, um das Problem zu zeigen. Erreichen Sie Daten anderer, hören Sie auf, behalten Sie nichts davon und sagen Sie es uns.
• Kein Social Engineering gegenüber unseren Mitarbeitenden oder Betreibern, keine physischen Angriffe und nichts, was auf unsere eigene Hardware zielt, einschließlich des Schlüsselspeichers und des Netzes dahinter.
• Behalten Sie die Einzelheiten bis zum abgestimmten Termin für sich.

Forschung innerhalb dieser Regeln ist willkommen, und der sichere Hafen der Offenlegungsrichtlinie deckt sie ab.

Was nicht abgedeckt ist

• Befunde in Software Dritter, die wir unverändert betreiben, etwa Knot DNS, NSD, Unbound, dnsdist, HashiCorp Vault, Temporal oder NATS. Melden Sie diese dem jeweiligen Projekt; wir helfen dabei und spielen die Korrektur ein.
• Schwächen des DNS-Protokolls selbst ohne Auswirkung, die GOpenCDR besonders betrifft.
• Die IANA-Root, OpenNIC und Handshake.
• Befunde, die ein bereits kompromittiertes Gerät, administrativen Zugang zu einem fremden Mirror oder ein Opfer voraussetzen, das etwas Ungewöhnliches installiert, es sei denn, GOpenCDR verschlimmert sie.
• Ausgaben automatischer Scanner ohne nachgewiesene Auswirkung, fehlende Header ohne Auswirkung und Ratenbegrenzungen, die wie beschrieben funktionieren.
• Missbrauch unter einem GOpenCDR-Namen, etwa Phishing; dafür gilt der Meldeweg in der Richtlinie zur zulässigen Nutzung.

Wenn ein Schlüssel kompromittiert sein könnte

Wenn Sie glauben, dass ein Signierschlüssel, ein Vertrauensanker oder der Schlüssel des Transparenzlogs offengelegt sein könnte, schreiben Sie sofort, mit „Key“ im Betreff. Tier 0 kann nach seinem Notfallverfahren sofort handeln, das nur aussetzen oder verschärfen darf, nie lockern. Jede Notfallmaßnahme wird im Transparenzlog veröffentlicht und nachträglich überprüft.

Probleme, die keine Schwachstellen sind

Ein Auflösungsfehler, eine falsche Antwort oder eine bald ablaufende Signatur ist nicht immer eine Schwachstelle, aber wir wollen ebenso schnell davon hören. Schreiben Sie an dieselbe Adresse.