Gibt es eigentlich eine deutsche RootCA?

[darkside40]

Durch die Berichte über Prism und darüber das FBI etc. versuchen bei Firmen SSL Masterkeys zu erpressen, stellt sich für mich die Frage ob es überhaupt es eine deutsche RootCA gibt die auch unter die in Deutschland geltende Rechtssprechung fällt.

Das SSL System basiert ja ein Stück weit auf vertrauen. Ich muss der RootCA vertrauen das Sie für meine Domain keine weiteren Zertifikate signiert. Was für Auswirkungen so etwas haben kann hat man ja 2011 beim Diginotar Hack gesehen. Diginotar wurde gehackt, wer garantiert mir jedoch das ein Unternehmen in den USA nicht auf einen geheimen Gerichtsbeschluss hin ein Wildcard Zertifikat für eine beliebige Domain ausstellt?

Aus diesem Grund würde ich gerne ein SSL Zertifikat einer deutschen RootCA kaufen. Dabei bin ich zuerst auf die Deutsche Post gestoßen, die Verkaufen jedoch scheinbar nur Comodo Zertifikate weiter. Die Telekom wird zwar als RootCA z.B. bei Mozilla geführt jedoch konnte ich nirgendwo sehen ob man bei der Telekom auch Zertifikate kaufen kann.

Gibt es gar keine deutsche RootCA, oder habe ich Sie bloss noch nicht gefunden?

 

[Mr_J]

Ich würde denken, dass du noch nicht richtig gesucht hast. Es gibt z.B.:
- Die Telekom betreibt sowas z.B. unter telesec.de.
- Die Sparkasse unter s-trust.de
Man kann wahrscheinlich noch mehr finden wenn man einfach mal z.B. in Firefox durch die Zertifikatsliste blättert und schaut was da so an deutsch klingenden Namen auftaucht.

MfG
Mr. J

 

[darkside40]

Okay bei Telesec bin ich inzwischen fündig geworden, dort kostet ein SSL Zertifikat für ein Jahr schlappe 178,00€ inkl. Steuern.

Bei S-Trust muss man sich ein persönliches Angebot einholen, wobei die Mindestabnahmemenge bei 15 Zertifikaten liegt. Das ist für Privatpersonen doch eher unpraktikabel.
Wie man auch hier sieht: Sicherheit kostet.

--- Automatisch zusammengeführter Beitrag ---

So bin gerade mal die Liste der Root Zertifikate auf meinem Mac durchgegangen. Dort sind ja immerhin schon 181 installiert.

Also es gibt bei mir nur 2 Deutsche RootCA, einmal Telekom und als zweites TC Trustcenter. TC Trustcenter gehört inzwischen zu Symantec und fällt damit aus dem Raster.
S-Trust taucht auch nicht auf, also entweder sind diese auch nur Reseller oder man muss deren Root Zertifikat von Hand importieren, was das ganze sinnlos macht.

 

[KippaKong]

Hier ein Link zur Certchain von Telesec / ServerPass:
http://www.telesec.de/serverpass/support_rootca_akzeptanz.html
Zertifikate die nach dem 16.12.2010 bestellt wurden, haben Baltimore CyberTrust Root als RootCA.

Ich verstehe aber nicht, was genau dein Vorhaben wäre?
Der Master-Key um den SSL-Verkehr entschlüsseln zu können? Den hast du auf deinem Server.

Oder deine Befürchtung, dass jemand für deine Domain ein Zertifikat erstellt..?
Das müsste er dann auch auf deinem Server anwenden.
Wenn er einen eigenen Server mit deiner Domain betreibt, dann müsste er im DNS den A-Record ändern.

Das ist alles ziemlich weit hergeholt.
Ich sehe irgendwie nicht, dass eine deutsche RootCA dich davor bewahren könnte.

 

[darkside40]

Die Befürchtung wäre eher eine MitM Attacke mit einem gültigen auf meine Domain ausgestelltem Zertifikat.

 

[KippaKong]

Mal zu den Begrifflichkeiten:
Zu allererst gibt ja die Root CA nicht die Zertifikate aus. Die CA welche ein Zertifikat ausstellt, nennt man Issuing CA oder auch Intermediate CA oder noch einfacher Sub-CA genannt..
Um mal beim Beispiel Telekom zu bleiben, könnte die Sub-CA jetzt die Telesec sein. Root-CA ist die Baltimore CyberTrust.
Die Sub-CA erhält von der Root-CA ein entsprechendes CA-Zertifikat, was sie dazu befähigt eigene Zertifikate auszustellen.

Somit ist die Zertifikatskette vertrauenswürdig, sobald dein Client eben die Root-CA auch als vertrauenswürdig einstuft.

Nun zum Szenario:
Also mal angenommen, jemand möchte von deinem Webserver den Traffic abgreifen und lässt ein Zertifikat auf deinedomain.de ausstellen. Um das zu ermöglichen muss man im Normalfall bei der CA nachweisen, dass man auch Domaininhaber ist.
Da wir aber nicht vom Normalfall ausgehen, könnte es nun also sein, dass der "Angreifer" Zugang zu einer Sub-CA hat und damit jederzeit ein Zertifikat für jede beliebige Domain ausstellen kann.

