de-DEen-GB
rss

Granikos Technology Blog

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:

Absicherung der E-Mail Übertragung mit TLS

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.

Absicherung interner und externer Verbindungen mit TLS

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

Mini-Serie E-Mail Sicherheit

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.

Weiterlesen »

Die Themen E-Mail Verschlüsselung und E-Mail Sicherheit sind keine neue Themen. Die vergangenen Veröffentlichungen im Rahmen der Whistleblower-Affären haben dazu geführt, dass die breite Masse sich mit dem E-Mail Sicherheit beschäftigt. Verschlüsselung an sich ist ein komplexes Thema und dies scheint einer der Gründe dafür zu sein, warum es nach einem ersten Aufschrei wieder in der Versenkung verschwindunden ist.

E-Mail Sicherheit als Marketing Instrument

Große deutsche Anbieter haben die Aufregung der ersten Stunde dazu genutzt, eine geschickte Marketing Kampagne zu starten (Stichwort: "E-Mail Made in Germany"), um von ihren Sicherheitsverfehlungen in der Vergangenheit abzulenken. Man darf die Augen nicht davor verschließen, dass die "großen Provider" vor Edward Snowden die Verschlüsselung des E-Mail Übertragungskanals aus Kosten- und Effizienzgründen nicht konfiguriert haben.

Die Verwendung von sichereren Übertragungskanälen ist weder eine Erfindung der Neuzeit und schon gar nicht eine Erfindung der Telekommunikationsanbieter. Die entsprechende Softwareprogramme unterstützten diese Funktionen schon vorher, da das notwendige Protokoll bereits 1999 (RFC 2487) eingeführt wurde. Die von WEB.DE in diesem Artikel verwendete Grafik suggeriert im Kontext des Artikels, dass nur GMX, WEB.DE und T-ONLINE über eine sichere Kommunikation verfügen und andere Anbieter dies nicht gewährleisten. Das ist schlichtweg falsch.

Technologisch besteht keinerlei Notwendigkeit, sich auf große Provider zu verlassen, wenn es um das Thema E-Mail Sicherheit geht. Selbst bei Anwendung des deutschen Datenschutzgesetzes, sind Daten des Kunden auf Geräten des Providers und sind damit rechtlich dem Zugriff des Kunden entzogen.

E-Mail Sicherheit für Unternehmen

Aber was kann ich als Unternehmen machen, um E-Mails sicher zu übertragen und die Integrität der E-Mails sicherzustellen?

Der Schutzbedarf der E-Mail Kommunikation stellt sich für jedes Unternehmen anders dar.

Mögliche Fragen sind:

  • Ist die Verschlüsselung des Übertragungskanals ausreichend?
    Stichwort: TLS Verschlüsselung
  • Möchte ich sicherstellen, dass meine Nachrichten nur von geprüften Systemen empfangen werden?
    Stichwort: Domain Secure
  • Sollen meine Nachrichten selber verschlüsselt werden?
    Stichworte: S/MIME, PGP
  • Möchte ich die volle Kontrolle über den Nachrichtenverkehr behalten?
    Stichworte: Eigener Mail Server, Exchange Online, Clouddienste
  • Ist die Verwaltung von Zertifikaten nicht kompliziert?
    Stichwort: Gateway Lösung
  • Welchen Zugriff haben Dritte (Administratoren, Dienstleister) auf meine E-Mails?
    Stichwort: Zugriffsberechtigung
  • Möchte ich, dass meine geschäftlichen Nachrichten zu Werbezwecken durchsucht werden?
    Stichwort: Google Mail, GMX, WEB.DE, T-Online, Hotmail
  • Muss ich meine E-Mails revisionssicher aufbewahren?
    Stichwort: Archivierung
  • Unterliegt meine E-Mail Umgebung einer Dokumentationspflicht?
    Stichworte: Audit, Zertifizierung
  • Sind in meinem Unternehmen Geräte oder Softwarekomponenten im Einsatz, die eigenständig E-Mails versenden?
    Stichwort: Multi-Funktionsdrucker mit Scanner, CRM, ERP

Vertrauen

Das Thema E-Mail Verschlüsselung und E-Mail Sicherheit ist und bleibt komplex. Jedoch können Sie mit Hilfe kompetenter Berater die passende Lösung finden und die Sicherheit und Integrität Ihrer E-Mails sicherstellen.

Grundsätzlich und faktisch basiert E-Mail Sicherheit auf Vertrauen. Das Vertrauen ist begründet sich technisch in den Vertrauensstellungen der verwendeten und gültigen Zertifikate auf der einen Seite und den organisatorischen und vertraglichen Vertrauensstellungen zwischen Kunden und Software- bzw. Dienstanbietern auf der anderen Seite.

Fragen zur E-Mail Sicherheit

Die technischen Aspekte der E-Mail Sicherheit werden im Rahmen von drei weiteren Blog Artikel auf http://blog.granikos.eu behandelt.

Die Themen der Serie sind:

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

Weiterlesen »

You can use PowerShell to manage your local certificate store.

The default PowerShell Get-ChildItem cmdlet allows for accessing the local certificate store. But you should start your PowerShell shell windows as administrator, as access might be restricted by GPO settings.

 

List all certificate folder on the local machine

Get-ChildItem -Path Cert:\LocalMachine

