Granikos Technology Blog

The use of certificate-based email encryption is still a challenging task for administrators. When you store end-user certificates stored locally on computers, you accept the risk of the user certificates being deleted or overwritten unintentionally.

The use of smart cards helps to mitigate the risks associated with locally stored certificates. But smart cards are too complicated for large and agile companies. The use of smart cards with mobile devices is even more complicated, if not impossible.

Gateway Encryption

A simple and reliable solution is to use encryption and decryption capabilities at the company email gateway(s). This approach allows for:

• Central management of user and domain certificates or keys
  • S/MIME
  • PGP
• Central management of digital signage and encryption parameters for email communication with partner companies
• Encryption of any outgoing email communication regardless of the client used to compose the message:
  • Outlook
  • OWA
  • Outlook on the web
  • Mobile phone
  • Tablet Application
• Usage of internal eDiscovery solutions as internally stored email communication is still searchable
• No lost user certificates anymore

Besides the option to import certificates manually, the real benefit is provided by automatic certificate provisioning. By using a certificate authority company account the gateway solution handles certificate requests automatically.

The supported S/MIME certificate authorities are:

• D-TRUST
• GlobalSign
• SwissSign

NoSpamProxy by Net at Work is a gateway solution proving this set of features for on-premise SMTP messaging infrastructures.

Office 365

The advantages provided by NoSpamProxy can be used with Office 365 as well. There is no need to have an Exchange Hybrid configuration ins place to benefit from the NoSpamProxy features. The NoSpamProxy gateway can be configured for the use with Office 365 cloud-only tenants.

The following picture illustrates how NoSpamProxy gateway is integrated into such a scenario.

External emails are received by the local NoSpamProxy Gateway server and not by Exchange Online (1). The NoSpamProxy gateway handles the messages and sends the messages to Office 365 using an Office 365 connector (2). Outgoing messages to external recipients are sent to the on-premise NoSpamProxy gateway using a dedicated Office 365 Send Connector (3). The NoSpamProxy gateway handles the messages and sends the messages to the external recipients.

Multiple NoSpamProxy gateway servers can be deployed for a redundant setup.

NoSpamProxy

The NoSpamProxy gateway solution provides more than just S/MIME or PGP encryption capabilities. NoSpamProxy is a robust fully-fledged anti-spam solution that rejects spam emails legally compliant. Each message that is not fully received by the company does not need to be archived.

NoSpamProxy features:

• Legally compliant spam protection
• Legally compliant email communication using digital signage
• Protected email communication using password-protected PDF attachments
• Large attachment support by using a dedicated we portal
• Geographically dispersed gateways with central management

Want to know more about all NoSpamProxy features?
Not yet an Office 365 customer, but keen to know more about gateway-based encryption and a reliable anti-spam solution?

Get to know more about NoSpamProxy here.

Die Verwendung von Zertifikaten zur Verschlüsselung von E-Mails stellt Administratoren immer wieder vor Herausforderungen. Werden Zertifikate lokal auf Computern gespeichert, besteht immer das Risiko, dass die Zertifikate unerwünscht gelöscht oder überschrieben werden.

Die Verwendung von Signaturkarten umgeht dieses Problem, jedoch erscheinen diese vielen Unternehmen als zu kompliziert in der Anwendung. Hinzukommt, dass Signaturkarten sich nicht oder nur schwer mit mobilen Endgeräten nutzen lassen.

Verschlüsselung am Gateway

Eine Lösung bietet hier der Einsatz einer Lösung zur zentralen Ver- und Entschlüsselung direkt am E-Mail Gateway des Unternehmens. Dieser Ansatz bietet folgende Vorteile:

• Zentrale Verwaltung von Benutzer- und Domänenzertifikaten
  • S/MIME
  • PGP
• Zentrale Konfiguration von Signatur- und Verschlüsselungsparameter für die Kommunikation mit Partnerunternehmen
• Verschlüsselung jedweder ausgehenden E-Mail Kommunikation, unabhängig vom Client System:
  • Outlook
  • OWA
  • OOTW
  • Mobiltelefon
  • Tablet Applikation
• Keine verlorenen Benutzerzertifikate mehr

Neben der Möglichkeit Zertifikate manuell zu importieren, kann die Ausstellung von Zertifikaten auch automatisiert werden. Hierzu wird bei einem Zertifikatsanbieter ein Unternehmenskonto eingerichtet und die Gateway Lösung kümmert sich um die Ausstellung der gewünschten Benutzerzertifikate.

