Monat: Oktober 2016

Was ist Mutual SSL Authentication?

Mutual Authentication referenziert sich darauf, dass sich zwei Parteien gegenseitig authentifizieren. Es wird auch zertifikatbasiertes gegenseitiges Authentifizieren genannt. Die zwei Parteien verifizieren sich dabei anhand der ausgetauschten digitalen Zertifikaten, so dass jede Partei sicher sein kann, mit wem sie spricht.

Es geht also darum, dass sich ein Client (etwa ein Webbrowser) einem Server gegenüber authentifiziert. Der Server wiederum macht dasselbe beim Client. Der Server prüft dafür das Public Key Certificate/digitale Zertifikat, welches von einer zertifiziertern Stelle, der Certificate Authority (CA) ausgestellt wurde. Die Authentifizierung im Netz basiert auf Zertifikaten, weshalb Anbieter wie Verisign Microsoft Certificate Server ein wichtiger Teil der Prozesses sind. Grosse Firmen haben dabei üblicherweise ihre eigene CA.

Die benötigten Schritte

Grob betrachtet sind bei einer Mutual Authentication folgende Schritte durchzuführen:

1. Ein Client beantragt Zugang zu einer geschützten Ressource

2. Der Server präsentiert sein Zertifikat dem Client

3. Der Client verifiziert dieses Zertificate

4. Ist der Client zufrieden, sendet er sein Zertifikat dem Server

5. Der Server überprüft die Eigenschaften des Clients

6. Ist der Server zufrieden, gibt er dem Client Zugang zu der gewünschten Ressource

Der Unterschied zur SSL Authentifizierung

Mutual Authentication funktioniert ähnlich wie die SSL (Secure Socket Layer) Authentifizierung. Der Unterschied ist jedoch, dass noch die Client Authentifizierung mittels Zertifikaten dazukommt. Mutual Authentication wird deshalb auch Two way SSL authentication genannt.

Will man genau verstehen, bei einer SSL Authentifizierung geschieht, sollte man die Spezialitäten der Handshake Nachrichten kennen.

SSL Authentication Handshake

Bei der SSL Authentifizierung wird dem Client das Server Zertifikat angezeigt – Der Server authentifiziert sich also gegenüber dem Client. Der Client probiert dann die CA des Serverzertifikat in der Liste der CA’s zu finden, denen er vertraut (trusted CA’s). Während des ganzen Prozesses werden neun Nachrichten ausgetauscht.

1. Der Client sendet die Nachricht ClientHello mit einem Vorschlag von SSL Optionen

2. Der Server antwortet mit dem ServerHello und wählt darin die SSL Optionen

3. Der Server schickt sein Server Zertifikat

4. Der Server bestätigt seine Nachricht mit einem ServerHelloDone

5. Der Client schickt die Session Key Information in einer ClientKeyExchange Nachricht – Verschlüsselt mit dem Public Key des Servers, welche er aus dem Zertifikat entnommen hat

6. Der Client schickt die ChangeCipherSpec Nachricht um die gewählte Verschlüsselungsmethode zu bestätigen

7. Der Client schickt eine Finished Nachricht, damit der Server die aktivierten Optionen prüfen kann

8. Der Server schickt ebenfalls eine ChangeCipherSpec Nachricht, um die gewählte Verschlüsselungsmethode zu aktivieren.

9. Der Server schickt ebenfalls eine Finished Nachricht zum Abschluss

Mutual SSL Authentication

Bei der Mutual SSL Authentication authentifizieren sich der Server und der Client gegenseitig. Um einen verschlüsselten Kanal zu öffnen werden insgesamt 12 Nachrichten verwendet.

1. Der Client sendet die Nachricht ClientHello mit einem Vorschlag von SSL Optionen

2. Der Server antwortet mit dem ServerHello und wählt darin die SSL Optionen

3. Der Server schickt sein Server Zertifikat

4. Der Server verlangt das Zertifikat des Kunden in einem CertificateRequest, damit die Verbindung gegenseitig authentifiziert werden kann

5. Der Server bestätigt seine Nachricht mit einem ServerHelloDone

6. Der Client antwortet mit seinem Client Zertifikat

7. Der Client schickt die Session Key Information in einer ClientKeyExchange Nachricht – Verschlüsselt mit dem Public Key des Servers, welche er aus dem Zertifikat entnommen hat

8. Der Client schickt eine CertificateVerify Nachricht, um den Server wissen zu lassen, dass er der Besitzer des Zertifikats ist

9. Der Client schickt die ChangeCipherSpec Nachricht um die gewählte Verschlüsselungsmethode zu bestätigen

10. Der Client schickt eine Finished Nachricht, damit der Server die aktivierten Optionen prüfen kann

11. Der Server schickt ebenfalls eine ChangeCipherSpec Nachricht, um die gewählte Verschlüsselungsmethode zu aktivieren.

12. Der Server schickt ebenfalls eine Finished Nachricht zum Abschluss

Die Nachrichten mit Wireshark aufgenommen:

mutualauthenticationpic

Klick mich für das Bild in gross

Blockchain Einführung

Seit dem Jahre 1981 suchen gescheite Leute Lösungen, um das Internet sicher zu machen und die Privatsphäre jedes Einzelnen zu schützen. Wie auch immer man den Prozess gestaltete, immer war eine Drittpartei involviert. Hat man mit einer Kreditkarte bezahlt, weiss etwa das Kreditkartenunternehmen genau, was man wo gekauft hat. Im Jahre 1993 gab es eine brilliante Erfindung des Mathematikers David Chaum namens „eCash“, welches perfekt dafür geeignet war, virtuelles Geld durch das Internet zu schicken. Das Problem war, dass im Jahre 1993 noch niemand an Sicherheit interessiert war, so dass die Chaum’s Firma im Jahre 1998 bankrott ging.

