Gedanken und Fragen zu PKI-Vorfällen der letzten Wochen

[869288141]

Hallo NSP-Team,
ich habe den Beitrag zu SwissSign aufmerksam und interessiert verfolgt.
https://forum.nospamproxy.com/threads/swisssign-bestimmte-zertifikate-widerrufen-und-erneuern.1739/

Nachdem der Höhepunkt der aktuellen Situation offenbar erreicht bzw. überschritten ist, möchte ich einige Gedanken und Fragen dazu teilen.

Vor weniger als vier Wochen gab es bereits einen Vorfall bei D-Trust. Damals waren ausschließlich TLS-Zertifikate betroffen. Auslöser war letztlich eine vergleichsweise kleine Abweichung – die Zertifikatslaufzeit betrug 203 statt der erlaubten 200 Tage. Dennoch wurde vorsorglich ein Issue im Mozilla Bugtracker (Link) erstellt, was innerhalb kürzester Zeit zu einem größeren Problem (aktueller Linter Prozess entspricht nicht den Baseline Requirements) geführt hat. Mich hatte damals ehrlich gesagt gewundert, dass es im Forum kaum Rückfragen dazu gab. Wobei der Zeitpunkt (Freitag, ca. 17:30 Uhr) sicherlich auch eine Rolle gespielt haben dürfte.

Nun, keine vier Wochen später, erleben wir mit SwissSign den nächsten Vorfall. Dieses Mal bei einem größeren Anbieter und im Bereich S/MIME statt TLS. Auch hier liegt die Ursache in einem Compliance-Thema, und erneut wurde ein Issue im Mozilla Bugtracker (Link) erstellt.

Aus meiner Sicht ist die genaue Ursache für die betroffenen Kunden zweitrangig. Entscheidend ist: Die Baseline Requirements definieren klar, innerhalb welcher Fristen betroffene Zertifikate widerrufen werden müssen – unabhängig von Wochenenden, Feiertagen oder anderen Umständen.

Was mich nachdenklich stimmt, ist die Einschätzung des Risikos solcher Szenarien. Offenbar wurde dieses zwar grundsätzlich betrachtet, aber eher als unwahrscheinlich eingestuft oder im Worst Case nicht ausreichend berücksichtigt. Zu dieser Einschätzung komme ich unter anderem aufgrund des kurzfristig bereitgestellten PowerShell-Skripts, das offensichtlich unter hohem Zeitdruck entstanden ist. Möglicherweise basierte es auf früheren, internen Tests – dennoch wirkte die Lösung eher reaktiv als vorbereitet.

In beiden Fällen lag die Vorlaufzeit bis zum Sperren bzw. Zurückziehen der Zertifikate bei maximal fünf Tagen. Allerdings gibt es Rahmenbedingungen, unter denen sich dieser Zeitraum auf 24 Stunden verkürzen kann. Das ist dann eine ganz andere Hausnummer. Im Vergleich dazu wirken fünf Tage fast komfortabel.

Positiv hervorheben möchte ich an dieser Stelle, dass zeitnah ein Workaround zur Verfügung gestellt wurde. Herzliches Dankeschön dafür an dieser Stelle! Dennoch würde ich mir als Kunde perspektivisch eine nachhaltigere Lösung wünschen. Eine entsprechende Funktionalität sollte aus meiner Sicht direkt im Produkt und vollständig über die UI abbildbar sein, ohne auf Skripte zurückgreifen zu müssen.

Mich würde daher interessieren:

• Wie bewertet ihr intern aktuell das Risiko solcher kurzfristigen Widerrufs-Szenarien?
• Gibt es Planungen, entsprechende Prozesse bzw. Funktionen künftig fest in das Produkt zu integrieren?
• Welche Lehren wurden aus den Vorfällen (D-Trust und SwissSign) gezogen?

Vielen Dank vorab und viele Grüße,
Daniel

 

[JanJäschke]

Guten Morgen Daniel,

