Wenn ich hier mal kurz etwas Aufklärungsarbeit leisten darf:
TLS(SSL)-Verschlüsselung dient ja gerade dazu, die beschriebenen man-in-the-middle Angriffe zu verhindern. Wenn ich über eine unverschlüsselte Verbindung meine POP3-Daten übermittel, kann die *jeder* Rechner, der dazwischensteckt (und das sind in der Regel 5-15 Stück) mitlesen. Kommt natürlich im Normalfall, in dem der Traffic nur über Router eures ISP und irgendwelche Verteiler im RZ des eMail-Anbieters läuft nicht vor. Bei LAN-Parties ist die Gefahr da schon wesentlich höher, wenn man jeden Traffic grundsätzlich über den Proxy eines (unseriösen) Drittanbieters laufen lässt, kann man seine Kennwörter eigentlich gleich auf Flugblättern verteilen.
Hier greift nun TLS. Client und Server tauschen Schlüssel aus, so dass die vom Client verschickten Daten nur vom (End-) Server gelesen werden können und umgekehrt die vom Server kommenden Daten nur vom ursprünglichen Client:
Server < Schlüsselaustausch > Client
Das ganze ist insofern trotzdem angreifbar, als dass sich ein "man in the middle" dazwischenschalten und sich zur einen Seite hin als Server und zur anderen hin als Client ausgeben kann:
Server < Schlüsselaustausch > man in the middle < Schlüsselaustausch > Client
Da der "man in the middle" die Kontrolle über die Schlüssel besitzt, kann er den Verkehr ver- und entschlüsseln. Die vom Client kommenden Daten entschlüsselt er also erst mit dem Schlüssel, den er dem Client vorher zugewiesen hat und verschlüsselt sie dann erneut, um sie dann dem Server zukommen zu lassen.
Die Idee ist natürlich nicht neu und so hat man sich was kluges ausgedacht um solche Angriffe zu verhindern: Zertifikate. Die Idee dahinter ist, dass sich ein Server durch ein Zertifikat "ausweisen" soll. Ein man in the middle könnte dann zwar versuchen sich in den Schlüsselaustauschprozess einzuklinken, der Client würde aber bemerken, dass es sich nicht um den Server handelt. Die wichtigste Angabe in einem solchen Zertifikat ist die Adresse des Servers.
Nun ist das ganze noch immer reichlich unsicher, kann doch jeder ein Zertifikat nach seinem gusto erstellen und da eintragen, was immer er will. Auch auf die Idee sind die "Guten" vor den "Bösen" gekommen und entwarfen das Prinzip der signierten Zertifikate. Hierbei sollen sog. CAs (Certificate Authorities) die Zertifikate prüfen und sie einzeln signieren, falls sie korrekt und die Aussteller vertrauenswürdig sind. Damit der Client diese signierten Zertifikate als gültig anerkennt, muss er ein sog. Root-Zertifikat besitzen. Alle damit signierten Zertifikate sieht er dann als gültig an. Wenn ihr mal in den Einstellungen eures Browsers kramt (Firefox: Edit - Preferences - Advanced - Certificates - Manage Certificates - Authorities), werdet ihr eine Liste der Root-Zertifikate finden, die bei eurem Browser mitgeliefert sind. Thawte usw. Jedes von diesen CAs signierte Zertifikat seht ihr nun als gültig an. Ein man in the middle kann zwar ein Zertifikat ausstellen, was so aussieht, als käme es vom Zielserver, er hat es jedoch nicht signieren lassen. Das merkt der Browser und gibt eine Warnmeldung aus bzw. verweigert den Datenverkehr ganz.
Wie so ziemlich alles ist das aber dann unsicher, wenn ein Bösewicht direkten Zugriff auf den Clientrechner hat. Jede Verschlüsselung wird z.B. durch die Installation eines Keyloggers unwirksam, in diesem Fall wird das ganze aber etwas eleganter und weitaus unauffälliger gelöst. Das besagte Programm leitet nicht nur den Datenverkehr über einen eigenen Proxy um (was die Verschlüsselung, wie oben beschrieben, nicht kompromittieren würde), sondern es installiert auch noch ein eigenes Root-Zertifikat. Dadurch sieht der Client das "zwischengeschaltete" Zertifikat des man in the middle als genauso gültig an, wie bspw. ein von Thawte signiertes.
Vereinfachtes Schema:
Zielserver (Identität durch Thawte bestätigt) < Schlüsselaustausch > man in the middle (gibt sich als Zielserver aus, falsche Identität durch Bösewicht bestätigt) < Schlüsselaustausch > Client (vertraut Thawte und Bösewicht, weil deren Root-Zertifikate installiert sind)
Fazit: Ist der Clientrechner dicht und die Verschlüsselung ausreichend, so können auch hunderte men in the middle euren Daten nichts anhaben, sobald der Client fällt, fällt die gesamte Sicherheit.
Der Vollständigkeit halber sei noch angemerkt, dass das bisherige System nicht gerade optimal ist. Die großen CAs signieren für gewöhnlich nur für ne Menge Geld (mind. 150$/Jahr). Alternative CAs (bspw. cacert.org) bieten zwar ähnliche Sicherheit, ihre Rootzertifikate bleiben den meisten Surfern aber vorenthalten, denn die großen Browserherstellern nehmen sie nur dann in die Standardinstallation auf, wenn sie eine kleine "Aufwandsentschädigung" erhalten. Jede CA, die diese blechen muss, übersteht das nur, wenn sie für das signieren ne Menge Geld verlangt, eine Art Teufelskreis also. Das ganze führt nicht etwa zu mehr Sicherheit (wie immer behauptet wird: "Wir brauchen xy $ um zu prüfen, ob XY wirklich vertrauenswürdig ist!"), sondern eher zu weniger Sicherheit. Kleinere Sitebetreiber können sich ein signiertes Zertifikat nämlich nicht leisten, eine man of the middle Attacke lässt sich somit nicht erkennen. Eine Besserung der Lage ist in Sicht: Mozilla steht offenbar kurz davor das cacert.org Root-Zertifikat standardmäßig einzubinden. Bis dahin muss es jeder Surfer manuell installieren. Aber das nur nebenbei erwähnt
Hoffe etwas Licht ins Dunkel gebracht zu haben.
wenn dann Sorgen eine Menge Router zwischen dir und mir dafür das du das hier Lesen kannst 
und es ist nunmal so das du gerouteten Verkehr nicht abhören kannst, ausser du Gräbst eine Leitung aus und klemmst dich da dazwischen.