Im Jahr 2008 ist die globale Finanzindustrie im Zuge der Subprime Krise gecrasht. Zu dieser Zeit wurde ein neues Protokoll vorgestellt, welche eine Punkt-zu-Punkt Verbindung für eine elektronische Zahlung zulassen soll: Bitcoin.

Bitcoin ist eine sogenannte Crypto-Währung/Cryptocurrency oder auch digitale Währung. Der Unterschied zu einer normalen Währung ist, dass diese Währung von keinem Land kontrolliert wird.

Das Bitcoin-Protokoll definiert Regeln, welche die Integrität von ausgetauschten Daten sicherstellt, ohne über eine Drittpartei gehen zu müssen.

Viele sind der Meinung, dass Bitcoin und das darunterliegende Blockchain Protokoll die nächste grosse Revolution nach dem Internet ist. Sicher ist, dass es so etwas noch niemals zuvor gab: Transaktionen, die einander vertrauen und zwei Parteien verbinden, welche sich durch das System authentifizieren und angetrieben werden von reinem Eigeninteresse – statt riesigen Firmen, die auf reinen Profit aus sind.

Wobei die grossen Firmen natürlich auch nicht dumm sind. Viele haben bereits angefangen, Forschungsteams auf Bitcoin und Blockchain anzusetzen. Wenn es wirklich die Zukunft ist, müssen Firmen bereit sein, auf den fahrenden Zug aufzuspringen, um nicht mit heruntergelassenen Hosen dazustehen.

Blockchain ist also das Protokoll hinter Bitcoin. Blockchain ist die Grundlage eines Netzwerks einer wachsenden Anzahl von globalen Zweigstellen/Hauptbüchern (namens „blockchains“) – wobei die Bitcoin Blockchain die grösste davon ist. Der Begriff „Hauptbuch“ kommt dabei aus der Buchhaltung. Mit dem Hauptbuch bezeichnet man alle Konten, mit denen eine Firma ihre Geschäftsfälle bearbeitet (Aktiv-/Passivkonten).

Die Idee von Blockchain ist also simpel: Jeder kann Geld direkt und sicher an eine Person senden, ohne durch eine Bank oder eine Kreditkartenfirma zu gehen.

Ich werde, sobald es mir die Zeit erlaubt, tiefer in das Thema eintauchen und entsprechende Blogeinträge dazu schreiben, da mich das Thema enorm interessiert.

Wie starre Prozesse eine Firma in die Knie zwingen können

Wir hatten also dieses neue Projekt, welches hunderttausende von Dateien verarbeiten musste. Das Problem war, dass wir nicht sicher sein konnten, wie schnell die Performance im laufenden Betrieb schlussendlich sein würde. Und in den Testumgebungen hatten wir nicht genügend Testdaten, um die Auslastung im Produktionsumfeld auch nur annähernd zu erreichen.

Das war damals eine Java Spring JMS Webapplikation. Wie es zu deren Natur gehört, hatten wir eine Konfigurationsdatei, in der wir etliche Parameter (Anzahl Threads etc.) einstellen konnten.

Nun waren wir aber alles andere als „Agile“ aufgestellt. Wir hatten jeweils nur wenige Releases pro Jahr. Natürlich gab es einen Prozess für ausserordentliche Lieferungen: Wenn es irgendwo brannte, musste man schnell reagieren und eventuelle Bugs beseitigen. Diese Prozesse gingen aber relativ lange und brauchten immer eine Unmenge von administrativem Aufwand. Und wenn man etwas liefern/beheben wollte, war das meistens ein recht negatives Erlebis. Man musste sich quasi das Recht erkämpfen, doch bitte die Software korrigieren zu können, damit der Kunde die Applikation funktionsgerecht verwenden konnte.

Verstehen Sie mich nicht falsch. Natürlich muss man mit allen Mitteln (Unittests, automatisierten Integrationstests etc.) verhindern, dass eine solche Situation entsteht. Doch eine solche Abneigung gegenüber Veränderung empfand ich als sehr lästig. Und heutige Informatiksysteme sind so gross, komplex und unüberschaubar geworden und miteinander verwoben, dass es durchaus Folgereaktionen geben kann, die man so nicht erwartet hätte. Nur schon die Vorstellung, man könnte alle Folgereaktionen und Abhängigkeiten einer Einlieferung wissen, ist absurd.

Wir wollten also Fehler beheben. Wir wollten auch eine möglichst gute Performance hinkriegen. Doch in der Realität haben wir die Parameter der Konfigurationsdatei initial bestimmt, so gut wir diese verstanden haben, und nachfolgend nur noch einmal angepasst. Wenn man jedesmal einen Marathon laufen muss, um einen Wert in einer Datei zu ändern, lässt man es irgendwann sein und hofft, dass doch alles noch gut kommt.

Ich hätte mir gewünscht, dass wir die Parameter öfters hätten ändern können – Und zwar in kleinen Schritten, um zu verstehen, welche Parameter wirklich etwas an der Performance verändern und das System beschleunigen oder verlangsamen. Aber was wir uns auch überlegten, jeder Schritt endete in einem administrativen Prozess, bei denen wir höchstens zwischen „mühsam“ und „einigermassen erträglich“ haben wählen können.

Wenn ich dann höre, dass in „fully agile Projekten“ eine unkomplizierte Anpassung der Produktion jeden Tag möglich ist, werde ich schon ein wenig neidisch. Ob es in der Realität in agilen Projekten wirklich so unkompliziert vonstatten geht?