Name : TrustedPublisher
Name : ClientAuthIssuer
Name : Remote Desktop
Name : Root
Name : TrustedDevices
Name : SPC
Name : CA
Name : REQUEST
Name : AuthRoot
Name : WebHosting
Name : TrustedPeople
Name : My
Name : SmartCardRoot
Name : Trust
Name : Disallowed

 

List all available certificates for the computer

Get-ChildItem -Path Cert:\LocalMachine\My

    Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\My

Thumbprint                                Subject
----------                                -------
EC225A0183DC64D864C8BEA1477822858FCEC767  CN=WMSvc-EXSRV02
E2BC29B1445FD267E5A2823591A5221D67D0D94F  CN=Microsoft Exchange Server Auth Certificate
D8EE794A39A8E04BE32A1E8BED93A3C46D15E0EF  CN=EXSRV02
60246A87C12BEB365E7B4044C926587590A3D7B6  CN=mobile.mcmemail.de, O=mcmemail, C=DE
5F103D6C61BF57D86DB4AAA05597B0D1E8155884  CN=EXSRV02.mcmemail.de, CN=EXSRV02, CN=127.0.0.1, CN=localhost, O=Trend Micro.

 

Retrieve certificate details

The example shows a self-signed certificate of a Trend Micro ScanMail for Exchange setup.

$cert = Get-ChildItem -Path Cert:\LocalMachine\My\5F103D6C61BF57D86DB4AAA05597B0D1E8155884
$cert | fl

Subject      : CN=EXSRV02.mcmemail.de, CN=EXSRV02, CN=127.0.0.1, CN=localhost, O=Trend Micro ScanMail for Microsoft
               Exchange
Issuer       : CN=EXSRV02.mcmemail.de, CN=EXSRV02, CN=127.0.0.1, CN=localhost, O=Trend Micro ScanMail for Microsoft
               Exchange
Thumbprint   : 5F103D6C61BF57D86DB4AAA05597B0D1E8155884
FriendlyName :
NotBefore    : 17.11.2014 00:00:00
NotAfter     : 16.11.2017 00:00:00
Extensions   : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid}

 

A certificate issued by an Enterprise CA looks like this

$cert = Get-ChildItem -Path Cert:\LocalMachine\My\60246A87C12BEB365E7B4044C926587590A3D7B6
$cert | fl

Subject      : CN=mobile.mcmemail.de, O=mcmemail, C=DE
Issuer       : CN=mcmemail-DC01-CA, DC=mcmemail, DC=de
Thumbprint   : 60246A87C12BEB365E7B4044C926587590A3D7B6
FriendlyName : mcmemail Exchange Server 2013 Certificate
NotBefore    : 28.08.2014 15:14:04
NotAfter     : 28.08.2015 15:24:04
Extensions   : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
               System.Security.Cryptography.Oid...}

 

Export a single certificate

$cert | Export-Certificate -FilePath C:\tmp\cert1.p7b -Type p7b

    Directory: C:\tmp

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        23.12.2014     11:56       1380 cert1.p7b

 

Export multiple certificates as serialized certificates

$certarray = @()
$certarray += $cert
$cert = Get-ChildItem -Path Cert:\LocalMachine\My\D8EE794A39A8E04BE32A1E8BED93A3C46D15E0EF
$certarray += $cert
$certarray

Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\My

Thumbprint                                Subject
----------                                -------
60246A87C12BEB365E7B4044C926587590A3D7B6  CN=mobile.mcmemail.de, O=mcmemail, C=DE
D8EE794A39A8E04BE32A1E8BED93A3C46D15E0EF  CN=EXSRV02

$certarray | Export-Certificate -FilePath c:\tmp\certs.sst -Type SST

    Directory: C:\tmp

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        23.12.2014     11:58       3056 certs.sst 

 

Enjoy working with certificates.

 


You plan to upgrade to Exchange Server 2013? You wonder what the benefits of Office 365 are? Contact us at info@granikos.eu

Weiterlesen »

Der Block Listen Dienst AHBL (http://ahbl.org) hat den Dienst eingestellt. Abfragen an die nachfolgenden Dienst-Urls liefern somit für alle Anfragen positive Ergebnisse.

  • rhsbl.ahbl.org
  • dnsbl.ahbl.org
  • ircbl.ahbl.org

Dies bedeutet, dass alle Domänen als "SPAM" zurückgemeldet werden.

Sollten Sie AHBL noch als aktiven Dienst für Spam-Prüfungen konfiguriert haben, so deaktivieren oder Löschen Sie den Dienst.

 


Sie interessieren sich für eine erfolgreiche und sichere Anti-Spam Lösung aus Deutschland? Teste Sie NoSpamProxy noch heute.

Weiterlesen »

Das Exchange Blog Cumulative Update für Dezember 2014 (CU1214) fasst interessante Themen rund um Exchange Server und Office 365 (Exchange Online), Azure und Lync des Monats Dezember 2014 zusammen.

Alle Links für des CU 1214 finden Sie auch in unserem Bitly Bundle: http://bit.ly/CU1214Bundle

Exchange Server & Exchange Online

Office 365 & Exchange Online

Lync Server

Azure

Allgemeine Themen

Replay

 

Podcast Empfehlungen

Tools / Software


Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Installation oder Migration.

Sie denken über einen vollständigen Wechsel zu Office 365 oder eine Hybrid-Implementierung mit Office 365 nach? Wir beraten Sie umfassend und ausführlich über die Möglichkeiten der Office 365 Plattform.

Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (http://www.granikos.eu) oder nehmen Sie direkt mit uns Kontakt auf: info@granikos.eu

Weiterlesen »