05.11.2013 Aufrufe

Zahn - Unix-Netzwerkprogramminerung mit Threads, Sockets und SSL

Zahn - Unix-Netzwerkprogramminerung mit Threads, Sockets und SSL

Zahn - Unix-Netzwerkprogramminerung mit Threads, Sockets und SSL

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

316 6 Netzwerkprogrammierung <strong>mit</strong> <strong>SSL</strong><br />

<strong>und</strong> ServerHello.random) <strong>mit</strong> ein. Mit dem Master-Secret wird dann eine<br />

abschließende ServerFinished-Meldung verschlüsselt <strong>und</strong> an den Client<br />

übertragen. In diese Meldung sind die kryptographischen MD5- <strong>und</strong> SHA-<br />

1-Hashwerte über alle bislang ausgetauschten Handshake-Nachrichten eingebettet.<br />

Der Client berechnet seinerseits das Master-Secret <strong>und</strong> kann nun feststellen,<br />

ob die vom Server generierte ServerFinished-Meldung korrekt ist.<br />

Ist dies der Fall, so hat der Server nachgewiesen, daß er im Besitz des zum<br />

Public-Key passenden privaten Schlüssels ist.<br />

Identitätsabgleich zwischen Kommunikationspartner <strong>und</strong> Zertifikat<br />

Technisch gesehen besteht nun zwischen Client <strong>und</strong> Server eine komplett aufgebaute,<br />

<strong>SSL</strong>-gesicherte Netzwerkverbindung. Bildlich gesprochen wurde bislang<br />

aber lediglich die (digitale) Unterschrift geprüft <strong>und</strong> das Gegenüber (der<br />

Server) ist offensichtlich in der Lage, diese zu leisten. Ob der vorgezeigte Personalausweis<br />

(das digitale Zertifikat) aber tatsächlich echt ist <strong>und</strong> ob die darüber<br />

identifizierte Person (der Server) das ursprünglich gewünschte Gegenüber ist,<br />

wurde bisher hingegen noch nicht geklärt. Genausogut wie <strong>mit</strong> dem echten<br />

Server könnte es der Client derzeit auch <strong>mit</strong> einem vorgeschalteten Server,<br />

dem sogenannten Man-in-the-Middle zu tun haben, der sich wie in Abb. 6.2<br />

zu sehen in die Kommunikation einklinkt <strong>und</strong> die übertragenen Daten abhört.<br />

Client<br />

Zertifikat anfordern<br />

gefälschtes Zertifikat Z’<br />

Datenaustausch<br />

Man<br />

in the<br />

Middle<br />

Zertifikat anfordern<br />

echtes Zertifikat Z<br />

Datenaustausch<br />

Server<br />

Abb. 6.2. Man-in-the-Middle-Attacke<br />

Der Man-in-the-Middle unterhält dazu in beide Richtungen je eine <strong>SSL</strong>-<br />

Verbindung. Dem Client auf der linken Seite präsentiert der Eindringling<br />

anstatt des echten Serverzertifikats Z ein eigenes, meist selbst ausgestelltes<br />

Zertifikat Z ′ , agiert ansonsten aber wie der eigentliche Server. Gegenüber<br />

dem Server auf der rechten Seite tritt der Man-in-the-Middle darüber hinaus<br />

als ganz normaler Client auf. Sämtliche Anfragen des Clients leitet der<br />

Eindringling nun an den Server weiter <strong>und</strong> dessen Antworten liefert er wiederum<br />

an den Client zurück. Solange der Client das vom Man-in-the-Middle<br />

präsentierte, gefälschte Serverzertifikat Z ′ nicht gewissenhaft prüft, bleibt der<br />

Eindringling unsichtbar <strong>und</strong> der Client wird die Man-in-the-Middle-Attacke<br />

nicht bemerken.<br />

Im nächsten Schritt muß vom Client also das Zertifikat des Servers überprüft<br />

werden. Um festzustellen, ob das präsentierte Zertifikat echt ist, gibt es prinzipiell<br />

zwei Möglichkeiten:

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!