Sicherheit des InternetsZertifizierungsstelle könnte Hintertür für US-Geheimdienst öffnen

Chrome, Safari und Firefox vertrauen den Zertifikaten von TrustCor Systems. Laut einem Bericht hat das Unternehmen jedoch Beziehungen zur US-Regierung und zu einem Spyware-Hersteller. Das könnte die Sicherheit von Webseitenaufrufen massiv gefährden.

Links sind die Firefox- Safari und Chrome-App zu sehen. Im Hintergrund sind Ketten abgebildet.
Die Zertifikate stellen einen wichtigen Baustein für die Sicherheit im Internet dar. (Symboldbild) – Apps: IMAGO / ZUMA Wire; Ketten: IMAGO / Imaginechina-Tuchong; Montage: netzpolitik.org

Recherchen der Washington Post haben Zweifel an einem Unternehmen aufgeworfen, dass sicherheitskritische Zertifikate an Webseiten vergibt, um deren Vertrauenswürdigkeit nachzuweisen. Dem betroffenen Unternehmen TrustCor Systems vertrauen unter anderem die Browser Google Chrome, Safari und Firefox. Der Bericht legt nun unter anderem nahe, dass TrustCor Systems Beziehungen zu Vertragspartnern der US-Geheimdienste und zu einem Hersteller von Überwachungssoftware unterhält.

Wer eine Website im Browser aufruft, setzt dabei aufwändige Verschlüsselungsprozesse in Gang. Diese wiederum benötigen sogenannte TLS-Zertifikate, welche häufig von Drittunternehmen an Websites vergeben werden. Ihnen kommt damit eine kritische Rolle in der Sicherheit des Internets zu, denn sie signalisieren den Browsern, dass eine Website vertrauenswürdig ist. Missbrauch könnte dann zum Beispiel so aussehen, dass das Unternehmen Zertifikate an eine Website vergibt, die sich fälschlicherweise als Online-Banking-Portal einer Sparkasse ausgibt.

Fragwürdige Beziehungen

TrustCor Systems ist durch seine besondere Stellung als Root-Zertifizierungsstelle sogar in der Lage, andere Stellen zur Vergabe von Zertifikaten zu authorisieren und soll bereits an etwa 10.000 Webseiten Zertifikate vergeben haben. Das ist zunächst nichts Ungewöhnliches. Ungewöhnlich ist jedoch, dass das Unternehmen offenbar in Panama registriert ist und laut Bericht der Washington Post eine „identische Liste von Beamten, Bevollmächtigten und Partnern“ aufweist wie ein anderes Unternehmen, das Überwachungssoftware herstellt: Measurement Systems.

Das Spyware-Unternehmen fiel in der Vergangenheit dadurch auf, dass es Entwickler:innen dafür bezahlte, Überwachungscode in ihre Apps zu integrieren. Die betroffenen Apps, die um Funktionen zur Weitergabe von Telefonnummern, Email-Adressen und GPS-Daten modifiziert wurden, wurden nach Schätzung von Sicherheitsforscher:innen mehr als 60 Millionen Mal heruntergeladen. Measurement Systems wiederum gehört laut Bericht zu einem Anbieter von Abhördiensten aus Arizona namens Packet Forensics, der seit mehr als einem Jahrzehnt die US-Regierung beliefert.

Dafür, dass TrustCor tatsächlich die Zertifikatsvergabe missbraucht hätte, gibt es bislang keine Beweise. Wissenschaftler:innen zweier Universitäten, auf deren Forschung sich der Beitrag stützt, halten es aber durchaus für denkbar, dass das System gegen einzelne, besonders wichtige Ziele und über kurze Zeiträume eingesetzt werde. Laut einer anonymen Quelle mit Verbindungen zu Packet Forensics sei genau das bereit geschehen: Packet Forensics habe demnach den Zertifizierungsprozess von TrustCor genutzt, um Kommunikation für die US-Regierung abzufangen.

Unternehmen kann verschlüsselte Mails mitlesen

TrustCor bietet auch den Email-Dienst MsgSafe.io an, der vom Unternehmen als Ende-zu-Ende verschlüsselt beworben wird. Die Wissenschaftler:innen warnten jedoch, dass das Unternehmen die Mails lesen könne. Für eine echte Ende-zu-Ende Verschlüsselung müssten allein Nutzer:innen des Dienstes über die privaten Schlüssel verfügen, TrustCor generiere und verwalte die privaten Schlüssel jedoch selbst. Außerdem habe TrustCor in einer Testversion den Spyware-Code von Measurement Systems integriert, ein weiterer Überschneidungspunkt der beiden Unternehmen.

In Reaktion auf den Bericht hat Mozilla TrustCor aufgefordert, innerhalb von zwei Wochen Stellung zu beziehen. Unter anderem soll das Unternehmen über seine Beziehungen zu Measurement Systems und Packet Forensics aufklären und berichten, wie der Spyware-Code in seinen Email-Dienst gelangte. Von Packet Forensics hieß es bereits, dass es aktuell keine Geschäftsbeziehungen zu TrustCor unterhalte. Nicht sagen wollte das Unternehmen jedoch, ob es in der Vergangenheit Verbindungen gab.

Deine Spende für digitale Freiheitsrechte

Wir berichten über aktuelle netzpolitische Entwicklungen, decken Skandale auf und stoßen Debatten an. Dabei sind wir vollkommen unabhängig. Denn unser Kampf für digitale Freiheitsrechte finanziert sich zu fast 100 Prozent aus den Spenden unserer Leser:innen.

