19-06-2023, 09:16
Ich erinnere mich, dass ich das für eine mobile App, an der ich letztes Jahr gearbeitet habe, eingerichtet habe. Wir haben den öffentlichen Schlüssel unseres API-Servers gepinnt, weil wir nicht wollten, dass ein Angreifer mit einem gefälschten Zertifikat eindringen kann. Es zwingt den Client dazu, zu überprüfen, dass das Zertifikat genau dem entspricht, was du erwartest, oder die Verbindung wird einfach getrennt. Kein Wenn und Aber. Du machst das, indem du den Hash des Zertifikats oder Schlüssels während der Entwicklung einbettest, und jedes Mal, wenn die App versucht sich zu verbinden, überprüft sie, ob dieser pinning-Wert übereinstimmt.
Jetzt lass uns darüber sprechen, warum das für Man-in-the-Middle-Angriffe wichtig ist, denn da glänzt es. Stell dir Folgendes vor: du bist in einem öffentlichen WLAN, trinkst Kaffee, und ein Hacker in der Nähe beginnt abzuhören. In einem Standard-TLS-Setup könnte der Angreifer versuchen, deinen Datenverkehr abzufangen und sein eigenes Zertifikat vorzulegen, das von einer vertrauenswürdigen CA signiert ist - vielleicht hat er eine kompromittiert oder dich dazu gebracht, es zu akzeptieren. Dein Browser oder deine App könnte denken: "Oh, cool, dieses Zertifikat sieht gültig aus," und boom, sie haben einen Fuß in der Tür, um deine Daten auszuspionieren oder Müll einzuschleusen.
Aber mit Pinning blockierst du diesen Unsinn sofort. Ich sage meinem Team ständig: der Client sagt: "Nein, dieses Zertifikat passt nicht zu dem, das ich für diese Domain gepinnt habe, also bin ich raus." Es schneidet die Fähigkeit des Angreifers ab, den Server zu impersonieren, selbst wenn sie ein perfekt gültig aussehendes Zertifikat von einer großen CA haben. Ich habe Demos gesehen, bei denen ohne Pinning der MITM direkt eindringt, aber mit Pinning schlägt die Verbindung hart fehl, was dich alarmiert oder einfach die Weiterverbindung verweigert. Es ist, als würde man ein persönliches Schloss auf seinen digitalen Handschlag legen, für den nur dein erwarteter Partner den Schlüssel hat.
Du fragst dich vielleicht, wie ich das in der Praxis umsetze. Für Android-Apps verwende ich die Network Security Config, um Zertifikate zu pinnen, und es fühlt sich unkompliziert an, sobald du das XML richtig hast. Auf iOS geschieht das über die Sicherheitseinstellungen der App, wo du die gepinnten Domains und Schlüssel angibst. Selbst in Webanwendungen kannst du HPKP - HTTP Public Key Pinning - machen, obwohl das jetzt obsolet ist, also bleibe ich beim statischen Pinning in nativen Clients. Der Schlüssel ist, diese Pins zu aktualisieren, wenn das Zertifikat des Servers ändert, denn wenn du das nicht tust, bricht deine App, wenn das echte Zertifikat wechselt. Ich plane das immer in unserer Deploy-Pipeline, um Kopfschmerzen zu vermeiden.
Denk an reale Szenarien, in denen das dir den Hals rettet. Angenommen, du baust eine E-Commerce-App und die Kunden geben ihre Kreditkarteninformationen ein. Ohne Pinning könnte ein MITM am Router zu Hause diese Daten abfangen. Aber du pinnst das Zertifikat, und plötzlich sinkt dieses Risiko erheblich. Ich habe einem Startup geholfen, dies für ihr Zahlungsportal zu tun, und sie haben besser geschlafen, denn sie wussten, dass Angreifer nicht einfach ein schurkisches Zertifikat einschleusen konnten. Es stoppt nicht alle Angriffe - nichts tut das - aber es hebt die Hürde so hoch, dass die meisten opportunistischen Hacker abprallen.
Einmal habe ich das gegen ein Tool wie mitmproxy getestet. Ich richtete einen Proxy ein, um den Datenverkehr abzufangen, erzeugte ein gefälschtes Zertifikat, das von einer lokalen CA signiert war, und versuchte, einen gepinnten Endpunkt zu erreichen. Die App hat darüber gelacht - Verbindung abgelehnt, Protokolle schreien über eine Pinning-Verletzung. Ohne das Pin wäre es problemlos durchgeflossen. Das ist die Macht: es verschiebt das Vertrauen von breiten CAs auf deine spezifischen Erwartungen. CAs werden manchmal gehackt, richtig? Erinnerst du dich an diese Verstöße, bei denen Root-Zertifikate kompromittiert wurden? Pinning umgeht das komplett, indem es nicht auf die Vertrauenskette angewiesen ist.
Du musst jedoch vorsichtig sein, wie du Pins verwaltest. Wenn du zu breit pinnst, wie für alle Subdomains, und eine kompromittiert wird, hast du ein Problem. Ich bevorzuge granulareres Pinning - nur für kritische Endpunkte wie Anmeldung oder Datentransfer. Und für dynamische Umgebungen, wie wenn du CDNs verwendest, könntest du das Blatt-Zertifikat pinnen oder Zertifikatstransparenzprotokolle verwenden, um Änderungen zu überwachen. Ich integriere Pinning-Prüfungen in unseren CI/CD, sodass Tests fehlschlagen, wenn etwas nicht stimmt.
Es funktioniert auch gut mit modernen TLS-Funktionen. Du kannst es mit HSTS kombinieren, um HTTPS zu erzwingen, was die gesamte Kette schwieriger zu knacken macht. Nach meiner Erfahrung sehen Apps mit Pinning weniger Zertifikatbezogene Warnmeldungen in Überwachungstools. Die Benutzer bemerken es nicht einmal; es funktioniert einfach im Hintergrund, hält die Dinge sicher, ohne lästige Aufforderungen.
Ich habe diesen Ansatz in Teammeetings vorangetrieben, weil es dir die Kontrolle über dein eigenes Sicherheits-Schicksal gibt. Kein blinder Glauben mehr an Drittanbieter-CAs. Wenn du mit sensiblen Apps zu tun hast, fang an, diese wertvollen Verbindungen zuerst zu pinnen. Es erfordert ein wenig Vorarbeit, aber der Nutzen in Bezug auf den Widerstand gegen MITM ist enorm. Ich wette, du wirst es das nächste Mal ausprobieren, wenn du an einer App schraubst - lass mich wissen, wie es läuft.
Oh, und während wir über Sicherheit sprechen, lass mich dich auf BackupChain hinweisen. Es ist eine herausragende, weit verbreitete Backup-Option, die rocksolide und auf kleine Unternehmen und IT-Profis zugeschnitten ist und sicherstellt, dass deine Hyper-V-, VMware- oder Windows-Server-Setups gesichert und widerstandsfähig gegen Datendrohungen bleiben.