Unterstützte Anbieter zur automatischen Ausstellung von S/MIME Zertifikaten:

• D-TRUST
• GlobalSign
• SwissSign

Die Gateway Lösung NoSpamProxy von Net at Work bietet genau solch einen Funktionsumfang.

Office 365

Der Vorteil der Mail Gateway Lösung NoSpamProxy lässt sich auch mit Office 365 nutzen. Hierzu ist keine Exchange Hybrid Konfiguration notwendig, da sich NoSpamProxy für den Betrieb mit einem Cloud-Only Tenant in Office 365 konfigurieren lässt.

Die nachfolgende Grafik veranschaulicht, wie E-Mail Nachrichten mit externen Kommunikationspartnern und mit Office 365 ausgetauscht werden.

E-Mails werden hierbei nicht mehr von Office 365 und Exchange Online Protection (EOP) empfangen, sondern vom lokalen Gateway Server des Unternehmens. Nach der Verarbeitung durch NoSpamProxy werden die Nachrichten an Office 365 gesendet und in die Postfächer zugestellt.

Ausgehende Nachrichten werden von Office 365 an das Gateway gesendet, dort verarbeitet und anschließend an die externen Empfänger zugestellt.

Für einen sicheren Betrieb des Gateway können mehrere Instanzen der Software betrieben werden.

NoSpamProxy

Die Gatewaylösung bietet nicht nur die Möglichkeit zur E-Mail Verschlüssung. Wie der Name des Produktes schon andeutet, handelt es sich auch um eine Anti-Spam Lösung, die Spamnachrichten erfolgreich erkennt und rechtskonform abweist. Das Abweisen von unerwünschtem Spam minimiert den Bedarf an Archivspeicher immens.

NoSpamProxy Funktionen:

• Rechtskonformer Spam-Schutz durch SMTP-Proxy Funktion
• Gesetzeskonforme Kommunikation mit qualifizierter elektronischer Signatur
• PDF Mail zur Kennwortgeschützten Kommunikation
• Austausch von großen Dateien, ohne diese per E-Mail senden zu müssen

Mehr über die Funktionen und Vorteile von NoSpamProxy finden Sie hier.

Schützen Sie Ihre E-Mail Kommunikation mit NoSpamProxy. Gerne beraten wir Sie zum Thema E-Mail Sicherheit und finden die für Ihr Unternehmen passende Konfiguration. Senden Sie uns Ihre E-Mail Anfrage an info@granikos.eu.

Profitieren Sie von E-Mail Sicherheit Made in Germany

In den vorherigen Blog-Artikeln wurde allgemein über die Herausforderungen beim Thema E-Mail Sicherheit, die Möglichkeiten der TLS Übertragungsverschlüsselung und der E-Mail Signierung und Verschlüsselung mit S/MIME gesprochen.

In diesem Blog-Artikel werden die Verschlüsselungskomponenten beschrieben, die sowohl für die Sicherung des Übertragungskanals, als auch für die Nachrichtenverschlüsselung verwendet werden. Der Schwerpunkt des Artikels liegt auf der Security Provider Implementierung von Microsoft.

SCHANNEL - Secure Channel

Secure Channel ist das Security Support Provider Interface (SSPI) von Microsoft und wird von den unterschiedlichen Betriebssystemen bei Authentifizierungsvorgängen und bei verschlüsselter Kommunikation verwendet. Die unterstützen Verschlüsselungsalgorithmen variieren sehr stark, je nach Version des verwendeten Betriebssystems.

Cipher Suite

Eine sog. Cipher Suite beschreibt ein Sammlung von kryptografischen Algorithmen, die zur Schlüsselerstellung, Schlüsselaustausch und zur Verbindungsherstellung verwendet werden. Im Regelfall verwenden Softwarekomponenten auf Windowssystemen (Client und Server) die SCHANNEL Konfigurationen zur Verschlüsselung und Abwicklung der Kommunikation.

Jede zur Verfügung stehende Cipher Suite beschreibt eine festgelegte Kombination von

1. FIPS Mode
2. Unterstütztem Protokoll
3. Algorithmus zum Schlüsselaustausch
4. Algorithmus zur Verschlüsselung
5. Algorithmus zum Hashing der Nachrichten

Die von Windows Server 2012R2 unterstützten Cipher Suites sind:

• TLS_RSA_EXPORT_WITH_RC4_40_MD5
• TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
• TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
• SSL_CK_RC4_128_EXPORT40_MD5
• SSL_CK_DES_64_CBC_WITH_MD5
• TLS_RSA_WITH_DES_CBC_SHA
• TLS_RSA_WITH_NULL_MD5
• TLS_RSA_WITH_NULL_SHA
• TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
• TLS_DHE_DSS_WITH_DES_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521

Diese Suites werden zwar unterstützt, stehen aber nach einer Standardinstallation des Betriebssystems nicht zur Verfügung. Hierzu muss die SCHANNEL Konfiguration per Registry angepasst werden. Mehr dazu im Abschnitt "SCHANNEL Konfiguration".

Der Aufbau einer TLS Verbindung gliedert sich in 4 Schritte:

1. Handshake und Cipher Suite Aushandlung
2. Authentifizierung der Teilnehmer
3. Schlüsselaustausch
4. Datenaustausch der Applikation

In der nachfolgenden Beschreibung entspricht der Client dem sendenden (Verbindung aufbauenden) System und der Server dem empfangenden System.

1. Handshake
   • Bei Aufbau einer Verbindung sendet ein Client eine Liste der unterstützten Cipher Suites und der Server wählt eine angebotenen Suites auf Basis seiner konfigurierten, bevorzugten Reihenfolge aus und teilt dem Client das Ergebnis mit.
   • An dieser Stelle wird auch entschieden, ob die aufzubauende Verbindung Perfect Forward Secrecy (PFS) verwendet oder nicht. Wird eine Cipher Suite mit Ephemeral Diffie-Hellman (DHE) oder eine Elliptic-Curve Variante (ECDHE) ausgewählt, steht PFS zur Verfügung.
2. Authentifizierung
   • Der Server sein öffentliches Zertifikat an den Client und fragt ggf. ein Zertifikat vom Client an.
   • Falls der Server an Zertifikat angefragt hat, sendet der Client sein Zertifikat an den Server.
3. Schlüsselaustausch
   • Der Client erstellt ein zufälliges Pre-Master Secret und verschlüsselt es mit dem öffentlichen Schlüssel des Server-Zertifikates und sendet es an den Server.
   • Der Server und der Client erstellen nun auf Basis des Pre-Master Secret das eigentliche Master Secret und die Schlüssel für die Session.
   • Der Client sendet nun eine "Change Cipher Spec" Nachricht an den Server, und teilt so mit, das die neuen Sessionschlüssel für das Hashing und die ausgewählte Verschlüsselung verwendet werden.
   • Der Server empfängt die Nachricht und wechselt auf symmetrische Verschlüsselung unter Verwendung der Sessionschlüssel.
4. Datenaustausch
   • Der sichere Kanal zwischen Client und Server ist hergestellt und Applikationsdaten können verschlüsselt übertragen werden.

Hinweis:
Bei der Konfiguration der Cipher Suites Reihenfolge sollte darauf geachtet werden, dass zwar zuerst Suites mit PFS konfiguriert werden, jedoch ein Fallback ohne PFS ebenfalls angeboten wird.

Cipher Suite Reihenfolge

Die Cipher Suite Reihenfolge legt fest, welche Suite zuerst und welche zuletzt verwendet werden soll.

In der Windows Systemregistrierung die zur Verfügungen stehenden Cipher Suites nach einer Basis Installation nicht konfiguriert. Der nachfolgende Screenshot zeigt den Registrierungsschlüssel SCHANNEL.

Einzig die zur Verfügung stehenden Protokolle (SSL/TLS) sind konfiguriert.

Die verfügbaren Cipher Suites und die eigentliche Reihenfolge der Suites werden in zwei unterschiedlichen Registrierungsschlüsseln konfiguriert.

Verfügbare Cipher Suites:
HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

Reihenfolge der Cipher Suites:
HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002

Hinweis: Der Registrierungsschlüssel für die Liste der Cipher Suites ist begrenzt auf 1023 Zeichen.

SCHANNEL Konfiguration

HINWEIS: Die direkte und eventuell fehlerhafte Anpassung der Windows Registry kann zur Instabilität des Betriebssystems führen. Die nachfolgende Beschreibung erfolgt nach bestem Wissen. Jedoch können wir keine Haftung für eventuelle Schäden übernehmen.

1. Erstellen Sie ein Backup des Systems, bevor Sie Änderungen an der Systemregistrierung durchführen
2. Erstellen Sie ein Backup des Systems, bevor Sie Änderungen an der Systemregistrierung durchführen