Der HTTPS-Traffic ist ja vom Client getrieben. D.h. der Client versucht eine Verbindung zu deinem Webserver aufzubauen. Der Webbrowser startet den SSL-Handshake. Der Webserver im SSL-Handshake das Zertifikat...usw

Beim MitM schafft es der Angreifer "irgendwie" das dieser Verbindungsaufbau vom Client eben bei ihm "in the middle" terminiert wird. Beim SSL-Handshake sendet der Angreifer dann sein selbst erstelltes Zertifikat von deinedomain.de an den Client zurück.

Es ist also total unerheblich welche Root-CA oder sogar welche Sub-CA für die Ausstellung deines Zertifikats zuständig ist.
Clientseitig kann man das nur überprüfen, wenn man die Zertifizierungskette überprüft und wenn man den Fingerprint eines Zertifikats kennt. Nur welcher Client könnte das schon? Dazu müsste man ja vorher wissen, welche Werte zu erwarten sind.

Wie gesagt... das alles ist natürlich sehr weit geholt.. und alles mal rein funktionell betrachtet.
Die Verifizierung des Domaininhabers muss eine Issuing CA vornehmen. Wenn es also eine CA gibt, die da mal alle Augen zudrückt, sobald ein Geheimdienst anruft, dann ist alles möglich.

 

[darkside40]

Danke für die ausführlich Erklärung, ist ja eigentlich auch logisch, scheinbar habe ich das nur nicht ganz zuende gedacht.

Zusammenfassend kann man dann aber sagen, sobald es staatlichen Stellen gelingt irgendeine CA zu erpressen ist es vollkommen egal ob ich das 15€/Monat Zertifikat von Telsec oder ein 1,99€/Monat Zertifikat von irgend einer billig CA habe, das System SSL ist so oder so kaputt.

 

[Mr_J]

Die Frage ist ob jede CA den Private Key eines Zertifikats lagert oder nicht. Wenn dem nicht so wäre dann ließen sich zumindest einmal verschlüsselte Daten nicht mehr so leicht entschlüsseln.

MfG
Mr. J

 

[Kugelfisch]

Die Frage ist ob jede CA den Private Key eines Zertifikats lagert oder nicht.

Weshalb (und wie) sollte sie das bei für Kunden signierten X.509-Zertifikaten tun? Den privaten Schlüssel erfährt die CA gar nicht, sofern der Zertifizierungsprozess korrekt abläuft: Der Kunde generiert lokal ein Schlüsselpaar und erzeugt einen CSR (Certificate Signing Request) dafür, welcher den öffentlichen Schlüssel und einige Meta-Daten enthält. Diesen lässt er der CA zukommen, welche daraus das Zertifikat erzeugt und signiert. Der private Schlüssel verlässt niemals den Rechner des Kunden.

Abgesehen davon bedeutet ein kompromittierter Private Key nicht unbedingt, dass alle zuvor verschlüsselt übertragenen Daten entschlüsselt werden können, da der Session-Key über einen DH-Schlüsseltausch ausgehandelt werden kann. Siehe auch https://en.wikipedia.org/wiki/Transport_Layer_Security#Perfect_forward_secrecy.

 

[KippaKong]

Der private key sollte an keiner Stelle den Server verlassen.

Nehmen wir mal den Prozess der Zertifikatsbeauftragung bei der CA:
Als erstes erstellt man sich den private Key. Wie gesagt.. der liegt auf dem Server und wird nicht rausgegeben.
Passend zum private Key wird aber ein public Key erzeugt, welcher dann mit Informationen erweitert wird, für wen das Zertifikat gelten soll bzw. wessen Identität sichgergestellt werden soll. Diese Informationen fliessen in den CSR (Certificate Signing Request) ein.
Mit dem CSR geht man dann zur CA und lässt sich ein Zertifikat ausstellen.
Die CA verfifiziert die Identität des Antragsstellers (mehr oder weniger) und versieht den CSR mit einer Signatur (des CA-Zertifikats). Dies ist dann das Zertifikat, welches als CRT-File runtergeladen werden kann.

SSL-Handshake (vereinfacht dargestellt):
Der Client ruft im Browser die entsprechende URL auf https://deinedomain.de
Der Webserver sendet das Zertifikat, welches den public Key enthält zurück.
Der Client validiert das Zertifikat (z.B. ob es von einer vertrauenswürdigen CA ausgestellt wurde).
Dann sendet der Client wiederum einen "Session-Schlüssel", welcher mit dem public Key des Server verschlüsselt ist.
Der Server entschlüsselt diesen mit dem private Key.
Webbrowser und Webserver kennen nun den gemeinsamen "Session-Schlüssel".

Man sieht also, der private Key wird nur sehr selten angefasst. Das dann freilich an den entscheidenden Stellen.
Und da der private Key der Ursprung der ganzen Kette ist, ist er eben so wichtig.

Edit: Hehe, hab zu lange geschrieben.

 

[darkside40]