9 Ergänzungen

  1. HA! What’s the news?

    What’s the monitoring process and policies to disband companies from the default installation, and what does it mean for the MS Windows installation at your workplace?

    Ödäsö?

    Natürlich haben solche Unternehmen nichts in allgemeinen (Root-) Zertifikatsspeichern zu suchen. Man müsste jetzt mal wadenbeißen, welche OS- und Browserhersteller zu dem Thema überhaupt Richtlinien haben.

  2. Streng genommen bescheinigen die Zertifikate natürlich nicht die Vertrauenswürdigkeit eines Website-Betreibers, sondern nur die Authentizität.
    Kompromittierung von CAs ist ein alter Hut; ich denke es ist wichtig, dass dementsprechend ordentlich kommuniziert wird, dass TLS lediglich eine zusätzliche überwindbare Hürde gegen nichtstaatliche Angreifer darstellt, komplette Dateneinsicht in den Netzwerkverkehr zu erlangen.
    Wer mehr will, muss auf der Anwendungsebene verschlüsseln und einen wirklich vertrauenswürdigen Schlüsselaustausch garantieren.

    1. Es geht allerdings nicht um „das Zertifikat“ irgendeiner x-beliebigen Seite, sondern um einen ganzen Rootzertifizierer mit weitreichenden Möglichkeiten. Im Rahmen von MITM-Angriffen könnte z.B. Microsoft.com (mal als Versuch, vielleicht auch besser eine Nummer kleiner, wegen Certificate-Pinning) ersetzt werden, ohne dass Systeme in Standardkonfigurationen solches bemerken. Daher ist meine Forderung seit langem, die Zerzifikatsprüfmöglichkeiten massiv aufzublasen, und da auch keine Rücksicht auf sogenannte Nutzer zu nehmen. Denn ein zertifikatsnutzendes System muss eine Historie aller jemals gesehenen Zertifikate mitführen können, sowie Konsistenzprüfungen durchführen und je nach Konfiguration rückfragen, z.B. „warum wurde dieses Zertifikat früh ausgetauscht“ oder „warum wurde das Zertifikat frühzeitig ausgetauscht aber nicht zurückgerufen“ oder „warum wurde das Zertifikat zu einem alten zurückgetauscht“ oder „warum ist die Rückrufliste von derselben Rootstelle signiert wie das Webserverzertifikat und warum eine andere als vor 12 Minuten“. Dazu kommt noch die Unterstützung, Zertifikate händisch zu verifizieren und auch per GPG u.ä., also zusätzliche Verifikationskanäle zu unterstützen. Wäre auch angeraten, falls doch mal Quantencomputer und daraus Resultierendes weit genug sein sollten bzw. könnten. Schon bei Tochterunternehmen o.ä. würde ich da einen „full stop“ machen.

      >>> Streng genommen bescheinigen die Zertifikate natürlich nicht die Vertrauenswürdigkeit eines Website-Betreibers, sondern nur die Authentizität.

      Root-Zertifikate für alles von Überwachungsunternehmen? Eher nicht möglich, da noch von Authentizität auszugehen.

      >>> ich denke es ist wichtig, dass dementsprechend ordentlich kommuniziert wird, dass TLS lediglich eine zusätzliche überwindbare Hürde gegen nichtstaatliche Angreifer darstellt

      Ganz so einfach darf es aber nicht sein. Die mussten „das letzte mal“ schon einen taiwanesischen Hardwarehersteller „hacken“. Die Branche lebt davon, dass da nicht einfach etwas möglich ist, sonst war es das mit „einfach“ – die Mittel der Umgehung werden ja schon mittels Loginfallen und Verkehrsumleitung gesucht.

      Wo „einfach“ bzw. „so“ etwas möglich ist, dort fliegt aus den Zertifikatshalden raus – so muss das sein. Und Bei Firmen mit entsprechenden Abhängigkeiten sollte das auch so sein.

      1. Da kann man sicherlich noch einiges ziemlich obligatorisches dranhängen. Z.B. alternative Sperrlisten, sowie mehrere davon, manuelle wie remote, usw.

        1. Und User-Pinning :). Also Nutzer können sagen, dass sie das Zertifikat wollen, sonst gewarnt werden wollen. Bei Internetdiensten im Grunde auch mit DNS und IPs und wenn schon Internet und Cloud, dann bitte auch eine (vorsichtige) Möglichkeit, Daten der Konsistenzprüfung und Nutzerermächtigung auch auszutauschen.

          1. Da muss man noch viel weiter gehen: auch den Vergleich solcher Daten, im Sinne mitgeführter Referenzen. Also z.B. „WARNUNG: Bei Fred war das Zertifikat von xyz.abc gestern noch ein anderes.“ oder „Rupert vertraut diesm Zertifikat… nicht.“.

            Nach Schuhen braucht man eben noch Socken, Schienbeinschoner, Tiefschutz, äh… usw. usf.

  3. > TrustCor Systems ist durch seine besondere Stellung als Root-Zertifizierungsstelle sogar in der Lage, andere Stellen zur Vergabe von Zertifikaten zu authorisieren

    Das trifft, sollte man ergänzen, auf ALLE Root.CAs zu.
    Der Spaß „funktioniert“ doch nur solange, solange das Vertrauen in die zentralen Instanzen nicht beeinträchtigt wird.

    1. Weswegen das Problem-chen ja auch in der Unabhängigkeit der Zertifizierungsstelle bzw. im Text des Artikels zu suchen wäre!

Dieser Artikel ist älter als ein Jahr, daher sind die Ergänzungen geschlossen.