Die Konfiguration der Cipher Suites erfolgt im nachfolgenden Beispiel unter Verwendung des Tools IIS Crypto.

IIS Crypto ist ein Hilfsmittel, um die Konfiguration in der Windows Registry einfacher zu gestalten. Jedoch muss man bei Einsatz bedenken, dass beim Start des Programmes nicht die tatsächlich vorhandene Konfiguration der Systemregistrierung ausgelesen und angezeigt wird, sondern vielmehr die Standardkonfiguration von IIS Crypto.

IIS Crypto bietet vorkonfigurierte Konfigurationen für:

• FIPS 140-2
• PCI
• Best Practices

Nach der Anpassung der Cipher Suite Konfiguration (im nachfolgenden Beispiel die Best Practices Konfiguration), sind die neuen Schlüssel und Parameter in der Systemregistrierung vorhanden.

Je nach Typ (Protokoll oder Cipher Komponente) werden zur Aktivierung bzw. Deaktivierung folgende Schlüssel verwendet:

• Enabled, 0x0 oder 0xffffffff
• DisabledByDefault, 0 oder 1

Eine Beschreibung zur manuellen Konfiguration der Systemregistrierung finden Sie bei Microsoft hier: http://support2.microsoft.com/default.aspx?scid=kb;EN-US;245030

Fazit

Wenn eine besonderen Anforderungen an die Absicherung der Server-Kommunikation mit externen Systemen besteht, was eigentlich immer der Fall ist, muss eine zusätzlich Konfiguration des Secure Channel Providers erfolgen. Im Normallfall kann die einheitlich über Gruppenrichtlinien erfolgen. Verwenden Sie aber Systeme, die keine Mitgliedsserver einer Domäne sind, so müssen diese Systemen manuell über die Systemregistrierung oder durch Verwendung der lokalen Sicherheitsrichtlinie erfolgen.

Die Konfiguration des Secure Channel hat eine direkte Auswirkung auf die TLS Verschlüsselung aller TCP Protokolle. Durch die unterschiedlichen Implementierungen bei unterschiedlichen Betriebssystemen müssen die Anpassungen mit Bedacht durchgeführt werden.

Sollte es Gründe geben, dass Sie eine FIPS- oder PCI-konforme Konfiguration vornehmen müssen, gibt es allerdings keine Alternative zur Umsetzung der Vorgaben.

Links

• Secure Channel
• Cipher Suites in Windows Server 2008R2 und Windows Server 2012(R2)
• How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll
• Bewertung der unterschiedlichen Schlüsselaustausch Algorithmen
• IIS Crypto
• FIPS 140-4
• PCI Security Standards

Mini-Serie E-Mail Sicherheit

• E-Mail Verschlüsselung und E-Mail Sicherheit
• E-Mail Verschlüsselung - TLS, S/MIME & Co (Teil 1)
• E-Mail Verschlüsselung - TLS, S/MIME & Co (Teil 2)
• E-Mail Verschlüsselung und Cipher Suites

Fragen zur E-Mail Sicherheit

Haben Sie Fragen rund um das Thema E-Mail Verschlüsselung und E-Mail Sicherheit? Kontaktieren Sie uns unter: emailsecurity@granikos.eu.

In vorherigen Blog-Artikeln wurde allgemein das Thema E-Mail Verschlüsselung und E-Mail Sicherheit besprochen und auf die Verbindungsverschlüsselung mit TLS eingegangen. In diesem Artikel werden Möglichkeiten zum Einsatz von S/MIME zur Signierung und Verschlüsselung von E-Mail Nachrichten betrachtet.

E-Mail Sicherheit

In der heutigen Zeit kommt der Signierung und Verschlüsselung von E-Mail Nachrichten eine zentrale Rolle zu, um sich gegen Wirtschaftsspionage und anderen Zugriffe Dritter auf die Unternehmenskommunikation zu schützen. Die Sicherung des Nachrichtenverkehrs ist nur ein Baustein im gesamten Informationssicherheitskonzept eines Unternehmens. Weitere Punkte sind u.a. Schutz gegen den Verlust von Daten (Data Leackage Prevention, DLP), Berechtigungsmanagement (RMS) oder die Kontrolle von Zugriffsberechtigungen.

Das generelle Konzept zur Verschlüsselung von Nachrichten per S/MIME geht auf das Jahr 1995 zurück. Die aktuellen Implementierung von S/MIME 3.2 sind seit 2010 Stand der Technik.