erst einmal ein Danke für dein Feedback. Wie bekannt ist nehmen wir Kunden Feedback sehr ernst und freuen uns auch sehr darüber.
Daher nehme ich auch vorweg, dass ich mögliche Verbesserungen im NoSpamProxy diskutieren werde um komfortabler als Kunde reagieren zu können. Ideen dazu gibt es bereits, auch schon seit der D-Trust Thematik. Dies von heute auf Morgen umzusetzen wäre aber eine übertriebene reaktive Reaktion gewesen.
Wir sind darauf bedacht unseren Kunden ein bestmögliches Erlebnis mit NoSpamProxy zu bieten, weshalb wir auch bei solchen Themen noch bessere Reaktionsmöglichkeiten bieten möchten.


Nun mal meine ganz persönliche Meinung, nicht als PM sondern als Person und Admin:
Ich sehr überrascht über deine Reaktion. NoSpamProxy liefert zwei Möglichkeiten direkt aus dem Produkt heraus handeln zu können:
1. Manuelles ausrollen neuer Zertifikate über die NCC
2. warten auf die Revozierung -> der Benutzerimport stößt neue Zertifikate an (hier käme der zu verbessernde Komfortfaktor ins Spielt)
Das Skript ist tatsache reaktiv entstanden um unsere Kunden die einen sehr hohe Anforderung and durchgehende Verschlüsselung/Signatur haben zu unterstützen vorzeitig neue Zertifikate voll automatisch neue Zertifikate ausrollen zu können. Das hätte auch per NCC gemacht werden können
Ich finde es immer wieder erstaunlich wie negativ reagiert wird wenn NoSpamProxy als Produkt Ihre Kunden bei Problem unterstützt die genau genommen nicht unsere sind. Geht dein Feedback so auch an die SwissSign oder die D-Trust? Da mal nachgefragt wie man hunderte oder tausende Zertifikate vorzeitig neu austellen soll?


LG
Jan

 

[Sören]

Dennoch würde ich mir als Kunde perspektivisch eine nachhaltigere Lösung wünschen. Eine entsprechende Funktionalität sollte aus meiner Sicht direkt im Produkt und vollständig über die UI abbildbar sein, ohne auf Skripte zurückgreifen zu müssen.

ich stelle mir gerade die Frage wie das technisch funktionieren soll

Die Zertifikate sind zu dem Zeitpunkt noch gültig, es gibt kein technisches Merkmal an den Zertifikaten das sagt "wird vorzeitig revoked am xx". Eine weitere Alternative könnte sein, dass eine CA diese Informationen per API mit uns teilt, bisher gibt es sowas nicht.

Daher sind uns da komplett die Hände gebunden was einen Automatismus betreffen könnte. Hier sind die CA´s aus meiner Sicht in der Pflicht.

Daher hat @JanJäschke das völlig richtig beschrieben:

1. Manuelles ausrollen neuer Zertifikate über die NCC
2. warten auf die Revozierung -> der Benutzerimport stößt neue Zertifikate an

 

[wagnerv]

Hallo zusammen,

ich möchte selbstverständlich meinen Senf auch dazugeben.

