TLS-Pinning und VPN-Zugang beantworten verschiedene Fragen

Setzt man eine private mobile App hinter ein VPN, fragt ein vernünftiger Mensch, ob sie noch Certificate Pinning braucht. Die Frage klingt wie eine Wahl zwischen zwei gleichwertigen Kontrollen, und sie ist wirklich eine Frage zu zwei verschiedenen Toren. Das VPN entscheidet, ob dieses Gerät den Pfad überhaupt nutzen darf; die App entscheidet, ob der erreichte Server der erwartete ist. Beantwortet man beides getrennt, wird das Design einfacher.

Zwei Tore, zwei Fragen

Netzwerkzulassung betrifft den Client: Ist dieses Gerät registriert, ist sein Nachweis gültig, und erlaubt die Richtlinie ihm diesen Pfad? Anwendungsvertrauen betrifft den Server: Hat die Verbindung einen Dienst mit einer Identität erreicht, die die App akzeptiert? Diese Antworten kommen aus verschiedenen Systemen, scheitern aus verschiedenen Gründen und werden von verschiedenen Teams behoben. Ein VPN-Handshake kann gelingen, während die App mit einem abgelaufenen Zertifikat hinter dem Peer spricht. Eine perfekt gepinnte App kann trotzdem für niemanden erreichbar sein, weil das Gerät nie ins Netz gekommen ist.

Beide ergänzen sich. Fällt eines weg, fehlt eine Kontrolle; das andere hinzuzufügen ersetzt es nicht.

Was ein Pin tatsächlich begrenzt

Ein Pin verengt die Menge der Serveridentitäten, die die App akzeptiert, meist indem er einen öffentlichen Schlüssel oder einen Zertifikat-Hash benennt, statt jeder Kette zu vertrauen, für die ein Speicher bürgen würde. Er ist eine Einschränkung, die auf der gewöhnlichen Prüfung aufsetzt, kein Ersatz für sie. Die gewöhnliche Prüfung beantwortet, ob eine Kette überhaupt vertrauenswürdig ist; der Pin beantwortet, ob es die Kette ist, die diese App erwartet. Eine Implementierung, die den ersten Schritt überspringt, hat keine Sicherheit gewonnen, nur Neuheit.

Das gepinnte Objekt unterscheidet sich zwischen Plattformen, daher sagt das Wort allein sehr wenig. Einen Hash aus dem Trust Store eines Produkts zu kopieren und ihn in einer mobilen App als dasselbe zu behandeln, ist ein häufiger und stiller Fehler.

Pinning auf der Plattform ist eine Konfiguration, keine Richtlinie

Android stellt Pinning über seine Netzwerksicherheitskonfiguration bereit, wo ein Pin-Set Digests eines öffentlichen Schlüssels enthält und die Kette mindestens einen davon enthalten muss. Diese Datei gilt pro App und erfordert eine bewusste Build-Änderung. iOS hat keinen gleichwertigen Manifest-Mechanismus, deshalb lebt das Pinning dort im eigenen Vertrauensprüfcode der App.

Da der Mechanismus unterschiedlich ist, muss die Anforderung pro Plattform geschrieben werden. Eine Richtlinie, die pinne das Zertifikat sagt, ohne die Plattform zu nennen, ist nicht umsetzbar.

Rotation entscheidet, ob der Pin überlebt

Der schwierige Teil ist nicht die erste Version, sondern die Zertifikatserneuerung danach. Eine restriktive Vertrauensrichtlinie lehnt einen legitimen neuen Schlüssel genauso entschieden ab wie den eines Angreifers.

Zwei Mechanismen machen Rotation überlebbar: ein Reserve-Pin, dem schon vertraut wird, bevor er gebraucht wird, und ein Ablaufdatum am Pin-Set, damit die Durchsetzung ausläuft, statt die App lahmzulegen. Beides sind Richtlinienentscheidungen, und gerade der Ablauf ist eine bewusste Verringerung der Sicherheit, kein harmloser Timer. Benennt, wer den App-Build, den TLS-Endpunkt und die Zertifikatserneuerung steuert, und führt sie in einen Änderungsprozess zusammen. Sind das drei verschiedene Teams, wird der Pin irgendwann einen Ausfall verursachen, den niemand eingeplant hat.

Ein verlorenes Gerät ist ein drittes Problem

Das Widerrufen eines VPN-Nachweises beendet nicht unbedingt eine Anwendungssitzung, und ein Server-Pin tut überhaupt nichts gegen ein Telefon in fremder Hand. Gerätesperre, Speicherung der Nachweise, Sitzungsdauer und Fernwiderruf sind getrennte Entscheidungen mit getrennten Verantwortlichen. Sie in die Pinning-Diskussion zu falten garantiert, dass keines davon entworfen wird.

Prüft vier Beziehungen statt der einen, die ihr seht: den beabsichtigten Server und Vorgang, ein Konto, das abgelehnt werden sollte, eine Serveridentität, die verworfen werden sollte, und die geplante Rotation. Ein funktionierendes VPN übt nur die erste. Schreibt auf, was jeder Test bewiesen hat, denn die nächste Person wird annehmen, ein grüner Tunnel bedeute, dass alle vier bestanden wurden.