6
Exchange 2013: SSL v3 und TLS1.0 besser nicht deaktivieren
An diesem Wochenende wollte ich Microsofts Empfehlung folgen und SSL v3 und TLS 1.0 auf allen IIS deaktivieren
Ich stellte fest, dass dies keine gute Idee in einem Exchange-Cluster (Exchange 2013) ist, in welchem die CAS und die Mailbox-Server nicht auf der gleichen Maschine liegen.
Die Kommunikation mit den Backend-Services wird dadurch unterbrochen und OWA, ECP, EWS und alle anderen Clientconnections scheitern dann. OWA zeigt nach dem Login die berüchtigte Blank-Page.
Ich stellte fest, dass dies keine gute Idee in einem Exchange-Cluster (Exchange 2013) ist, in welchem die CAS und die Mailbox-Server nicht auf der gleichen Maschine liegen.
Die Kommunikation mit den Backend-Services wird dadurch unterbrochen und OWA, ECP, EWS und alle anderen Clientconnections scheitern dann. OWA zeigt nach dem Login die berüchtigte Blank-Page.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 303969
Url: https://administrator.de/contentid/303969
Ausgedruckt am: 21.11.2024 um 20:11 Uhr
6 Kommentare
Neuester Kommentar
Moin,
zu dem Thema hat Mircosoft letztes Jahr einen Artikel verfasst. Es sind auf seitens Exchange Server bestimmte Builds Vorraussetzung damit dein Vorhaben glückt.
Gruß,
Dani
zu dem Thema hat Mircosoft letztes Jahr einen Artikel verfasst. Es sind auf seitens Exchange Server bestimmte Builds Vorraussetzung damit dein Vorhaben glückt.
Gruß,
Dani
Der Artikel beschreibt sehr schön, dass man bis auf weiteres TLS 1.0 (wegen des Proxy) nicht deaktivieren kann. Sie wollen das Problem mit einem CU angehen. Tipp: CU12 beim Exchange Server 2013 hat das Problem noch nicht gelöst.
Zitat von @VeryBigM:
An diesem Wochenende wollte ich Microsofts Empfehlung folgen und SSL v3 und TLS 1.0 auf allen IIS deaktivieren
An diesem Wochenende wollte ich Microsofts Empfehlung folgen und SSL v3 und TLS 1.0 auf allen IIS deaktivieren
Bei SSl V3 grundsätzlich ja ne gute Sache, die zu diablen, da diese Verschlüsselungsart bereits unsicher ist.
Aber bei TLS V1.0?
Moin,
Wäre nicht "Warum überhaupt noch TLS1.1?" die bessere Frage? In einem Unternehmen sollten die Geräte ja ungefähr den gleichen Patchlevel haben, das heißt in diesem Fall sehr aktuell. Eigentlich können alle diese Geräte TLS1.2 wenn ich jetzt nicht irgendeinen externen Hansel auf dem jeweiligen System haben will, reicht es völlig wenn ich nur TLS1.2 unterstütze. Theoretisch!
Praktisch sehen wir ja leider dass es Microsoft irgendwie wieder nicht gebacken bekommt es so zu bauen. Wenn man Mozilla fragt unterstützen Moderne Webserver am besten nur noch TLS1.2.
Von daher stelle ich gerade wieder fest wie glücklich ich bin Sogo statt Exchange zu verwenden ^^.
Gruß
Chris
Wäre nicht "Warum überhaupt noch TLS1.1?" die bessere Frage? In einem Unternehmen sollten die Geräte ja ungefähr den gleichen Patchlevel haben, das heißt in diesem Fall sehr aktuell. Eigentlich können alle diese Geräte TLS1.2 wenn ich jetzt nicht irgendeinen externen Hansel auf dem jeweiligen System haben will, reicht es völlig wenn ich nur TLS1.2 unterstütze. Theoretisch!
Praktisch sehen wir ja leider dass es Microsoft irgendwie wieder nicht gebacken bekommt es so zu bauen. Wenn man Mozilla fragt unterstützen Moderne Webserver am besten nur noch TLS1.2.
Von daher stelle ich gerade wieder fest wie glücklich ich bin Sogo statt Exchange zu verwenden ^^.
Gruß
Chris
Moin,
das geht weiter mit Geräten welche per Outlook Anywhere, Active Sync, Sharepoint, etc... dranhängen. Somit wird solch eine "simple" Sache auf einmal komplex und unübersichtlich. Da kann soll ein Vorhaben ganz schnell eine Produktivumgebung lahmlegen.
Ich weiß nicht wie ihr euch das Entwicklungumgebung von Microsoft vorstellen. Bei der Anzahl von Produkten und den möglichen Kombinationen und Abhängigkeiten ist das sicher kein leichtes Unterfangen.
Gruß,
Dani
das geht weiter mit Geräten welche per Outlook Anywhere, Active Sync, Sharepoint, etc... dranhängen. Somit wird solch eine "simple" Sache auf einmal komplex und unübersichtlich. Da kann soll ein Vorhaben ganz schnell eine Produktivumgebung lahmlegen.
Ich weiß nicht wie ihr euch das Entwicklungumgebung von Microsoft vorstellen. Bei der Anzahl von Produkten und den möglichen Kombinationen und Abhängigkeiten ist das sicher kein leichtes Unterfangen.
Gruß,
Dani
Moin,
Nun ja, das sollte aber auch da nicht an der Crypto scheitern. Diese Läuft zwischen Layer4 und 5 ab und setzt auf systemweite Bibliotheken. Nehmen wir z.B. eine Anwendung die auf OpenSSL basiert. Gebe ich hier als Entwickler gar keinen Defaultwert an, was die Crypto-Algorithmen angeht, nimmt die Bibliothek ihren ganz eigenen Standard der zum Compilierzeitpunkt oder über die systemweiten Einstellungen geregelt wird. Ich kann aber ebenso ziemlich genau bestimmen was ich haben will und was nicht indem ich den entsprechenden Parameter setze. Wenn ich also nur etwas sauberen Code produziere bei der Implementierung meiner Anwendungen sollte ich immer alle Crypto-Algorithmen bereitstehen haben, die eine gewisse Grenze nicht unterschreiten. diese untere Grenze sollte man bei sauberem Code festlegen, die obere nicht.
Hier unterscheiden sich übrigens OpenSSL und die Windows-eigenen Bibliotheken nicht besonders. Sobald also alle Geräte(!)/OS-Instanzen TLS1.2 akzeptieren sollten sie zum einen nur noch TLS1.2 Ciphersuiten benutzen und zum anderen sollte ich auch die Möglichkeit haben bei beliegen Geräten alle nicht TLS1.2 Ciphersuiten abzuschalten. Wenn jetzt was kaputt geht, heißt das, dass irgendwie eine Schnittmenge an Cipheralgorithmen fehlt. Aber im Normalfall sollte das wirklich nicht auftreten, alle gängigen Bibliotheken (Windows/OpenSSL/GNUtls/...) können eigentlich auf TLS1.2 sauber kommunizieren, wenn man die Cipher nicht noch händisch zusätzlich beschneidet.
Das heißt also irgendwo ist da Dreck, den man eigentlich nicht haben will. Den Rest überlasse ich nun dir ;)
Gruß
Chris
Nun ja, das sollte aber auch da nicht an der Crypto scheitern. Diese Läuft zwischen Layer4 und 5 ab und setzt auf systemweite Bibliotheken. Nehmen wir z.B. eine Anwendung die auf OpenSSL basiert. Gebe ich hier als Entwickler gar keinen Defaultwert an, was die Crypto-Algorithmen angeht, nimmt die Bibliothek ihren ganz eigenen Standard der zum Compilierzeitpunkt oder über die systemweiten Einstellungen geregelt wird. Ich kann aber ebenso ziemlich genau bestimmen was ich haben will und was nicht indem ich den entsprechenden Parameter setze. Wenn ich also nur etwas sauberen Code produziere bei der Implementierung meiner Anwendungen sollte ich immer alle Crypto-Algorithmen bereitstehen haben, die eine gewisse Grenze nicht unterschreiten. diese untere Grenze sollte man bei sauberem Code festlegen, die obere nicht.
Hier unterscheiden sich übrigens OpenSSL und die Windows-eigenen Bibliotheken nicht besonders. Sobald also alle Geräte(!)/OS-Instanzen TLS1.2 akzeptieren sollten sie zum einen nur noch TLS1.2 Ciphersuiten benutzen und zum anderen sollte ich auch die Möglichkeit haben bei beliegen Geräten alle nicht TLS1.2 Ciphersuiten abzuschalten. Wenn jetzt was kaputt geht, heißt das, dass irgendwie eine Schnittmenge an Cipheralgorithmen fehlt. Aber im Normalfall sollte das wirklich nicht auftreten, alle gängigen Bibliotheken (Windows/OpenSSL/GNUtls/...) können eigentlich auf TLS1.2 sauber kommunizieren, wenn man die Cipher nicht noch händisch zusätzlich beschneidet.
Das heißt also irgendwo ist da Dreck, den man eigentlich nicht haben will. Den Rest überlasse ich nun dir ;)
Gruß
Chris
