Eine Klarstellung zu CAA
Die Firma Qualys bietet einen populären SSLTest an. Leider scheinen sie in letzter Zeit einen Fehlgriff getan zu haben, indem sie die CAA Tests einführten. Das Problem ist, dass CAA etwas völlig anderes tut, als die Betreiber annehmen.
Warum CAA?
CAA wurde im RFC 6844 standardisiert und vom CA Forum ab 8. September als verpflichtend vereinbart.
Es geht um folgendes (aus dem RFC)
The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain. Publication of CAA Resource Records allows a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue.
Der Webseitenbetreiber kann also im DNS seiner Webseitenzone angeben, welche CA für den Server Zertifikate ausstellen darf.
Der RFC stellt nochmal explizit klar:
Like the TLSA record defined in DNS-Based Authentication of Named Entities (DANE) [RFC6698], CAA records are used as a part of a mechanism for checking PKIX certificate data. The distinction between the two specifications is that CAA records specify an authorization control to be performed by a certificate issuer before issue of a certificate and TLSA records specify a verification control to be performed by a relying party after the certificate is issued.
Die Zielgruppe des CAA Records ist also die CA, die bei der Zertifikatserstellung prüfen kann, ob der Betreiber sich auch an diese CA wenden wollte. Der Gedanke dabei ist, dass eine CA erkennen kann, dass sie von einem Angreifer für eine fehlerhafte Zertifikatserstellung missbraucht wird.
Die Zielgruppe von TLSA Records dagegen sind die Browser, die bei der Zertifikatsvalidierung prüfen können, ob das beim Verbindungsaufbau präsentierte Zertifikat vom echten Webseitenbetreiber stammt. Der Gedanke dabei ist, dass ein Browser erkennen kann, ob ihm ein falsches Zertifikat unter geschoben werden soll.
Wie deutlich der CAA Record auf den Betrieb einer CA ausgerichtet ist, sieht man daran, dass die Autoren von Comodo (einer CA) stammen und als Beispiel angeben, welche Nutzerkennung im Commodo-Portal für die Zertifikatserstellung benutzt werden darf (aus dem RFC):
example.com. CAA 0 issue "ca.example.net; account=230123"
Böse formuliert kann man den CAA Record als Abwehrmechanismus von Comodo verstehen, wenn wieder mal fälschlich Zertifikate ausgestellt wurden. Die CA könnte dann darauf verweisen, dass der Webseitenbetreiber ja angeben hätte können, dass diese CA gar nicht für ihn arbeiten darf.
Woher bekommt man nun so einen CAA Eintrag, wenn man einen braucht?
- Auf der Webseite von SSLmate kann man sich die Records erzeugen.
- Den notwendigen Issuer-String kann man bei einer inoffiziellen Registry nachschlagen.
Interessant ist dabei, welche Issuer-Strings die CAs so anerkennen. Symantec ist es beispielsweise egal, welcher Reseller zum Zuge kommt. Es ist also nicht möglich, "thawte.com" anzugeben und so GeoTrust auszuschließen.
Ebenso interessant ist, dass der RFC vermeidet, der IANA die Pflege der Issuer-Strings aufzuerlegen. Dabei wäre das echt nützlich gewesen. Die referenzierte Registry hat lustigerweise ein "fork me on Gitlab" Banner in der Ecke.
Was SSLabs tut
Zunächst mal hat Qualsys auf die Ankündigung des CA-Forums reagiert, und prüft auf die Existenz des Eintrags. Ist der Eintrag vorhanden, gibt es Zusatzpunkte für einen A+ Status. Das hebt die Motivation natürlich.
Also schauen wir mal. Eintrag vornehmen und testen:
Ist das nicht cool? Das Zertifikat stammt von Symantec, und der Test befindet den CAA Eintrag für gut.
Aber kann er überhaupt einen Eintrag testen, der gar nicht für die Verwendung in einem Browser vorgesehen ist? Schließlich hat der Test ja keinen Zugriff auf die Validierungslogik der CAs.
Also testen wir auch das.
Wie bitte? Ein ganz offensichtlicher Widerspruch wird mit Zusatzpunkten bewertet?
Wenn man versteht, dass CAA ausschließlich für die CAs da ist, ist das keine Überraschung. Vielleicht soll ja auch das nächste Zertifikat von einer anderen CA ausgestellt werden? Der Betreiber der Webseite benutzt halt nur noch das noch gültige alte Zertifikat weiter. Gründe kann es vieles geben.
Im Kern fällt es auf die Aussage zurück, dass der Zeitpunkt der Auswertung des CAA Records bei der Zertifkatserstellung wichtig ist. Dieser Zeitpunkt unterscheidet sich erheblich von dem der Zertifikatsvalidierung!
Noch viel witziger sind die Ausschlusskriterien für die Verwendung von CAA:
-
Wenn der CAA Test schon zweimal in der Vergangenheit erfolgreich war und das im Certifcate Transparency Log steht.
Ich darf also die CA nicht wechseln? -
Wenn die ausstellende Sub-CA dies in ihren Verträgen ausschließt.
Diese Sub-CAs waren bisher schon immer eine Quelle von Fehlern. -
Wenn die CA auch Betreiber des DNS ist.
Die Großen schauen also weg. -
Wenn die DNS Abfrage fehlschlägt aus Gründen, die nicht die CA zu verantworten hat, die Anfrage aber wenigsten einmal versucht wurde und die Zone nicht komplett bis zur Wurzel DNSSEC validierbar ist.
Also immer.
Ehrlich gesagt ist das ein Frechheit.
Und nun?
Wer auch immer einen Draht zu Qualys SSLabs hat, er möge den Leuten dort auf die Füße treten:
- Entfernt die CAA Prüfung!
- Prüft TLSA!