E-Mail-Verschlüsselung Site-to-Site per PGP/GPG, S/MIME oder SSL/TLS?
Geht es um E-Mail-Verschlüsselung scheint PGP und S/MIME die erste Wahl zu sein. Dabei ist SSL/TLS -- richtig eingesetzt -- für die meisten Anwendungsfälle viel besser geeignet. Gerade wenn es darum geht die gesicherte Kommunikation zwischen zwei Unternehmen zu realisieren, ist SSL/TLS nicht nur die technisch erheblich bessere Wahl, sondern zu dem auch noch viel schneller und günstiger einzurichten. Leider wird viel zu häufig geurteilt: Was nix kostet taugt auch nix. Hier der Aufklärungsversuch.
PGP, GPG und S/MIME in der technischen Übersicht
Bei PGP/GPG und S/MIME besitzt eine Person (oder "ein Postfach") einen eigenen Schlüssel, der typischerweise auch auf die jeweilige E-Mail-Adresse ausgestellt ist. Dabei verschlüsselt schon der absendende Mailclient (=Outlook, Thunderbird, Kmail & Co.) die zu versendende E-Mail, also schon bevor die E-Mail überhaupt mittels SMTP an den eigenen Provider abgeschickt wird.
Der Vorteil: Auch der Provider von Absender oder Empfänger kann den Inhalt der E-Mail nicht mehr mitlesen. Etwaige Abgriffe der Postfächer, egal ob durch polizeiliche Beschlagnahme oder Auskuntfsersuchen oder durch einen Hacker-Zutritt in das Postfach, fördern stets nur die verschlüsselten E-Mails zutage.
Der Nachteil -- und das ist leider vielen nicht bewußt -- ist jedoch, daß PGP und S/MIME stets nur den eigentlichen Inhalt der Nachricht verschlüsseln können. Die Information aus dem Mailheader bleiben unverschlüsselt -- und damit auch die Information, wer an wen eine E-Mail mit welchem Betreff (!) geschickt hat. Aus Sicht eines Angreifers übrigens durchaus relevante Informationen im Rahmen eines "social engineering" oder auch "social hacking", denn mit diesem Insiderwissen kann zu Dritten eine besondere Vertrauensstellung aufgebaut werden, die diese unvorsichtig werden läßt ("Ihr Kollege Michael Stützing bearbeitet ja die Akten XY, ich müßte da schnell noch etwas wissen.")
Kurzum: Schon der Mailheader beinhaltet Daten, die aus Sicht einer Unternehmessicherheit schützenswert sind, die aber genausogut auch so bereits personenbezogene Daten sind, die dem Schutz des BDSG unterliegen.
Mindestens wenn ein Unternehmen im Betreff der E-Mail auch (besondere?) personenbezogene Daten über Dritte transportiert (Subject: Herr Klaus Müller hat Prostata-Krebs) muß festgehalten werden, daß dem nötigen Datenschutz mindestens grob fahrlässig nicht mehr genüge getan wird, weil eben diese Informationen total ungeschützt durch die Weltgeschichte verschickt werden. Oder würden Ärzte und Krankenkassen diese Informationen auf einer Postkarte versenden? Wohl kaum.
PGP und S/MIME bieten eine Ende-zu-Ende-Verschlüsselung, also vom Mailclient eines einzelnen Absenders hin zum Mailclient eines einzelnen Empfängers. Das heißt aber auch: Für jeden Beteiligten müssen eigene Schlüssel generiert und sicher ausgetauscht werden.
Es gibt Lösungen am Markt, die versuchen den Austausch der Schlüssel zu automatisieren, bzw. die die Verschlüsselung vom einzelnen Mailclient hin auf einen zentralen Ausgangs-/Eingangsserver verlagern. Das hat den Vorteil, daß der einzelne Mitarbeiter mit dem ganzen Verfahren nichts mehr zu tun hat; er senden die E-Mail normal ab, das Gateway kümmert sich um eine Verschlüsselung passend zum Empfänger. Was aber letzten Endes auch heißt, daß innerhalb der Absender- und auch der Empfänger-Systeme die fraglichen E-Mails unverschlüsselt vorliegen.
SSL/TLS in der technischen Übersicht
Bei einer Verschlüsselung mittels SSL/TLS wird nicht die einzelne E-Mail verschlüsselt, sondern die Verbindung zwischen zwei Servern zum Zeitpunkt der Übertragung. Der bekannteste SSL/TLS-Vertreter ist der Zugriff über https://, bei dem (normale) Webseiten verschlüsselt übertragen werden. Analog gibt es SSL/TLS-Varianten der E-Mail-Protokolle SMTP, POP3 und IMAP.
Auf jedem jeweiligen Server selbst liegt die E-Mail dann unverschlüsselt vor. Administratoren, Polizei oder Hacker hätten ungehinderten Zugriff, dessen muß man sich bewußt sein. Erst wenn die E-Mail zum jeweils nächsten System transportiert wird, geschieht das dann wieder über eine verschlüsselte Verbindung.
Mailserver haben das Problem, daß ein "man in the middle" den Austausch der Verschlüsselungs-Keys von vornherein unterwandern und den beteiligten Systemen die Schlüssel des Angreifers unterschieben könnte. Das ist möglich, setzt aber bereits einen gezielten spezifischen Angriff mit Energie und Vorsatz voraus, es handelt sich dabei nicht mehr um eine "versehentliche" durch einen Dritten, wie sie im technischen Alltag immer wieder mal vorkommen kann.
Eine man-in-the-middle-Attacke bei SSL/TLS kann jedoch leicht dadurch umgangen werden, daß einmal die Schlüssel der Gegenseite fix hinterlegt werden, so daß ein späterer Austausch durch einen Angreifer auffallen und zum Verbindungsabbruch führen könnte. Eine Manipulation ist dann bei Site-to-Site-Verbindungen ausgeschlossen. Größere Setups skalieren bequem durch eine von einer (eigenen?) CA unterschriebenen Zertifikate, deren Unterschrift dann zur Validierung herangezogen werden kann, um eine Schlüsselmanipulation durch Dritte auszuschließen.
Trotzdem ist SSL/TLS durchaus sehr vorteilhaft, denn hier wird die gesamte Kommunikation zwischen den Servern verschlüsselt -- es gelangt keine Information mehr über Absender, Empfänger oder gar Betreff der übertragenen E-Mail nach außen, ja, es ist noch nicht mal mehr die Anzahl der übertragenen E-Mails ersichtlich oder gar das Passwort, mit dem auf das POP3/IMAP-Postfach zugegriffen wurde. Es ist ein verschlüsselter "Tunnel", durch den die Daten fließen.
SSL/TLS bietet darum eine Site-to-Site-Verschlüsselung an, über den ganz grundsätzlich der vollständige Mailverkehr zwischen beiden Netzwerken verschlüsselt übertragen wird. Auf die Frage, um welche Postfächer und welche Mailadressen es sich dabei handelt, kommt es gar nicht mehr drauf an, ein Provider kann so den E-Mail-Transfer für seine Kunden absichern.
Sichere E-Mail-Übertragung in der Praxis
In der Praxis decken PGP+S/MIME und auch SSL/TLS jeweils Bereiche ab, die der jeweils andere Mechanismus nicht absichern kann. Folgerichtig wäre der konsequente Einsatz beider Verfahren der einzig wirkliche Schutz.
Unternehmen wollen häufig bestimmte Gegenstellen absichern: Eigene Niederlassungen, Partner-Unternehmen wie Steuerberater oder Anwaltskanzleien, aber beispielsweise auch Zulieferer, mit denen regelmäßig vertraulicher E-Mail-Verkehr stattfinden soll. Ärzte, Krankenkassen und Klinken geraten schnell in die Versuchung, auch sensible Patientdaten per Mail zu verschicken und sollten darum in der Lage sein, jede ausgehende Verbindung (auch zu beliebigen Providern) zu verschlüsseln.
Aufgrund guter Vertriebsarbeit der Hersteller der (nicht ganz billigen) Verschlüsselungs-Gateways setzen Unternehmen oft auch für eine Site-to-Site-Verschlüsselung auf entsprechende PGP S/MIME-basierten Verschlüsselungs-Gateways. Wird damit eine Site-to-Site-Verschlüsselung realisiert,werden i.d.R. "Gruppenzertifikate" (Wildcard-Zertifikate) erzeugt und zwischen beiden Gateways ausgetauscht. Jeweils ein Zertifikat "@zulieferfirma" und "@herstellerfirma" wird auf beiden Seiten hinterlegt und damit jede ein/ausgehende E-Mail verschlüsselt.
Gleichzeitig würde ein Konfigurationsfehler schon auf einem PGP S/MIME-Gateway dazu führen, daß Mails versehentlich unverschlüsselt versandt werden können, da die Gegenstelle nicht in der Lage wäre, die unverschlüsselte Einlieferung zu verhindern.
SSL/TLS wäre dafür technisch viel besser geeignet und sogar tatsächlich alle relevanten Informationen verschlüsseln (siehe oben), darüber hinaus könnte auch die empfangende Seite durch eine entsprechende Einstellung verhindern, daß versehentlich unverschlüsselt eingeliefert werden kann. Aber SSL/TLS hat halt keinen Hersteller und keinen Vertrieb -- und abgesehen davon: Was nix kostet kann nix taugen. Wenn Verschlüsselungs-Gateays schnell fünf- oder sechsstellige Summen kosten, dann muß das doch auch toll sein.
Die verschiedenen Szenarien mit Vor- und Nachteilen
PGP oder S/MIME-Verschlüsselung der E-Mails im Mailclient
- Weitreichenste Verschlüsselung Endpunkt-Endpunkt
- Jeder beteiligte muß Software verstanden, installiert und Keys erzeugt haben
- Endanwender muß Keys der Gegenseite besorgen/einlesen
- Keys liegen auf dem Desktop (Vor-/Nachteil gleichermaßen)
- Installation muß auf jedem Desktop gepflegt / ausgerollt werden
- Problem: Falsches Werkzeug für Site-to-Site. Wesentliche Teile einer E-Mail weiterhin unverschlüsselt. Oft schlechte Verwaltung der eingesetzten Schlüssel (Verlorene Schlüssel, Ex-Mitarbeiter hinterlassen verschlüsselten Bestand, Urlaubs-/Krankheitsvertretungen haben kein Zugriff)
- Einrichtungsaufwand: Installation und Key-Erzeugung für jeden Desktop
PGP ode S/MIME-Verschlüsselung auf dem Server-Gateway (Zertificon Z1 oder andere)
- Grundsätzlich wie PGP und S/MIME oben
- Mailrelay übernimmt Verschlüsselung beim Versand/Empfang anhand verschiedener Regelsätze/Vorgaben
- Transparent und mögl. unbemerkt für Endanwender
- Kommerzielle Lösungen besorgen sich die Schlüssel der Gegenstelle automatisiert aus dem Trustcenter (aber nur, wenn Gegenstelle auch im Trustcenter eingekauft hat, statt sich Schlüssel selbst zu machen)
- "Letzte Meile" zum Enduser-Desktop ist dann stets unverschlüsselt, also auch stets unverschlüsselte Ablage in der INBOX (Vor-/Nachteil gleichermaßen)
- Geeignet bei Kommunikation zu beliebig vielen und vorher unbestimmten Endpunkten und Empfängern
- Problem: Falsches Werkzeug für Site-to-Site. Wesentliche Teile einer E-Mail weiterhin unverschlüsselt. Definitiv nicht billig.
- Einrichtungsaufwand: Zentrale Serverinstallation durch Systemadministratoren, skaliert gut
Mailverschlüsselung per SSL/TLS-Tunnel
- Mailrelays versendet Mailverkehr an bestimmte Gegenstellen grundätzlich SSL/TLS-Verschlüsselt, d.h. nicht nur der Mailbody, sondern die gesamte Verbindung inkl. Mailheader, Absender/Empfänger wird verschlüsselt (also eigentlich viel besser).
- Absolut einfachste und pflegeleichteste Lösung, halt wie https bei Webseiten
- Absolut transparent, keinerlei Eingriff in die E-Mail
- Keinerlei Know-how und Installation beim Endanwender nötig
- Geeignet um Mailverkehr zu bekannten Endpunkten wie Mailrelays von Zulieferern, Abnehmern oder Partnern zu verschlüsseln. Ist das Zertifkat der Gegenstelle fest hinterlegt, ist SSL/TLS extrem sicher und auch nicht durch man-in-the-middle-Attacken auszuhebeln
- Durch entsprechende Policy-Regeln können Mailserver auch sicherstellen, daß zu bestimmten Gegenstellen ein Verkehr definitiv nur verschlüsselt stattfindet
- Aber auch geeignet um ohne großen Aufwand den Mailverkehr zu beliebigen Gegenstellen ganz grundsätzlich zu verschlüsseln und vor einer allzu einfachen unbefugterEinsichtnahme zu schützen.
- Problem: Sind die Schlüssel der Gegenstelle nicht fest oder überprüfbar hinterlegt, könnte sich ein man-in-the-middle bei einem gezielten (!) Angriff jedoch dazwischenschalten.
- Einrichtungsaufwand: Wenige Handgriffe in der Mailserver-Konfiguration in unter 15 Minuten
Und die Moral von der Geschichte?
Beide Varianten haben entscheidende Vorteile und Anwendungsfälle. Auch wenn Verschlüsselungsgateways hier in der Site-to-Site-Betrachung etwas schlecht weggekommen sind, haben Sie im Bereich 1-to-n (Ein Unternehmen, beliebig viele unbestimmte Kunden/Partner) eine wichtige Daseinsberechtigung, um eine vertrauliche Kommunikation sicherzustellen. Gerade die hier häufig integrierte Möglichkeit bei fehlen eines PGP oder S/MIME-Schlüssels die E-Mails stattdessen über einen integrierten https-geschützten Webmailer abzusichern, ist sehr charmant. So kann auch mit Kunden sicher kommuniziert werden, die selbst kein PGP S/MIME nutzen und deren Provider (warum auch immer) kein sicheres SSL/TLS unterstützt.
Heinlein Support realisiert seit vielen Jahre sichere Mailgatways -- egal ob Eigenbau-Lösungen oder PGP S/MIME-Gateways mit Produkten der verschiedenen Hersteller (bevorzugt unseren Kollegen bei Zertificon). Doch sorgen wir dafür, daß für jeden Einsatzzweck auch tatsächlich die richtige technische Lösung gewählt wird -- letztenendes müssten beide Systeme überlagernd eingesetzt werden.
Sprechen Sie uns an: Wir beraten Sie fachlich top und herstellerneutral ohne Eigeninteressen, am Ende setzen mit Ihnen und für Sie das für Sich beste fachliche Konzept um.
Weitere Beiträge zum Thema
Enterprise Mail-Security mit Open-Source?
Enterprise Mail Security with Open Source?
Kommentare