Es ist aus meiner Sicht verständlich, dass auf so ein Szenario niemand vorbereitet war und vermutlich proaktiv so ein Szenario nicht in Betracht genommen wurde. Allerdings gab es schon mal so einen Fall (https://forum.nospamproxy.com/threa...-zertifikaten-aufgrund-eines-formfehlers.547/)

Ich persönlich bin immer wieder erstaunt wie schnell hier auf ein Problem reagiert wurde. Es wurde eine Lösung angeboten die sehr gut funktioniert hat (auch wenn es bei größeren Batches (unsere) NSP Server ge-DDost hat). Ich bin immer wieder überrascht wie schnell Leute hier im Forum reagieren.

Nun meine Gedanken zu dem Vorfall im NSP (funktionell):

- Manuelles Ausrollen neuer Zertifikate im NCC, ja selbstverständlich möglich. Administrativ aber sehr aufwändig. Ich kann nicht nach Zertifikaten von bis Datum suchen (was wieder sehr speziell ist bezogen auf den Fall).
- Revozierung ist aktuell immer noch im NSP nicht sichtbar.

ich stelle mir gerade die Frage wie das technisch funktionieren soll

ich könnte mir vorstellen, dass man Zertifikate markiert und mit einem Button "erneuern markierter Zertifikate" auslöst. ggf. Meldung, dass die Zertifikate noch gültig sind , fortfahren? -> ja nein.

Vielleicht bisschen OT aber wäre es möglich einen "Zurückrufen" Button im NCC zu implementieren? Oder was wäre die Empfehlung für die Zertifikate der Mitarbeiter die das Unternehmen verlassen? (ist natürlich nicht ein Problem von NSP , leider (aus welchem Grund auch immer) sehen wir im SwissSign Portal keine Zertifikate, weder ausgestellte noch revozierte, weiß nicht ob noch jemand so ein Problem hat. Somit kann ich über SwissSign selbst die Zertifikate nicht zurückrufen.

man ist schon an funktionalen und supportativen Luxus von NSP gewöhnt

 

[Simon_]

Was glaube ich schon eine deutliche Erleichterung bringen würde, wäre dass mehr Optionen zu Verwaltung der Zertifikate unter dem Punkt "Identitäten" > "Zertifikate" zu Verfügung stehen würden. Am besten auch mit Mehrfachauswahl.
Dort ist die Massenverwaltung deutlich einfacher wie jeden User einzeln anfassen zu müssen.
Außerdem wären hier auch mehr Filteroptionen wünschenswert. Aktuell kann z.B. nicht nach gesperrten Zertifikaten gefiltert werden.

 

[869288141]

Hallo zusammen,

Ich finde es immer wieder erstaunlich wie negativ reagiert wird wenn NoSpamProxy als Produkt Ihre Kunden bei Problem unterstützt die genau genommen nicht unsere sind.

Danke für dein Feedback. Ich war bisher der Meinung, dass es eine konstruktive Formulierung gewählt habe. Aber in diesem Fall muss ich an meiner Ausdrucksweise arbeiten. Dafür möchte ich mich ausdrücklich bei euch entschuldigen. Das war und ist keinesfalls meine Absicht gewesen! Es soll wie bisher auch eine Diskussion/Austausch auf Augenhöhe sein.

Für mich ist das Zertifikatsmanagement eine Kernfunktion des Produkts. Es stellt eine Schnittstelle bereit, um Zertifikate automatisiert von verschiedenen (öffentlichen) CAs abzurufen.

Aus meiner Sicht sollte das keine Einbahnstraße sein. Logisch wäre es daher, wenn darüber hinaus auch das Sperren sowie die automatisierte Neuausstellung von Zertifikaten möglich wäre. Das würde das bestehende Feature-Set meines Erachtens sinnvoll abrunden.

1. Manuelles ausrollen neuer Zertifikate über die NCC

Das mag bei einer überschaubaren Anzahl von Zertifikaten sicherlich für eine größere Anzahl eurer Kunden der bestmögliche Weg sein. Bei Kunden mit einer 3 oder 4stelligen Anzahl von Zertifikaten ist das doch kaum zu bewältigen, oder?

2. warten auf die Revozierung -> der Benutzerimport stößt neue Zertifikate an (hier käme der zu verbessernde Komfortfaktor ins Spielt)

Bin ich grundsätzlich dabei. Setzt aber voraus, dass diese Revokation seitens der CA erfolgt ist und dies auch in der NCC erkannt wird. Soweit ich das aktuell überblicke, ist das wohl nicht immer der Fall. Natürlich ist mir bewusst, dass ihr auf Windows Server und deren Funktion keinen Einfluss habt. Aber spätestens wenn dies nicht (mehr) zuverlässig funktioniert, greift dein genannter Punkt nicht, oder?

Das Skript ist tatsache reaktiv entstanden um unsere Kunden die einen sehr hohe Anforderung and durchgehende Verschlüsselung/Signatur haben zu unterstützen vorzeitig neue Zertifikate voll automatisch neue Zertifikate ausrollen zu können.

Das rechnen dir die betroffenen Kunden sicherlich hoch an und haben bestimmt in verschiedenen Formen Ihre große Dankbarkeit ausgedrückt.

Geht dein Feedback so auch an die SwissSign oder die D-Trust? Da mal nachgefragt wie man hunderte oder tausende Zertifikate vorzeitig neu austellen soll?

D-Trust nutzt mein aktueller Arbeitgeber nicht. Nichtsdestotrotz haben wir das Thema im Rahmen einer Regelabstimmung mit dem BSI angesprochen. Uns wurde dabei zugesichert, dass die organisatorischen Prozesse geprüft und entsprechende Maßnahmen evaluiert werden. Die CA ist für Bundes-, Landes- und kommunale Behörden essenziell. Insbesondere für Services wie die elektronische Patientenakte, Bundeswehr, die Gematik-Infrastruktur oder den elektronischen Personalausweis. Man stelle sich vor, die CA fliegt aus dem Root Programm der Browser Hersteller...

Mein Arbeitgeber ist Kunde bei SwissSign, weshalb es hierzu einen direkten Austausch und entsprechendes Feedback gab. Insgesamt ist dieser Vorfall kein triviales Thema. Über alle Kunden hinweg sind nicht nur einige hundert oder wenige tausend, sondern über 450.000 Zertifikate betroffen.

Operativ hatte das bei uns jedoch kaum Auswirkungen, da das Zertifikatsmanagement (z.B. TLS, S/MIME etc.) weitgehend automatisiert ist. Zusätzlich rufen wir (Fallback) Zertifikate mittlerweile über mehrere CAs ab, um in solchen Fällen nicht vollständig abhängig zu sein. Das war auch der Auslöser diesen Beitrag zu schreiben.

ich stelle mir gerade die Frage wie das technisch funktionieren soll

wagnerrv und Simon_ haben Teile bereits erwähnt.

In unserer Lösung können Zertifikate nach Anbieter, CA sowie Datum (Start- und Enddatum) gefiltert werden. Dadurch lässt sich schnell ein Überblick über den Bestand gewinnen.

Anschließend können die Zertifikate entweder einzeln oder gesammelt ausgewählt werden. Über das Action Menü lassen sich dann verschiedene Operationen ausführen. In diesem Fall beispielsweise eine erzwungene Neuausstellung.

Die daraus resultierenden Aufträge werden in eine Queue eingereiht und anschließend sukzessive, abhängig von definierten Limits, abgearbeitet. Selbstverständlich lassen sich große Mengen an Zertifikaten nicht innerhalb weniger Minuten austauschen, aber darum geht es auch nicht. Der primäre Vorteil liegt in der deutlichen Reduktion des manuellen Aufwands und der damit verbundenen Fehleranfälligkeit.

Das Sahnehäubchen ist, dass nach erfolgreicher Neuausstellung des Zertifikats das bisherige bzw. alte Zertifikat automatisch zurückgezogen wird. In diesem konkreten Fall ist das auch zwingend erforderlich, da SwissSign dies nach der Deadline zentral für alle Kunden übernimmt.

Es gibt allerdings auch andere Szenarien, in denen die jeweilige CA diesen Schritt nicht automatisch übernimmt. Entsprechend muss das dann individuell berücksichtigt werden.

Es ist aus meiner Sicht verständlich, dass auf so ein Szenario niemand vorbereitet war und vermutlich proaktiv so ein Szenario nicht in Betracht genommen wurde.

Dass das Thema nicht betrachtet wurde, kann ich mir ehrlich gesagt nicht vorstellen. Meine Vermutung ist, dass es im Rahmen der Risikoabwägung durchaus regelmäßig bewertet wurde. Dabei stehen in der Regel zwei Fragen im Vordergrund: Wie hoch ist die Eintrittswahrscheinlichkeit und wie groß ist die betroffene Kundenbasis bzw. Installationsbasis. Schnittstellen in NoSpamProxy sind das eine, allerdings kocht jede CA ihr eigenes Süppchen. Das bedeutet, es gibt leider keine einheitliche, standardisierte API, die sich für alle CAs gleichermaßen verwenden lässt. Jede Integration muss daher individuell umgesetzt und an die jeweiligen Eigenheiten der CA angepasst werden.

Bei uns sehe ich, welche Ressourcen für unsere Lösung bereits für die initiale Entwicklung, die kontinuierliche Pflege, die Umsetzung von CA-seitigen Änderungen sowie die Fehlersuche gebunden werden. Das sind inzwischen deutlich mehr als zwei FTEs, was mich regelmäßig überrascht.

NoSpamProxy ist natürlich kein Wohlfahrtsverein, und am Ende spielen wirtschaftliche Aspekte immer eine Rolle. Auch die Weiterentwicklung muss entsprechend tragfähig finanziert sein.


Gruß,
Daniel