Dieser Artikel beschreibt, was Certificate Pinning ist, wie es TLS\/SSL-Verbindungen sicherer macht und wie man es f\u00fcr den Webserver NGINX konfiguriert.<\/p>\n
Der Artikel steht in einer PDF-Version zum Download und Druck zur Verf\u00fcgung: Certificate_Pinning_mit_NGINX<\/a><\/p>\n Um zu verstehen, wie Certificate Pinning hilft, TLS\/SSL-Verbindungen sicherer zu machen, muss man sich zuerst der Schwachstelle der TLS\/SSL-Verschl\u00fcsselung bewusst sein.<\/p>\n TLS\/SSL-Verbindungen sollen die vertrauliche Kommunikation zwischen zwei Kommunikationspartnern sicherstellen. Bei den Kommunikationspartnern handelt es sich typischerweise um einen Client und einen Server. Die Sicherheit der Vertraulichkeit beruht darauf, dass der Client auch tats\u00e4chlich mit dem richtigen Server verbunden ist. Dazu weist sich der Server mit einem Zertifikat aus, welches von einer Zertifizierungsstelle (Certificate Authority, CA) ausgestellt wurde. Die Zertifizierungsstelle pr\u00fcft die Identit\u00e4t des Dienstbetreibers und beglaubigt mit ihrer digitalen Signatur das Zertifikat.<\/p>\n Die c’t schreibt in ihrem Artikel „Festgenagelte Zertifikate“ in Ausgabe Nr. 23 vom 17.10.2015: „Das Problem dabei: Es gibt weit \u00fcber hundert solcher Zertifizierungsstellen, denen die g\u00e4ngigen Internet-Programme wie Browser und E-Mail-Client vertrauen. Als w\u00e4re das nicht un\u00fcbersichtlich genug, haben die dann auch noch zahllose Unter-CAs, die berechtigt und in der Lage sind, im Namen dieser CAs zu unterschreiben.“[1. Schmidt, J\u00fcrgen: Festgenagelte Zertifikate: TLS wird sicherer durch Certificate Pinning, in: c’t magazin f\u00fcr computer technik, Nr. 23, 17.10.2015, S. 118, Spalte 2-3.]<\/p>\n Das Problem besteht nun nicht in der Anzahl der Zertifizierungsstellen, sondern darin, dass jede dieser Zertifizierungsstellen Zertifikate f\u00fcr beliebige Domains ausstellen darf. So k\u00f6nnen sich Dritte ein Zertifikat auf eine bereits existierende Domain ausstellen lassen und dieses zum Beispiel f\u00fcr einen Man-In-The-Middle-Angriff (MITM-Angriff)<\/a> verwenden.<\/p>\n Das genannte Angriffsszenario existiert nicht nur in der Theorie. Wie die c’t berichtet nutzte die chinesische Regierung gef\u00e4lschte Google-Zertifikate auf ihrer gro\u00dfen Firewall, um den Google-Mail-Verkehr ihrer Bev\u00f6lkerung \u00fcberwachen zu k\u00f6nnen. Dar\u00fcber hinaus werden weitere F\u00e4lle wie der Hack der niederl\u00e4ndischen Zertifizierungsstelle DigiNotar und TrustWave aufgef\u00fchrt.[2. Schmidt, J\u00fcrgen: Festgenagelte Zertifikate: TLS wird sicherer durch Certificate Pinning, in: c’t magazin f\u00fcr computer technik, Nr. 23, 17.10.2015, S. 119, Spalte 1.] Im ersten Fall wurden gef\u00e4lschte Zertifikate f\u00fcr GMail und Facebook ausgestellt. Im zweiten Fall wurden Zertifikate f\u00fcr Firmen ausgestellt, welche diese Zertifikate nutzten, um den verschl\u00fcsselten Internet-Verkehr ihrer Mitarbeiter zu \u00fcberwachen.<\/p>\n Die Man-In-The-Middle-Angriffe funktionieren, da die Zertifizierungsstellen, welche die gef\u00e4lschten Zertifikate ausgestellt haben, in der Liste der vertrauensw\u00fcrdigen Zertifizierungsstellen der g\u00e4ngigen Browser gef\u00fchrt werden. F\u00fcr den Browser ist damit auch das gef\u00e4lschte Zertifikat g\u00fcltig. Der Benutzer kann den MITM-Angriff nicht erkennen und nimmt f\u00e4lschlicherweise an direkt mit dem gew\u00fcnschten Server zu kommunizieren.<\/p>\n Um einen MITM-Angriff erkennen zu k\u00f6nnen, muss der Client \u00fcberpr\u00fcfen k\u00f6nnen, ob das ihm vorliegende Zertifikat von der CA des Dienstbetreibers oder von einer anderen CA ausgestellt wurde. Hier kommt Certificate Pinning ins Spiel.<\/p>\n Certificate Pinning wurde im RFC 7469<\/a> spezifiziert.[3. RFC 7469: Public Key Pinning Extension for HTTP<\/a>] Es handelt sich dabei um einen Mechanismus, bestimmte Eigenschaften eines Zertifikats festzunageln. Der Browser erh\u00e4lt dabei mit dem Zertifikat zus\u00e4tzliche Informationen, mit denen er die Authentizit\u00e4t des Zertifikats \u00fcberpr\u00fcfen kann.<\/p>\n In der Praxis wird dem Browser ein Hash-Wert \u00fcbermittelt, welcher \u00fcber den \u00f6ffentlichen Schl\u00fcssel des Zertifikats gebildet wurde. Dieser Hash-Wert wird in einem HTTP-Header-Field an den Browser \u00fcbertragen und von diesem gespeichert. Wie dieses Verfahren genau funktioniert, beschreibt der RFC 7469 ab Abschnitt 2.1.1[4. RFC 7469 Section 2.1. Response Header Field Syntax<\/a>] Da nur der Dienstbetreiber \u00fcber den dazugeh\u00f6rigen privaten Schl\u00fcssel verf\u00fcgt, ist ein Missbrauch durch Dritte ausgeschlossen. \u00dcbermittelt nun n\u00e4mlich ein Angreifer bei einem MITM-Angriff den zu seinem Zertifikat geh\u00f6renden \u00f6ffentlichen Schl\u00fcssel, kann der Browser mit Hilfe des PINs erkennen, dass dieser Schl\u00fcssel nicht dem Dienstbetreiber geh\u00f6rt und den Angriff damit auffliegen lassen.<\/p>\n Eine Schwachstelle bleibt jedoch. Damit das beschriebene Verfahren funktioniert, muss die erste Verbindung, die ein Client zum Server aufbaut, integer und vertrauensw\u00fcrdig sein. Findet bereits beim ersten Verbindungsaufbau ein MITM-Angriff statt, kann der Angreifer einen zu seinem \u00f6ffentlichen Schl\u00fcssel passenden Hash \u00fcbermitteln und das beschriebene Verfahren damit aushebeln.<\/p>\n Es existiert also ein gewisses Henne-Ei-Problem, welches im folgenden Abschnitt kurz angerissen wird.<\/p>\n Nein, mit TOFU ist an dieser Stelle kein Nahrungsmittel gemeint. TOFU steht in diesem Kontext f\u00fcr das Trust-On-First-Use-Prinzip, welches die c’t in ihrem Artikel „Zertifikate festnageln“ erl\u00e4utert.[5. Schmidt, J\u00fcrgen: Festgenagelte Zertifikate: TLS wird sicherer durch Certificate Pinning, in: c’t magazin f\u00fcr computer technik, Nr. 23, 17.10.2015, S. 121, Kasten „TOFU: Trust On First Use.]<\/p>\n Das darin beschriebene Henne-Ei-Problem besteht darin, dass man zuerst eine sichere Verbindung ben\u00f6tigt, um die erforderlichen Informationen zu erhalten, mit denen zuk\u00fcnftige Verbindungen gesichert werden k\u00f6nnen.<\/p>\n Mittlerweile sollte jedoch bekannt sein, dass es keine hundertprozentige Sicherheit gibt. Damit ist der beschriebene Schutz besser als gar keiner. In der Praxis kann Certificate Pinning daher in sehr vielen F\u00e4llen helfen, die Sicherheit vertraulicher Kommunikation zu steigern.<\/p>\n Dieser Abschnitt beschreibt, wie man Certificate Pinning auf dem eigenen Server konfigurieren kann. Es wird dabei auf notwendige Vor\u00fcberlegungen eingegangen und die Berechnung der PINs beschrieben. Im Anschluss wird das Certificate Pinning beispielhaft an einem NGINX-Server demonstriert.<\/p>\n In den vorangegangenen Abschnitten wurde erl\u00e4utert, wie Man-In-The-Middle-Angriffe durch Certificate Pinning erheblich erschwert werden k\u00f6nnen. Nun stellt sich die Frage, welchen \u00f6ffentlichen Schl\u00fcssel man festnageln m\u00f6chte. Denn Certificate Pinning kann auf jeden \u00f6ffentlichen Schl\u00fcssel der gesamten Zertifizierungskette angewendet werden. So kommen sowohl das eigene Serverzertifikat, als auch das der Intermediate CAs und das der Root CA in Frage.[6. Schmidt, J\u00fcrgen: Sicher mit Pin: Zertifikats-Pinning auf dem eigenen Server, in: c’t magazin f\u00fcr computer technik, Nr. 23, 17.10.2015, S. 122, Spalte 1.]<\/p>\n Pinnt man den \u00f6ffentlichen Schl\u00fcssel einer Intermediate CA oder gar einer Root CA, so werden alle von diesen Zertifizierungsstellen ausgestellten Zertifikate vom Browser als g\u00fcltig und sicher akzeptiert. Daher erscheint es am sichersten, wenn man den \u00f6ffentlichen Schl\u00fcssel des eigenen Serverzertifikats festnagelt. Hierbei muss allerdings folgendes Risiko beachtet werden.<\/p>\n Wird der Schl\u00fcssel durch Kompromittierung unbrauchbar, oder geht durch Hardwaredefekt verloren, k\u00f6nnen Benutzer die gesicherten Dienste eventuell nicht mehr nutzen. Denn die Browser haben den Pin gespeichert und werden vor Ablauf der Lebensdauer keinen neuen Pin akzeptieren. Die Lebensdauer kann je nach Konfiguration mehrere Wochen bis Monate betragen.[7. Schmidt, J\u00fcrgen: Sicher mit Pin: Zertifikats-Pinning auf dem eigenen Server, in: c’t magazin f\u00fcr computer technik, Nr. 23, 17.10.2015, S. 122, Spalte 2.]<\/p>\n Um das im vorigen Absatz beschriebene Risiko zu minimieren definiert RFC 7469 die zus\u00e4tzliche Verwendung eines Backup-PINs. Dabei wird ein Hash-Wert \u00fcber den \u00f6ffentlichen Schl\u00fcssel eines Schl\u00fcsselpaares gebildet, welches aktuell noch nicht genutzt wird.[8. RFC 7469, Abschnitt 4.3. Backup Pins<\/a>] Dies kann zum Beispiel dadurch erreicht werden, dass ein Hash-Wert f\u00fcr den \u00f6ffentlichen Schl\u00fcssel eines Certificate Signing Request (CSR)<\/a> generiert wird.<\/p>\n Der Backup-Pin wird ebenfalls \u00fcber ein HTTP-Header-Feld ausgeliefert und vom Browser eines Clients gespeichert. Der erzeugte Backup-CSR sollte sicher offline aufbewahrt werden. Er kann genutzt werden, um ein neues Zertifikat f\u00fcr die entsprechende Domain ausstellen zu lassen. Auf diese Weise k\u00f6nnen Zertifikate verl\u00e4ngert bzw. erneuert werden, ohne dass der Zugriff auf die entsprechende Domain unterbrochen wird.<\/p>\n In diesem Abschnitt wird eine konkrete Backupstrategie f\u00fcr den Backup-Pin beschrieben.<\/p>\n Der f\u00fcr den Backup-Pin verwendete CSR ist sicher aufzubewahren. Denn mit ihm kann ein Zertifikat f\u00fcr eine Domain bzw. einen Host ausgestellt werden, welches von Clients als g\u00fcltig anerkannt wird, da sie den dazugeh\u00f6rigen Backup-Pin gespeichert haben.<\/p>\n Ich pers\u00f6nlich speichere den CSR und den dazugeh\u00f6rigen privaten Schl\u00fcssel in KeePassX[9. The Official KeePassX Homepage<\/a>]. Auf diese Weise werden die Informationen sicher in einer Datenbank mit einer 256 Bit AES-Verschl\u00fcsselung abgelegt. Die KeePassX-Datenbank selbst bewahre ich in einem TeamDrive[10. TeamDrive Homepage<\/a>]-Space auf. Dadurch wird die Datenbank sicher auf meine Endger\u00e4te synchronisiert, so dass die Daten auch bei Ausfall eines Endger\u00e4ts erhalten bleiben.<\/p>\n Die lokalen Datentr\u00e4ger der zur TeamDrive-Synchronisation verwendeten Endger\u00e4te sind ebenfalls verschl\u00fcsselt. So sind die Daten im Falle eines Diebstahls eines Endger\u00e4ts gleich doppelt gesch\u00fctzt. Erstens durch die Verschl\u00fcsselung des lokalen Datentr\u00e4gers und zweitens durch die verschl\u00fcsselte KeePassX-Datenbank.<\/p>\n Die ben\u00f6tigten PINs werden auf der Kommandozeile mit openssl<\/em> generiert.[11. RFC 7469: Appendix A. Fingerprint Generation<\/a>] F\u00fcr ein existierendes SSL-Zertifikat kann der Pin mit folgendem Code erzeugt werden:<\/p>\n Der erzeugte Pin wird auf der Standardausgabe ausgegeben und endet immer auf das Zeichen „=“.<\/p>\n F\u00fcr den Backup-Pin wird zun\u00e4chst ein neuer Certificate Signing Request erstellt:<\/p>\n \u00dcber den so erzeugten Certificate Signing Request (example.com.csr) wird nun ebenfalls ein Pin mit folgendem Code erzeugt:<\/p>\n Der erzeugte Backup-Pin wird ebenfalls auf der Standardausgabe ausgegeben und muss ebenfalls auf das Zeichen „=“ enden.<\/p>\n Sind die PINs erzeugt, kann anschlie\u00dfend der Webserver konfiguriert werden, diese auszuliefern. Neben der Pin-Direktive[12. RFC 7469: Abschnitt 2.1.1. The Pin Directive<\/a>] ist hier die Max-Age-Direktive[13. RFC 7469: Abschnitt 2.1.2. The max-age Directive<\/a>] von Bedeutung. Letztere gibt die Zeit in Sekunden an, f\u00fcr die ein Pin durch den Browser gespeichert wird.<\/p>\n F\u00fcr die ersten Tests sollte die Max-Age-Direktive auf wenige Minuten gesetzt werden. Dieser Wert sollte erst bei reibungslosem Betrieb auf mehrere Wochen erh\u00f6ht werden.<\/p>\n Das zus\u00e4tzliche Header-Feld muss im SSL-Block der NGINX-Konfiguration hinzugef\u00fcgt werden. Dazu wird folgender Code in den SSL-Block eingef\u00fcgt:<\/p>\n Dabei sind PRIMARY-PIN und BACKUP-PIN durch die entsprechenden PINs zu ersetzen. Die optionale includeSubDomains-Direktive[14. RFC 7469: Abschnitt 2.1.3. The includeSubDomains Directive<\/a>] gibt an, dass die \u00fcbermittelten PINs auch f\u00fcr alle Subdomains des Hosts gelten.<\/p>\n Anschlie\u00dfend muss die Konfiguration neue geladen werden, um diese zu aktivieren:<\/p>\n Certificate Pinning ist ein in RFC 7469 spezifizierter Standard, welcher heute bereits von den weit verbreiteten Browsern Chrome und Firefox unterst\u00fctzt wird. Auch die Konfiguration weit verbreiteter Webserver wie Apache, lighttpd und NGINX ist mit geringem Aufwand, wie hier am Beispiel von NGINX gezeigt, zu erledigen.<\/p>\n Lediglich die sichere Aufbewahrung des Backup-CSR ist sicherzustellen, um eine l\u00e4ngere Nichterreichbarkeit einer Domain vermeiden zu k\u00f6nnen.<\/p>\n Damit ist Certificate Pinning grunds\u00e4tzlich geeignet, die verschl\u00fcsselte Kommunikation im Internet noch sicherer zu machen.<\/p>\n Dieser Artikel beschreibt, was Certificate Pinning ist, wie es TLS\/SSL-Verbindungen sicherer macht und wie man es f\u00fcr den Webserver NGINX konfiguriert. Der Artikel steht in einer PDF-Version zum Download und Druck zur Verf\u00fcgung: Certificate_Pinning_mit_NGINX Einleitung Um zu verstehen, wie Certificate Pinning hilft, TLS\/SSL-Verbindungen sicherer zu machen, muss man sich zuerst der Schwachstelle der TLS\/SSL-Verschl\u00fcsselung bewusst [Weiterlesen…]<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_metis_text_type":"","_metis_text_length":0,"_post_count":0,"footnotes":""},"categories":[95],"tags":[371,304,305,372],"class_list":["post-1304","post","type-post","status-publish","format-standard","hentry","category-security-2","tag-certificate-pinnig","tag-nginx","tag-planet","tag-rfc-7469"],"_links":{"self":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/1304","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/comments?post=1304"}],"version-history":[{"count":24,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/1304\/revisions"}],"predecessor-version":[{"id":1508,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/1304\/revisions\/1508"}],"wp:attachment":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/media?parent=1304"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/categories?post=1304"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/tags?post=1304"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Einleitung<\/h2>\n
Certificate Pinning f\u00fcr TLS\/SSL<\/h2>\n
TOFU: Trust On First Use<\/h3>\n
Certificate Pinning auf dem eigenen Server<\/h2>\n
Vor\u00fcberlegungen<\/h3>\n
Backupstrategie<\/h3>\n
Die PINs berechnen<\/h3>\n
openssl x509 -noout -in certificate.pem -pubkey | openssl asn1parse -noout -inform pem -out public.key\r\nopenssl dgst -sha256 -binary public.key | openssl enc -base64\r\n<\/pre>\n
openssl genrsa -out example.com.key 2048\r\nopenssl req -new -key example.com.key -out example.com.csr\r\n<\/pre>\n
openssl req -noout -in example.com.csr -pubkey | openssl asn1parse -noout -inform pem -out example.com_csr.key\r\nopenssl dgst -sha256 -binary example.com_csr.key | openssl enc -base64\r\n<\/pre>\n
Konfiguration von NGINX<\/h3>\n
add_header Public-Key-Pins 'pin-sha256=\"PRIMARY-PIN\"; pin-sha256=\"BACKUP-PIN\"; max-age=300; includeSubDomains';\r\n<\/pre>\n
sudo service nginx reload\r\n<\/pre>\n
Fazit<\/h2>\n
Quellen:<\/h2>\n","protected":false},"excerpt":{"rendered":"