SSL Ist aktiv

SSL (Secure Socket Layer) sollte wohl den meisten ein Begriff sein, das ist dieses lustige kleine „s“ was manchmal hinter dem „http“ in der Adresszeile des Browsers auftaucht (siehe Bild). In dieser Serie möchte ich euch erklären wie SSL in der Theorie funktioniert und wie ihr es in euren Applikationen nutzen könnt.

Im letzten Teil haben wir die Serverseitige Authentifizierung besprochen. Heute wollen wir die Beidseitige Authentifizierung durchsprechen, welche auch Client Authentifizierung genannt wird.

Wenn man mit dem Browser im Internet unterwegs ist wird man eigentlich nie auf eine Beidseitig Authentifizierte SSL Verbindung treffen. Erst wenn man auf den Server und seine Architektur im Hintergrund schaut wird man diese Art von Sicherheit treffen.

Dabei ist das System hinter der Beidseitigen Authentifizierung ähnlich simpel wie bei der Serverseitigen. Wie der Name schon sagt, müssen sich diesmal beide Parteien gegenseitig authentifizieren. Wenn wir das nun auf unser Beispiel mit der Post aus dem ersten Teil anwenden siehts wie folgt aus: (Post ist der Server wir sind der Client)

Ihr kommt zur Post und wollt euer Paket abholen, nun ist erstmal die Post (als Server) gefragt und muss uns beweisen, dass es wirklich die Post ist und sendet uns ihr Zertifikat. Wir prüfen das Zertifikat und entscheiden, dass wir dem Zertifikat vertrauen.

Nun sagt die Post aber, dass sie auch einen Beweis dafür haben wollen, dass wir auch der sind, für den wir uns ausgeben und verlangt von uns ebenfalls ein Zertifikat. Wir senden nun also unser Zertifikat zur Post und warten auf die Bestätigung oder die Absage vom Server.

Erst wenn beide Seiten die gegenseitigen Zertifikate akzeptiert haben ist die verschlüsselte Verbindung aufgebaut und eine Kommunikation kann stattfinden. Sollte eine der Parteien unzufrieden mit dem Zertifikat sein wird der Vorgang abgebrochen und muss von vorn begonnen werden.

Wie ihr euch denken könnt ist diese Art von Authentifizierung viel sicherer als die Serverseitige, bei der sich nur eine Seite ausweisen muss, ist aber natürlich auch mit einem höheren Aufwand in der Administration verbunden. Das ist auch der Grund warum man beim Browsen nur auf Serverseitige Authentifizierung stößt.

Denn im Internet ist es eigentlich für uns uns Nutzer wichtig, dass wir mit Sicherheit wissen an wen wir unsere Daten senden. Der Server stellt unsere Identität normalerweise durch einen Login oder eine Anmeldung fest. Würde man eine Beidseitige Authentifizierung für das Internet wollen, müsste jeder Server da draussen unser Zertifikat kennen, und das wäre eine unlößbare Aufgabe 😉

Bei Internen Systemen ist die Sache da deutlich einfacher, da weiß man für gewöhnlich schon vorher, welche Systeme mit welchen kommunizieren müssen, und kann so die nötigen Zertifikate in die Systeme Pflegen. So geht man dann sicher dass nur diese Systeme miteinander Sprechen und sich nicht jemand ins System schleichen kann.

Typischer Aufbau

So baut man Server so auf, dass Sie auf der Access Seite (Internetanbindung) sich gegenüber dem Client authentifizieren, aber auf der internen Seite nur über beidseitige Authentifizierung an ihre Daten kommen.

Teil 1: Serverseitige Authentifizierung und Zertifikate
Teil 2: Beidseitige Authentifizierung
Teil 3: Der SSL Handshake
Teil 4: Serverseitige Authentifizierung mit Java