S/MIME - E-Mail Signierung und Verschlüsselung

Bei der Verwendung von S/MIME wird eine unverschlüsselte E-Mail Nachricht in einer sog. MIME gekapselt und nur signiert oder auch verschlüsselt. Neben diesem ersten Teil enthält die neue Nachricht auch die erforderliche Zertifikatsinformation zum Zugriff auf den Nachrichtenteil.

Zertifikate teilen sich in einen öffentlichen und einen privaten Schlüssel und bilden gemeinsam das Schlüsselpaar eines Anwenders. Im Standardfall wird das Schlüsselpaar auf einem Clientrechner eines Benutzers erzeugt und der öffentliche Schlüssel von einer Zertifizierungsstelle signiert. Der private Schlüssel verbleibt auf dem Rechner des Benutzers.

Da der private Schlüssel somit nur an einer Stelle gespeichert ist, jedoch für die Laufzeit des Zertifikates zum Entschlüsseln von Nachrichten benötigt wird, stellt dies ein Risiko dar. Kommt es ohne Datensicherung des privaten Schlüssels zu einem Schaden am Gerät, muss ein neues Zertifikat ausgestellt werden und alte, mit dem verlorenen Zertifikat verschlüsselte Nachrichten, können nicht mehr entschlüsselt werden. Mehr dazu im Abschnitt "Gateway-Lösungen".

Neben der Speicherung des Zertifikates auf dem Clientrechner können auch Signaturkarten verwendet werden. Der Einsatz von Signaturkarten erfordert allerdings auch den Einsatz von passenden Lesegeräten, die meist nicht für alle Arten von Clientgeräten zur Verfügung stehen. Die auf Signaturkarten gespeicherten Zertifikate sind durch eine PIN vor unbefugtem Zugriff geschützt.

S/MIME Clients

Im Standardfall ist das S/MIME E-Mail Zertifikat auf dem Clientrechner eines Benutzers vorhanden. Dies bedeutet, dass der Benutzer auf diesem Clientrechner in der Lage ist, E-Mail Nachrichten zu signieren oder zu verschlüsseln. Und dies auch nur mit einem E-Mail Programm wie Outlook. Alternative Produkte verfügen eventuell über einen separaten Speicher für S/MIME Zertifikate und verwenden nicht den Zertifikatsspeicher des Betriebssystems.

In der heutigen Welt ist ein fester Clientrechner, sei es ein Desktop PC oder ein Laptop, nicht mehr das einzige Gerät, über das ein Mitarbeiter Zugriff auf E-Mails hat. Wenn in einem Unternehmen S/MIME verwendet wird, soll die Zugriff auf E-Mail Nachrichten und damit das Verfassen und Lesen von verschlüsselten Nachrichten auf allen Clients verfügbar sein.

Zu den Client-Optionen und Zugriffsarten gehören:

• E-Mail Client - Outlook
• Webmail - Outlook Web App
• Mobile App - Exchange ActiveSync Implementierung, OWA App
• Citrix - Remote Desktop Zugriff
• VDI - Virtual Desktop Infrastructure
• AppV - Application Virtualization

Je nach erforderlichem Einsatzszenario im Unternehmen, muss das S/MIME Zertifikat sowohl auf den Servern, als auch auf den auf den unterschiedlichen Endgeräten ausgerollt und installiert werden. Dies bringt ganz neue Herausforderungen mit sich. Gerade wenn unterschiedlichste Endgeräte zum Einsatz kommen oder eine BYOD Kultur etabliert ist, empfiehlt sich eine zentrale Gateway-Lösung für die E-Mail Verschlüsselung.

Der Einsatz von S/MIME Verschlüssung beim Zugriff auf Webmail (Outlook Web App) erfordert den Zugriff des Browsers auf den lokalen Zertifikatsspeicher. Hierzu muss eine separate Software-Komponente (S/MIME Plugin) installiert werden, die nur mit dem Internet Explorer funktioniert. Zusätzlich müssen die serverseitigen S/MIME Parameter für OWA im Exchange Server konfiguriert werden. Da die OWA S/MIME Implementierung aber nur ein Teil der zur Verfügung stehenden Crypto-Einstellungen unterstützt, müssen OWA S/MIME Einstellungen und die Crypto Konfigurationen des Betriebssystem im Einklang erfolgen. Ansonsten kommt es in OWA zu Fehlermeldungen und der Benutzer kann E-Mails nicht signieren, verschlüsseln oder entschlüsseln. Dies bedeutet, dass ein Benutzer per Outlook verschlüsselte E-Mails nicht in OWA öffnen kann.

