Vor etwas mehr als drei Jahren hatten wir hier im Blog die Open-Source-Veröffentlichung unserer Shared-Secrets-Webanwendung bekannt gegeben und damit genau das erreicht, was wir erreichen wollten: Mehr Augen schauten auf die Anwendung und fanden Probleme mit der eingesetzten Logik. Die Sicherheit der eigentlichen Verschlüsselung stellte nie das große Problem dar, da mit GnuPG auf einen etablierten Standard gesetzt wurde. Auf Basis von GnuPG die Nur-Einmal-Lesen-Eigenschaft aufzubauen, führte jedoch wiederholt zu Anpassungsaufwänden.
Die Änderungen über die Zeit teilen sich grob in zwei Kategorien – auf der einen Seite die Änderungen, die Feature-Verbesserungen mit sich brachten und auf der anderen Seite Änderungen, die erforderlich waren, um Schwächen in der gewählten Verschlüsselung zu umgehen.
Feature-Verbesserungen
Kommen wir erstmal zu den Featureverbesserungen:
- Es wurde der Wunsch nach einer zusätzlichen lokalen Verschlüsselung laut, damit der Server zwar die Nur-Einmal-Lesen-Eigenschaft durchsetzt, selbst das eigentliche Geheimnis jedoch nicht mitlesen kann.
- Intern wurde festgestellt, dass die Base64-Encodierung aufgrund der unüblichen Sonderzeichen die Links in Mails kaputt machten, sodass diese nicht mehr einfach angeklickt werden konnten. Daher wurde auf URL-safe Base64-encodierte Links gewechselt.
- Wir selbst haben die Anwendung immer nur mit NGINX betrieben. Plötzlich war ein Nutzer da, der gern Apache verwenden wollte und in Probleme mit den langen URLs geriet. Mit einem kleinen Bugfix konnte das Problem aus der Welt geschafft werden.
Verschlüsselungsrelevante Verbesserungen
Als nächstes sehen wir uns einmal an, welche verschlüsselungsrelevanten Themen über die Jahre bearbeitet wurden:
- Um die API zur Nutzung von GnuPG ordentlicher zu gestalten, wurde der Support für das GnuPG-PECL eingeführt. Es stellte sich jedoch bald heraus, dass das GnuPG-PECL Integritätsfehler nicht korrekt zurückgab, was direkte Auswirkungen auf die Nur-Einmal-Lesen-Eigenschaft von Shared-Secrets hatte. Daher führten wir zuerst eine Warnung ein, das GnuPG-PECL nicht zu nutzen und schalteten schlussendlich den GnuPG-PECL Support vollständig ab.
- In diese Zeit fiel auch das Finding eines Bloglesers, dass durch Anfügen von Parametern an die URL eine URL mehrfach abrufbar wurde. Das Problem wurde durch verbessertes Parsen der URL behoben, doch erst nach dem initialen Fixen der Lücke wurde uns klar, dass eigentlich die fehlende Integritätsprüfung des GnuPG-PECL diese Lücke geöffnet hatte.
- Im Jahr 2018 wurde die Efail-Lücke bekannt. URLs, die direkt von der Anwendung generiert wurden, waren nicht betroffen, lokal erzeugte URLs jedoch potentiell schon. Daher bauten auch wir einen weiteren Check ein und verweigerten das Entschlüsseln von nicht integritätsgeschützten URLs.
- Mit neueren GnuPG-Releases wurde zusätzliche Konfiguration erforderlich, um die verbliebene Aufrufmöglichkeit weiterhin nutzen zu können. Die Erkenntnis und die dokumentierte Lösung kamen hierbei von extern.
Modification Detection Code
Wie man an der Auflistung erkennt, wurde ein großer Teil der Arbeit darauf verwandt, die verwendete GnuPG-Verschlüsselungsbasis abzusichern und um die Unzulänglichkeiten der Integritätssicherung herumzuarbeiten. Die Efail-Lücke letztes Jahr hat uns an dieser Stelle die Augen geöffnet, genauer gesagt ein Schlagwort, das dabei immer wieder in sämtlichen Nachrichtentiteln gefallen ist: der Modification Detection Code (MDC). Beim initialen Entwickeln der Shared-Secrets-Webanwendung war die Annahme, dass GnuPG die erzeugten Nachrichten entsprechend des Stands der Technik (sprich: vollständig) integritätssichern würde. Mit Blick auf den RFC 4880 stellt man jedoch fest, dass der MDC sich nur auf die symmetrisch verschlüsselten Daten bezieht:
The Modification Detection Code packet contains a SHA-1 hash of plaintext data, which is used to detect message modification. It is only used with a Symmetrically Encrypted Integrity Protected Data packet. The Modification Detection Code packet MUST be the last packet in the plaintext data that is encrypted in the Symmetrically Encrypted Integrity Protected Data packet, and MUST appear in no other place.
Das heißt, dass es bisher – trotz des Einsatzes des MDC – möglich gewesen wäre, eine Shared-Secrets-URL zu parsen, die GnuPG-Nachricht mit weiteren Paketen zu ergänzen und im Anschluss die geänderte URL erneut abzurufen, da die hinzugefügten Pakete nicht Teil der Integritätsprüfung gewesen wären. Bei dieser Erkenntnis ist uns klar geworden, dass GnuPG für den angestrebten Zweck nicht sinnvoll einsetzbar ist, denn dieser besteht daraus, Nachrichten eindeutig erkennen und deren erneuten Abruf unterbinden zu können.
Unsere Anforderungen an das neue Verschlüsselungssystem
Gleichzeitig wollten wir den bisherigen Vorteil der Shared-Secrets-Webanwendung nicht verlieren: Bisher war es möglich, Shared-Secrets-URLs lokal in der Shell zu erzeugen, die kompatibel zum Abruf mit der Webanwendung sind. Das bedeutete für uns, dass die neue kryptographische Basis der Anwendung so gebaut sein musste, dass diese möglichst ohne unübliche Tools lokal realisierbar ist. Unsere Wahl fiel daher auf OpenSSL und ein eigenes Nachrichtenschema, das die Vorteile von GnuPG aufwies, ohne dessen Nachteile mitzubringen:
- Die Verschlüsselung sollte hybrid erfolgen: Durch den asymmetrischen Anteil der Verschlüsselung sollte sichergestellt sein, dass man Nachrichten lokal verschlüsseln kann, diese jedoch nur vom Server wieder entschlüsselt werden können.
- Der gesamte Nachrichteninhalt inklusive aller erforderlichen Metadaten sollte mit einem Message Authentication Code (MAC) versehen sein, sodass alle Änderungen an der verschlüsselten Nachricht auffallen würden.
Vorteile des neuen Verschlüsselungsschemas
Das Ergebnis der Überlegungen ist in einem separaten technischen Dokument beschrieben. Es wurden konservative Verschlüsselungs- und Hashalgorithmen gewählt, die dank einer enthaltenen Versionierung der Nachrichtenformate zukünftig aktualisiert werden können. In der Implementierung haben sich durch das neue Verschlüsselungsschema einige Vorteile ergeben:
- Es kann nun verhindert werden, dass Nachrichten an mehrere Empfänger entschlüsselt werden, was die Nur-Einmal-Lesen-Eigenschaften bisher zerstört hat.
- Der Fingerprint zum Erkennen von bereits gesehenen Nachrichten ist nun direkt der Message Authentication Code der verschlüsselten Nachricht.
- Dank des eindeutig definierten Nachrichtenformats können nun zu erwartende Nachrichtenlängen direkt berechnet werden. Dadurch war es möglich, die unterstützte Maximallänge von Nachrichten zu verlängern und mehrzeilige Geheimnisse zuzulassen.
- Da wir auch ein Nachrichtenformat für rein symmetrische Nachrichten definiert haben, konnten wir für die Browser-basierte lokale Verschlüsselung von 3rd Party JavaScript-Krypto-Libraries auf die inzwischen existierende Web Cryptography API des W3C wechseln. Dank des wesentlich besseren Einblicks in das Verschlüsselungsschema ist es nun sogar möglich, die im Browser stattfindende Zusatzverschlüsselung auch lokal in der Shell abzubilden.
Natürlich haben wir auch weiterhin an den damals gesetzten Zielen festgehalten: Die Instanz, die wir unter secrets.syseleven.de betreiben, hat weiterhin A+ Ratings sowohl von Qualys SSL Labs als auch vom Mozilla Observatory.
Wir hoffen, mit der kritischen Betrachtung der Sicherheitseigenschaften und dem Neubau der kryptographischen Basis der Shared-Secrets-Webanwendung einen weiteren Beitrag zur Sicherheit unserer Kunden und externen Partner geleistet zu haben.
Wir freuen uns auch weiterhin über Fragen und Anregungen, wie wir die Anwendung weiter verbessern können. Hinterlasst einen Kommentar im Blog oder sendet eine E-Mail an secrets@syseleven.de.
