OpenSSL <http:\/\/openssl.org\/> as a library at first glance is complicated, and then you realise that a lot of the documentation <http:\/\/openssl.org\/docs\/ssl\/ssl.html> seems to be incomplete or missing.<\/p><\/blockquote>\n
Wie verbaut das System ist, zeigt folgende Beobachtung: es ist durchaus zul\u00e4ssig, eine eigene Authority zu definieren und deren Zertifikate in die Liste zu importieren. Zumindest mit den Browsern, in denen diese Stamm- und Zwischenzertifikate installiert sind, sollte alles reibungslos funktionieren. Tut es aber nicht unbedingt. In einem Versuch mit dem freien Anbieter http:\/\/www.CAcert.org kam heraus:<\/p>\n
- \n
- Firefox unter Windows 10 akzeptiert ein so signiertes Serverzertifikat als Ausnahme. Das gleiche gilt f\u00fcr die MicroSoft-Browser.<\/li>\n
- Firefox unter Ubuntu-Linux akzeptiert ein solches Zertifikat grunds\u00e4tzlich nicht, egal ob man die Stamm- und Zwischenzertifikate importiert oder nicht. Es wird keine Verbindung mit der Webseite aufgebaut.<\/li>\n
- Chrome unter Ubuntu-Linux akzeptiert das Zertifikat unter der Voraussetzung, dass man Stamm- und Zwischenzertifikat auf einem anderen Weg, beispielsweise mittels des Verwaltungsprogramms \u201eKleopatra\u201c, importiert und bearbeitet.<\/li>\n<\/ul>\n
Drei Browser \u2013 drei Verhaltensweisen. Mozilla, der Hersteller von Firefox, meint dazu<\/p>\n
.., because different browsers use different SSL stacks with different capabilities to find the missing certs, and it also depends on what other sites you have browsed to in that session and so whether the intermediate is in the cache.<\/p><\/blockquote>\n
Was soll man von einem System halten, dass nach Kommentaren der Macher nicht festen Regel folgt, sondern von den Launen der Programmierer und vom v\u00f6llig unverhersehbaren Verhalten der Nutzer abh\u00e4ngt? Auch an anderer Stelle ist OpenSSL in der Vergangenheit mit Schlampigkeiten aufgefallen: so scheinen die privaten Schl\u00fcssel deutlich weniger zuf\u00e4llig gewesen zu sein als notwendig, und auch zwischen verschiedenen Prozessen wiesen die Zufallszahlen Korrelationen auf. Mit den Leuten diskutieren zu wollen ist allerdings kaum m\u00f6glich. Da (angeblich) alles freiwillig passiert, reagiert man auf Kritik (wie bei anderen OpenSource-Paketen auch) mimosenhafter als die \u00fcblichen M\u00e4rchenprinzessinnen, und wer sich davon unbeeindruckt zeigt, muss mit verbalem Bashing rechnen. Aber man kann auch fragen, ob da wirklich Schlampigkeit am Werk war. In der englischen wikipedia findet man folgende Anmerkung zu OpenSSL:<\/p>\n
\u201cThe project has a budget of less than $1 million a year and relies in part on donations. Steve Marquess, a former CIA consultant in Maryland started the foundation for donations and consultancy contracts and garnered sponsorship from the United States Department of Homeland Security <https:\/\/en.wikipedia.org\/wiki\/United_States_Department_of_Homeland_Security> and the United States Department of Defense <https:\/\/en.wikipedia.org\/wiki\/United_States_Department_of_Defense> .[3] <https:\/\/en.wikipedia.org\/wiki\/OpenSSL#cite_note-wsj-3> \u201c<\/p><\/blockquote>\n
Gl\u00fccklicherweise ist man als Entwickler nicht an OpenSSL gebunden. Mit BotanSSL steht (mindestens) eine weitere SSL\/TLS-Bibliothek in C++ zur Verf\u00fcgung, die besser dokumentiert ist und manche der OpenSSL-Unzul\u00e4nglichkeiten nicht aufweist. Aber es stellt sich die Frage, was passiert, wenn der Branchenf\u00fchrer sich an gewissen Stellen nicht an die Norm gebunden f\u00fchlen sollte, sei es nun aus Gr\u00fcnden der \u201ek\u00fcnstlerischen Freiheit\u201c der Programmierer oder aufgrund nicht zur\u00fcckweisbarer W\u00fcnsche der Finanziers.
\nZur\u00fcck zum Problem des f\u00fcr normale Internetnutzer nicht durchschaubaren Zertifikatwesens. Ob um die Gelddruckmaschinen der Authorities etwas einzud\u00e4mmen oder aus was f\u00fcr Gr\u00fcnden auch immer hat sich die Zertifikat-Plattform \u201eLet’s Encrypt\u201c etabliert, hinter der sich eine \u201eInternet Security Research Group\u201c verbirgt, die sich haupts\u00e4chlich aus Vertretern der Internet-Industrie zusammensetzt (es w\u00e4re sicher interessant, Leute und Unternehmensbeziehungen zu untersuchen, um die Motivation f\u00fcr dieses Projekt besser verstehen zu k\u00f6nnen; m\u00f6glicherweise st\u00f6\u00dft man da auf \u00e4hnliche \u00dcberraschungen wie bei OpenSSL). Sie will globale Verschl\u00fcsselung erm\u00f6glichen, zun\u00e4chst im HTTP-Bereich, aber im Text wird auch der E-Mail-Bereich angesprochen, wenn auch technische Details bislang vollst\u00e4ndig fehlen. Genauso wichtige weitere Bereiche wie Telefonie oder Chat werden allerdings gar nicht erst angesprochen. Das Konzept basiert auf dem normalen X.509-Zertifikathandling, allerdings sind die Zertifikate im Gegensatz zu denen der Authorities kostenlos.<\/p>\nNoch scheint das Projekt nicht sonderlich weit gediehen zu sein. Die Bedienung ist einfach: man l\u00e4dt ein so genanntes CertBot-Programm und teilt diesem mit, man m\u00f6chte gerne ein Zertikat haben. Alles andere l\u00e4uft automatisch, was schon ein sehr gro\u00dfer Fortschritt gegen\u00fcber dem heutigen, selbst f\u00fcr Server-Administratoren komplexen Verfahren ist. Der CertBot erstellt ein Zertifikat und l\u00e4sst dieses in einem automatisierten Verfahren von einem Zentralserver signieren. Da anscheinend alle Browser-Hersteller kooperieren, werden diese Zertifikate anschlie\u00dfend auch problemlos akzeptiert. Ein echter Fortschritt? Wenn man von der einfachen Bedienung absieht, konzeptionell eher ein deutlicher R\u00fcckschritt. Wieso?<\/p>\n
Derzeit ist anscheinend nur das Verfahren f\u00fcr die Erstellung der Server-Zertifikate geregelt. Das Zertifikat wird automatisch erstellt, an einen Zentralserver gemeldet, und dieser \u00fcberpr\u00fcft im Gegenzug, ob unter der angegeben URL ein Server zu erreichen ist, der \u00fcber den privaten Schl\u00fcssel verf\u00fcgt. Ist das der Fall, wird das Zertifikat g\u00fcltig signiert. Weitere Kontrollen existieren nicht. Modellvorstellungen, wie das Konzept mit E-Mails funktionieren soll, sind noch nicht zu finden. Die wichtigsten Konsequenzen aus der automatischen Zertifikatausgabe hat nach dem derzeitigen Muster hat:<\/p>\n
- \n
- \u00a0Das eigentliche Sicherheitskonzept hinter den Zertifikaten \u2013 dass der Inhaber einer URL auch tats\u00e4chlich der ist, der er vorgibt zu sein \u2013 wird damit fallen gelassen. Es ist z.B. ohne Weiteres m\u00f6glich, sich vor\u00fcbergehend eine URL zu besorgen, sich daf\u00fcr ein Zertifikat erstellen zu lassen, und anschlie\u00dfend darauf zu warten, dass irgendjemand die URL \u00fcbernimmt und man versuchen kann, irgendwelchen Unfug zu treiben. Versprechen heutige Authorities auch noch irgendwelche mit 50.000 \u20ac oder mehr dotierte Garantien, dass sie sich von der Seriosit\u00e4t des Inhabers \u00fcberzeugt haben \u2013 bei Let’s Encrypt gibt es keine mehr. Der normale Nutzer kann aber nur mit sehr viel Aufwand zwischen \u201eLet’s Encrypt\u201c- und teuren Standardzertifikaten differenzieren, oder mit anderen Worten: de fakto ist der letzte Rest der versprochenen Sicherheit dahin.<\/li>\n
- Die Erstellung von g\u00fcltigen Zertifikaten ist an die Kontrolle \u00fcber den Server gebunden, da der CertBot nur von Administratoren aufgerufen werden kann. Wer seine Seiten irgendwo hostet, kommt folglich an solche Zertifikate selbst nicht dran, sondern muss beim Provider \u201ebitte-bitte\u201c machen oder hoffen, dass der auf den Zug aufspringt und das f\u00fcr ihn ohne Aufforderung \u00fcbernimmt.<\/li>\n<\/ol>\n
Man mag nun argumentieren, die Beschreibungen der Modelle seien noch nicht ausgereift oder es w\u00fcrden noch Work-Arounds f\u00fcr das eine oder andere Problem entwickelt. Beispielsweise k\u00f6nnte der Zentralserver ja nur ein Zertifikat f\u00fcr eine Webseite zulassen und bei erneuter Beantragung nach dem in 1. erw\u00e4hnten Angriffsmodell das alte zur\u00fcckziehen. Damit w\u00fcrde aber nur das Tor zu massiven Denial-of-Service-Angriffen ge\u00f6ffnet, denn ein Angreifer mit entsprechenden Mitteln k\u00f6nnte beliebig Zertifikate laufender Server ung\u00fcltig werden lassen. Wie man es dreht oder wendet: ein automatisiertes Zentralsystem versagt genau bei den Angriffsszenarien in epischer Breite, f\u00fcr deren Verhinderung das Zertifikatsystem urspr\u00fcnglich einmal entwickelt worden ist.<\/p>\n
Zusammengefasst: Let’s Encrypt ist so notwendig wie ein Pickel auf der Nase, da die Sicherheit eher geringer ist als wenn jeder selbst seine Zertifikate erstellt und signiert. Mit solchen selbst signierten Zertifikaten kann man nach den aktuellen Standardprotokollen heute ebenfalls arbeiten, indem man solche Zertifikate als Ausnahmen zul\u00e4sst, aber die Browsern reagieren darauf mit f\u00fcr den Nutzer deutlich zu heftigen Meckereien oder, wie im Fall des Ubuntu-Firefox und m\u00f6glicherweise der zuk\u00fcnftigen Standardreaktion, mit einer protokollwidrigen Arbeitsverweigerung. Let’s Encrypt dient bestenfalls zur Rettung f\u00fcr das als inzwischen nur noch bedingt taugliche Zertifikatkonzept, und mit der eigenwilligen Interpretation, welche Zertifikate sicher sind und welche nicht, wird der Internetnutzer gezwungen, v\u00f6llig entm\u00fcndigt alles einer anonymen Organisation zu \u00fcberlassen, die letzten Endes doch f\u00fcr nichts garantiert oder gar \u2013 aber das ist jetzt Verschw\u00f6rungstheorie \u2013 f\u00fcr die Interessen derjenigen arbeitet, vor denen man sich sch\u00fctzen will.<\/p>\n
Jeder Polizist r\u00e4t, sein Haus und sein Eigentum selbst zu sichern, um Gaunern das Handwerk zu erschweren. Warum darf das nicht im Internet gelten? Weil irgendwann mal OpenSSL konstruiert wurde und jemand beleidigt sein k\u00f6nnte, wenn man die inzwischen unzul\u00e4nglichen Konzeptteile \u00fcber Bord wirft? Statt wie bei Let’s Encrypt weiterhin auf eine Zentralinstanz zu setzen und dem Nutzer eine wirksame Eigenverantwortung zu entziehen, sollte man ihm nicht besser mehr Kontrolle und Verantwortung \u00fcbertragen und ihn sein Eigentum selbst sch\u00fctzen lassen? Die Zertifikate, bei denen man sicher sein MUSS (es sind n\u00e4mlich gar nicht so viele, wie immer suggeriert wird), dass tats\u00e4chlich die angegebene Person oder Institution dahinter steckt, kann man auch selbst verwalten und muss nicht hoffen, dass eine anonyme Zentralinstanz keine falschen Daten ausliefert. Das entspr\u00e4che dem Konzept der Elektronischen Identit\u00e4t, die wir anderswo entwickelt haben. Die Bedienung w\u00e4re nicht komplizierter als bei Let’s Encrypt: ein EIBot erstellt die notwendigen Zertifikate und verwaltet sie. Das Konzept br\u00e4uchte noch nicht einmal neue Software-Entwicklungen: weist man die Browser an, selbst signierte Zertifikate nicht in schreiend bunten Warnfarben als \u201egef\u00e4hrlich\u201c, sondern schlicht als \u201eElektronische Indentit\u00e4ten\u201c zu kennzeichnen und den Rest dem EIBot zu \u00fcberlassen, w\u00e4re das vermutlich in 20 Programmzeilen zu realisieren. Auch E-Mails, Telefonie, Chats oder gar abgeschlossene Sicherheitsbereiche wie ein Unternehmen oder der zuk\u00fcnftige autonome Stra\u00dfenverkehr sind problemlos mit dieser Technologie einzubinden.
\nWie es weitergeht, bleibt abzuwarten. Weiterhin alles den US-Amerikern \u00fcberlassen, bei denen sich am ende herausstellt, dass doch wieder Homeland Security in irgendeiner Form dahinter steckt? Oder selbst einmal etwas in die Hand nehmen? Eine Alternative w\u00e4re nat\u00fcrlich noch dieses Kommunikationsmodell aus den 1920er Jahren:<\/p>\n![\"DSC_7439\"](\"http:\/\/gilbertbrands.de\/blog\/wp-content\/uploads\/2016\/06\/DSC_7439-300x225.png\")
<\/a><\/p>\nLetsEncrypt<\/a> als PDF-Version<\/p>\n","protected":false},"excerpt":{"rendered":"
In unserer elektronischen Welt der Handys und des Internets sind die meisten Informationen ohnehin nicht zu verbergen. Wer wann wo gewesen ist, l\u00e4sst sich aus dem Bewegungsprofil des Handys entnehmen, und wer welche Webseite besucht hat, geht aus den Verbindungsdaten hervor. Der einzige Schutz w\u00e4re Nichtbenutzung, aber wie es auf anderem Gebiet so sch\u00f6n hei\u00dft: … Let’s Encrypt<\/span> weiterlesen
![\"DSC_7439\"](\"http:\/\/gilbertbrands.de\/blog\/wp-content\/uploads\/2016\/06\/DSC_7439.png\")
<\/a><\/p>\n