PKI - Public Key Infrastructure

Die zur Signierung und Verschlüsselung verwendeten Zertifikate werden von einer Zertifizierungsstelle signiert. Diese Zertifizierungsstelle ist Bestandteil einer sog. PKI und wird entweder von einem externen Anbieter oder aber vom eigenen Unternehmen betrieben.

Die Verwendung eines externen Anbieters von Zertifikaten hat den Vorteil, dass in den allermeisten Fällen die erforderlichen Zertifikate (Root- und Intermediate-Zertifikate) zur Überprüfung eines E-Mail Zertifikates bereits auf den jeweiligen Endgeräten zur Verfügung stehen. Die benötigten E-Mail Zertifikate für Mitarbeiter werden immer für einen bestimmten Zeitraum ausgestellt, wobei unterschiedliche Zeiträume mit unterschiedlichen Kosten verbunden sind.

Die Implementierung einer eigenen PKI ermöglicht es Unternehmen, die Zertifikatsinfrastruktur auch für andere Komponenten zu verwenden. Hierzu gehören u.a. interne Webserver, Lync Kommunikation oder Benutzerauthentifizierung.

Die Verwendung einer eigenen PKI erhöht aber auch die Komplexität der IT-Infrastruktur und will gut überlegt und geplant sein, da etablierte PKI für einen langen Zeitraum in Betrieb ist.

Für S/MIME bedeutet der Einsatz einer eigenen PKI, dass die erforderlichen Root- und Intermediate Zertifikate für externe E-Mail Empfänger zur Verfügung stehen müssen. Partnerunternehmen können diese Zertifikate mit Hilfe von Softwareverteilung intern zur Verfügung stellen. Andere Empfänger müssen in der Lage sein, sich diese Zertifikate von einer Webseite herunterladen zu können. Hinzu kommt, dass der Endpunkt zur Überprüfung von zurückgezogenen Zertifikaten ebenfalls aus dem Internet erreichbar sein muss.

Gateway-Lösungen

Wie bereits oben beschrieben, ist die Ausstellung von E-Mail Signatur Zertifikaten auf Benutzerrechnern in Unternehmen als Risiko zu sehen. Ebenso können Benutzer nicht ohne weiteres die gewohnten unterschiedlichen Endgeräte verwenden, um S/MIME Nachrichten zu empfangen oder zu senden.

Hier setzen Gateway-Lösungen an, die zentral die Signierung und die Ver- und Entschlüsselung sicherstellen. Das Zertifikatmanagement, also die Ausstellung und das Widerrufen von Benutzerzertifikaten erfolgt ebenfalls zentral am Gateway.

Die öffentlichen Schlüssel von eingehenden Nachrichten werden automatisch ausgelesen und zentral gespeichert. Hierdurch stehen die öffentlichen Schlüssel von externen Kommunikationspartnern allen Mitarbeitern im Unternehmen für eine sichere E-Mail Kommunikation zur Verfügung.

Durch ein Regelwerk kann sichergestellt werden, dass E-Mails an Empfänger, die keine Verschlüsselung unterstützen, auch unverschlüsselt zugestellt werden. Die Verschlüsselung des Übertragungskanal ist weiterhin möglich.

Als Beispiel einer solchen Lösung sein hier enQsig von Net at Work, Paderborn, genannt. Diese zertifizierte Verschlüsselungslösung unterstützt neben der Verschlüsselung mit S/MIME auch PGP. Das Produkt verfügt über weitere Funktionen, die Sie gerne hier nachlesen können.

Eine zentrale Gateway-Lösung zur E-Mail Verschlüsselung stellt eine optimale Möglichkeit zur Implementierung sicherer E-Mail Kommunikation dar, bei gleichzeitiger Reduzierung des Aufwandes für die erforderliche IT-Infrastruktur und die notwendigen Prozesse.

Fazit

Es gibt keinen wirklichen Grund, E-Mail Verschlüsselung nicht einzusetzen. Die Gefährdungen für sensible Unternehmenskommunikation werden in den nächsten Jahren eher steigen als sinken.

Und mit einer zentralen Gateway-Lösung ist es sowohl für mittelständische Unternehmen, als auch für Großkonzerne möglich, eine verlässliche Kommunikationsumgebung zu schaffen, die anderen technischen Entwicklungen nicht im Wege steht.