Auf jeden Fall vielen Dank an KippaKong und Kugelfisch für die ausführliche Erklärung. Ihr habt mich wieder mal ein bisschen schlauer gemacht.

 

[accC]

Die Zertifikate nutzt du doch eigentlich nur um zu Beweisen, dass du der bist, für den du dich ausgibst. Es gibt ein paar Leuten, denen du per default traust (kannst du im Browser einsehen), die wiederum sprechen Dritten ihr "Vertrauen" aus. Dadurch ergibt sich eine Chain-of-Trust: Wenn du dem Root traust und der Root traut einem Dritten, dann vertraust du auch dem Dritten. Das System funktioniert wunderbar, wenn der Dritte dir sonst nicht glaubhaft machen kann, dass er der ist, für den er sich ausgibt und natürlich nur sicher, wenn der Root wirklich kontrolliert, wem er da was zertifiziert. Es könnte ja (theoretisch) auch einen schlechten Root geben, der Evil vertraut und Evil ist aber nicht der, für den er sich ausgibt.
Ein solcher Fall ist bei soeren-hentzschel.at beschrieben.


Jedenfalls, wenn es nur um den privaten Einsatz geht, dann kannst du auch ein eigenes Zertifikat verwenden. Du weißt immerhin, dass du das zur Frage stehende Zertifikat ausgestellt hast und du kannst deinen Freunde mit Sicherheit glaubhaft machen, dass du der bist, für den du dich im RL ausgibst. In dem Moment, wo deine Freunde dir vertrauen, vertrauen sie auch deinem Zertifikat, dessen Gültigkeit du quasi bestätigst.

 

[darkside40]

Noch mal weil es so schön zum Thema passt: http://www.golem.de/news/kaspersky-...itime-zertifikate-ausstellen-1308-101036.html

 

[KippaKong]

Danke für den Link.

Jetzt haben wir doch erst festgestellt, dass der Private Key nicht den Server verlässt.
Und dennoch behauptet der Mitarbeiter von Kaspersky:

Rein technisch gesehen gibt es zwei Stellen, an welchen die Private Keys zur Kompromittierung für SSL-Verbindung abgegriffen werden können. Zum einen ist dies bei den Zertifizierungsstellen (Certificate Authorities) möglich, welche die digitalen Zertifikate ausstellt. [..]

Das würde mich jetzt aber doch genauer interessieren!
Weiter heisst es:

[..] Sollte eine solche Institution kollaborieren oder kompromittiert werden, wie etwa im Fall von Diginotar im Jahr 2011, könnten durch diese technisch legitime Zertifikate ausgestellt werden, welche für Man-In-The-Middle-Angriffe eingesetzt werden können.

Jep, so hatten wir es ja bereits dargestellt. Nur was hat der zweite Teil denn mit dem ersten Teil zu tun?

Weiter im Artikel heisst es:

Laut einem Bericht soll das System SSL durch seine langlebigen Master-Keys angreifbar sein: Diese Keys, die wie ein Generalschlüssel eines Anbieters arbeiten, sollen nämlich von US-Behörden bei den Providern eingefordert werden.

Diese "langlebigen Master-Keys" gibt es nicht.
Das einzige was die US-Behörden insteressieren könnte, wäre der private Key.
Dann soll die Presse aber nicht von Master Keys sprechen, um somit anzudeuten im SSL wäre ein grundsätzlicher Design-Fehler.

 

[Mr_J]

[...]Jetzt haben wir doch erst festgestellt, dass der Private Key nicht den Server verlässt.[...]

Ist das immer so? Ich kenne zumindest vom Studium her die Möglichkeit dass man ein Zertifikat beantragt und den Private Key per Post zugesendet bekommt.

MfG
Mr. J

 

[Kugelfisch]

Diese "langlebigen Master-Keys" gibt es nicht. Das einzige was die US-Behörden insteressieren könnte, wäre der private Key.

Korrekt. Mit der Aussage ist wohl gemeint, dass (wie in https://ngb.to/threads/1376-Gibt-es-eigentlich-eine-deutsche-RootCA?p=30417#post30417 ff. angedeutet) ein herausgegebener Master-Key bedeutet, dass man durch einen abhanden gekommenen Private-Key sämtliche vergangenen und zukünftigen TLS-Sitzungen entschlüsseln kann, sofern das Perfect-Forward-Security-Feature (PFS) nicht zum Einsatz kommt. Ohne PFS wird beim Handshake das Pre-Master-Secret, aus dem sich der Session-Key ergibt, nämlich direkt (verschlüsselt) übertragen. Bei PFS wird es zwischen Client und Server z.B. durch einen DH-Schlüsseltausch ausgehandelt.

Ist das immer so? Ich kenne zumindest vom Studium her die Möglichkeit dass man ein Zertifikat beantragt und den Private Key per Post zugesendet bekommt.

Das ist zumindest der übliche, in X.509 vorgesehene Weg zur Signierung eines Zertifikats. Ich kann natürlich nicht ausschliessen, dass einige CAs anbieten, selbst ein Schlüsselpaar zu erzeugen - davon sollte man jedoch aus genannten Gründen keinen Gebrauch machen.