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

Was ist ein „False Positive“?

Ein False Positive ist ein Ergebnis einer Liste, welches aber aus einem legitimen Grund nicht dazu gehört.

Hat man zum Beispiel eine gewisse Logik eingebaut, welche in einem Chat nach Fluchwörtern sucht, kann es durchaus auch Wörter treffen, die keine Fluchwörter sind. Etwa, wenn Fluchwörter auf Englisch gesucht werden, die User aber Deutsch sprechen. Das sind dann False Positives.

Inputvalidierung von Passwörtern, Hashing, Rainbow Tables und Salting

Bei einem Passwort will man den Benutzer geradezu ermuntern, viele Sonderzeichen zu verwenden. Kann das zu einer Sicherheitslücke führen?

Nein. Ein Passwort wird in der Realität als erstes in einen Hash umgewandelt und niemals als Plaintext in der Datenbank gespeichert. Ob der Benutzer dann ein „script“ oder „onload“ in seinem Passwort hat, ist nicht wichtig, da es nie zur Ausführung kommt.

Ein Passwort gehasht sieht dann vielleicht so aus: YTM0NZomIzI2OTsmIzM0NTueYQ==

Eine Hashfunktion ist eine Einwegfunktion. Der Hashwert kann also nie in das Passwort zurückgeführt werden. Dies ist auch der Grund, warum auf allen Internetseiten ein zufälliges, neues Passwort erstellt wird, wenn man sein altes Passwort vergessen hat. Gibt der Benutzer sein Passwort ein, wird es ebenfalls gehasht und mit dem gespeicherten Hash in der Datenbank verglichen.

Wenn nun ein Angreifer eine Tabelle mit Passwörtern ergattert hat, kann er alle möglichen Passwörter hashen und dann den Hash mit der Tabelle vergleichen. Beziehungsweise nimmt er nicht alle möglichen Kombinationen, sondern verwendet dafür eine sogenannte Rainbow Table, auf der die meistgenutzten Passwörter stehen. Der Angreifer hasht also ein Passwort der Rainbow Table nach dem anderen und schaut, ob der Hash in seiner geklauten Tabelle vorkommt.

Um es einem Angreifer nun zusätzlich schwer zu machen, kann man ihm die Suppe gehörig versalzen (Brüllwitz). Der Benutzer gibt ein Passwort ein und an dieses Passwort hängen wir noch einen sogenannten „Salt“, bevor wir das alles verhashen und in der Tabelle speichern. So wird aus aus dem Passwort „MeineEhefrau“ zum Beispiel „MeineEhefrau))%*ç%kkkk“. So wird das Anwenden einer Rainbow Table enorm erschwert.