Links

• NoSpamProxy Encryption, E-Mail Verschlüsselung am Gateway
• RFC 3851 - S/MIME 3.1
• RFC 5751 - S/MIME 3.2
• PKI - Public Key Infrastructure, Common Trust, Encryption and Digital ID Troubleshooting – for Microsoft Outlook and Microsoft Exchange users
• MS-OXOSMIME Protokoll

Mini-Serie E-Mail Sicherheit

• E-Mail Verschlüsselung und E-Mail Sicherheit
• E-Mail Verschlüsselung - TLS, S/MIME & Co (Teil 1)
• E-Mail Verschlüsselung - TLS, S/MIME & Co (Teil 2)
• E-Mail Verschlüsselung und Cipher Suites

Fragen zur E-Mail Sicherheit

Haben Sie Fragen rund um das Thema E-Mail Verschlüsselung und E-Mail Sicherheit? Kontaktieren Sie uns unter: emailsecurity@granikos.eu.

Im ersten Blog-Artikel dieser Miniserie wurde allgemein das Thema E-Mail Verschlüsselung und E-Mail Sicherheit besprochen. In diesem Artikel wird die Verschlüsselung des Übertragungsweges mit TLS genauer betrachtet.

E-Mail Sicherheit

E-Mail Sicherheit besteht nicht nur aus der Sicherung des Übertragungsweges zwischen den beteiligten Systemen, sondern auch aus der optionalen Verschlüsselung bzw. Signierung der Nachricht selber. Die Verschlüsselung des Übertragungsweges ist aber die Grundvoraussetzung für eine sichere Kommunikation und seit 1999 Stand der Technik.

TLS - Verschlüsselung des Übertragungsweges

Bei der Sicherung des Übertragungsweges erfolgt zwischen zwei Servern mit Hilfe der Transport Layer Security (TLS). TLS ist das Nachfolgeprotokoll des Secure Socket Layer (SSL) Protokolls und wird gegenwärtig in der Version 1.2 eingesetzt. Hierbei handelt es sich um ein zertifikatsbasiertes Protokoll, das zur Sicherung von unterschiedlichen TCP Protokollen verwendet wird. Hierzu zählen u.a. POP3, IMAP, SIP, SMTP, HTTP oder LDAP.

Die grundsätzliche Implementierung des TLS Protokolls und aller Protokolleinstellungen ist Teil des Server-Betriebssystems (Windows Server) und nicht der verwendeten E-Mail Software. Ausgeführte Konfigurationen wirken sich somit auf alle Applikationen auf dem Server aus. Der vierte Blog-Artikel dieser Reihe beschreibt die Konfiguration und die Auswirkungen im detaillierter.

Bei der Verwendung von TLS ist nur die Kommunikation zwischen zwei Servern (Sender und Empfänger) verschlüsselt. In den jeweiligen Unternehmensnetzen ist es möglich, dass die Übertragung zwischen anderen beteiligten Systemen unverschlüsselt erfolgt. Von einer unverschlüsselten Kommunikation, also ohne Verwendung von TLS, ist auch innerhalb eines Unternehmensnetzwerkes dringend abzuraten.

Einfache Darstellung der TLS Kommunikation zwischen zwei E-Mail Systemen:

Diese einfache Darstellung lässt sich beliebig in seiner Komplexität erweitern. Im nachfolgenden Beispiel wird gezeigt, dass auf der Sender-Seite eine interne Lösung zur Anti-Malware Erkennung betrieben wird, während auf der Empfänger-Seite eine Cloud-basierte Lösung im Einsatz ist.

Im vorstehenden Beispiel können Sie als Sender nur die Verbindung zwischen der Anti-Malware Lösung und dem Cloud-Anbieter überwachen und prüfen. Den Status und die Konfiguration zwischen dem Services des Cloud-Anbieters und dem E-Mail Server des Empfänger können Sie nicht kontrollieren.

Auch wenn alle Verbindungen "TLS verwenden", so können die verwendeten Verschlüsselungsmechanismen (Cipher Suite, Hashes, Signature) für jede der TLS Verbindungen unterschiedlich sein. Somit ist auch jede der Verbindungen unterschiedlich "sicher".

In der Grundkonfiguration führt TLS nur Grundprüfungen der verwendeten Zertifikate durch. Hierzu gehört u.a., ob das Zertifikat zeitlich noch gültig ist. Eine Überprüfung, ob das Zertifikat vielleicht zwischenzeitlich zurückgezogen wurde und daher ungültig ist, gilt bereits als erweiterte Prüfung. Solch eine erweiterte Prüfung ist Aufgabe der eingesetzten E-Mail Software.

Das TLS Protokoll selber ist anfällig für Man-In-The-Middle Angriffe und wird daher als nicht 100% sicher eingestuft. Hintergrund ist, dass es zweifelhafte Zertifizierungsstellen gibt, die Zertifikate ohne genaue Prüfung herausgeben. Hierdurch können sich unberechtigte Dritte als jemand anderes ausgeben (siehe Linkliste). Das Risiko lässt sich nur dadurch minimieren, indem auf den eigenen Systemen die fragwürdige Zertifizierungsstellen deaktiviert werden.

Gerade die unterschiedlichen Konfigurationen der TLS Sicherheit führen im täglichen Betrieb immer wieder zu Problemen. Wenn ein Server mit einer "zu sicheren" Konfiguration betrieben wird, kann es zu "Verständigungsproblemen" mit einem Server auf der anderen Seite kommen. Ist der empfangende Verbindungsendpunkt nun so konfiguriert, dass TLS erforderlich ist, so kommt keine Verbindung Zustande und die Nachricht kann nicht zugestellt werden. Ist wiederum TLS als optional konfiguriert, so wird die Nachricht on TLS Verschlüsselung übertragen. Hieraus ergibt sich die Notwendigkeit, zwei unterschiedliche Endpunkte zu betreiben:

• TLS optional aus Kompatibilitätsgründen zu unbekannten Systemen
• TLS erzwungen zu bekannten und vertrauten Partnern

Interne Systeme - das unbekannte Risiko

Interne Applikationen und Systeme stellen ein großes Risiko dar, wenn sie nicht in der Lage sind, unternehmenskritische Kommunikation mit Hilfe von TLS Verschlüsselung zu einem internen E-Mail Server zu übertragen. Noch kritischer ist die Situation, wenn interne Applikationen oder Systeme direkt mit Systemen außerhalb des Unternehmensnetzwerkes kommunizieren und nicht über Verschlüsselungsfunktionen verfügen. Als beispielhafte interne Applikationen oder Systeme seien genannt:

• CRM
• ERP
• Auftragswesen
• Rechnungswesen
• Helpdesk Systeme
• Multi-Funktionsdrucker mit Scanner
• IT Monitoring Lösungen

Es wird deutlich, dass das Thema E-Mail Sicherheit nicht isoliert betrachtet werden kann, sondern vielmehr mit einer ganzheitlichen Betrachtung der gesamten IT-Landschaft einhergeht.

Fazit

Ein Serversystem mit einer aktuellen E-Mail Software und aktiviertem TLS zu betreiben reicht nicht aus, um die E-Mail Sicherheit für ein Unternehmen zu gewährleisten. Neben den rein technischen Aspekten zur sicheren Konfiguration der TLS Implementierung müssen auch organisatorische Aspekte zur Kommunikation mit Partnerunternehmen geklärt und festgeschrieben werden.

Technik ist ein Hilfsmittel zur Sicherstellung der Sicherheit. Sie befreit nicht von einer sorgsamen Planung und Dokumentation (auch zur Auditzwecken) der E-Mail Umgebung.

Um die Sicherheit der Kommunikation zu Erhöhen, können Nachrichten nicht nur sicher übertragen, sondern digital signiert und/oder verschlüsselt werden. Hierzu stehen die Technologien S/MIME oder PGP zur Verfügung. Im nächsten Blog-Artikel befassen wir uns mit diesen beiden Technologien.

Links

• Internetzugang im Flugzeug: Google-Expertin entdeckt gefälschtes SSL-Zertifikat
• Transport Layer Security

Mini-Serie E-Mail Sicherheit

• E-Mail Verschlüsselung und E-Mail Sicherheit
• E-Mail Verschlüsselung - TLS, S/MIME & Co (Teil 1)
• E-Mail Verschlüsselung - TLS, S/MIME & Co (Teil 2)
• E-Mail Verschlüsselung und Cipher Suites

Fragen zur E-Mail Sicherheit

Haben Sie Fragen rund um das Thema E-Mail Verschlüsselung und E-Mail Sicherheit? Kontaktieren Sie uns unter: emailsecurity@granikos.eu.