Mindestsicherheit der TLS-Transportverschlüsselung

[Marvin]

Eine Kundin hat mich auf das Tool von comcrypto (Testmail senden auf Startseite anklicken) aufmerksam gemacht, welches meldet, dass NoSpamProxy Cloud die Mindestsicherheit der TLS-Transportverschlüsselung beim Versand nicht gewährleistet.



Weiß jemand zufällig, wie das Testergebnis zu interpretieren ist? Direkt nachvollziehen kann ich es nämlich nicht.

 

[869288141]

Im Rahmen der Transparenz Offensive. Wir haben das Thema bereits hier (Link) angefangen zu diskutieren.

---

Weiß jemand zufällig, wie das Testergebnis zu interpretieren ist? Direkt nachvollziehen kann ich es nämlich nicht.

Meine/Eine Interpretation habe ich dir hier (Link) mitgeteilt. An deiner Stelle bin ich so "frech" und würde einfach dem Support von comcrypto GmbH schreiben. Da auf der Internetseite keinerlei Informationen zu Logik und Interpretation zu finden sind, bleibt dir auch keine andere Möglichkeit.

Abgesehen davon haben Tools, welche Hersteller abhängig sind, grundsätzlich ein Beigeschmack. Ganz nach dem Motto: Traue keine Statistik welche du nicht selbst gefälscht hast. Vergleichen schön und gut. Aber nur Tools, welche Open Source sind, damit die Ergebnisse auch jederzeit nachvollziehbar sind.

 

[Marvin]

Ich wurde gestern von comcrypto kontaktiert und mir wurde eine Erläuterung angeboten, Daniel.
Nächste Woche gebe ich dazu eine Rückmeldung.

Was mir gerade noch eingefallen ist: NoSpamProxy Cloud unterstützt MTA-STS und DANE noch nicht, oder? Vielleicht gibt es dort auch einen Zusammenhang.



Hardenize:

Microsoft Remote Connectivity:


Einen Beigeschmack haben alle Tools für mich. Deshalb probiere ich gerne mal durch.
Einen Report vom Klassiker testssl.sh erstelle ich bis dahin auch noch.

 

[869288141]

Hallo Marvin,

Ich wurde gestern von comcrypto kontaktiert und mir wurde eine Erläuterung angeboten, Daniel.

Freut mich zu hören... ein kleines Weihnachtswunder.

Was mir gerade noch eingefallen ist: NoSpamProxy Cloud unterstützt MTA-STS und DANE noch nicht, oder? Vielleicht gibt es dort auch einen Zusammenhang.

Die Einrichtung und Konfiguration der beiden Technologien ist Produkt unabhängig. Dies obliegt in diesem Fall dem Postmaster/Webmaster und dem Verantwortlichen für die jeweilige DNS-Zone.

Meines Wissens nach wird von NoSpamProxy DANE ausgewertet, wenn ein Eintrag vorhanden ist. Macht natürlich nur Sinn, wenn die betroffene DNS-Zone über DNSSEC verfügt. Bei MTA-STS bin ich mir gerade unsicher. Aber ich meine, dass dies noch nicht implementiert ist.

Wobei bei ich keine 100 Unternehmen in Deutschland kenne, die MTA-STS (korrekt) eingerichtet haben.

Einen Beigeschmack haben alle Tools für mich. Deshalb probiere ich gerne mal durch.

Da kann ich dir nicht folgen. In wie fern?


Gruß,
Daniel

 

[Marvin]

Da kann ich dir nicht folgen. In wie fern?

Das war eine eher allgemeine philosophische Anmerkung. Nichts ist perfekt und menschliches Erleben ist nie rein.

 

[Marvin]

Hier ist das Ergebnis von testssl.sh:


Spricht etwas gegen eine Aktivierung von TLS 1.3? Meiner Meinung nach hätte das eigentlich keinen Nachteil, oder?
Ansonsten sieht das Resultat super aus.

 

[Marvin]

Meines Wissens nach wird von NoSpamProxy DANE ausgewertet, wenn ein Eintrag vorhanden ist.

Ich habe nach einem TLSA-DNS-Eintrag für nospamproxy.com geschaut und keinen gefunden. Deshalb bin ich etwas stutzig.
Ich denke auch, dass DANE unterstützt wird und MTA-STS noch nicht. Sicher bin ich mir aber nicht.

 

[869288141]

Hallo Marvin,

Spricht etwas gegen eine Aktivierung von TLS 1.3?

setzt voraus, dass eine Windows Server Version eingesetzt wird, welche TLS 1.3 mit bringt. Weil NoSpamProxy verwendet die Funktion Schannel von Windows (Server).

Ansonsten sieht das Resultat super aus.

Sehe ich anders:

• CBC gehört aus meiner Sicht heute nicht mehr in eine moderne Konfiguration.
• Diffie-Hellman mit weniger als 2048 Bit ist bereits grenzwertig – zukunftsorientiert sollte man eher 4096 Bit ansetzen.
• TLS 1.3 betrachte ich inzwischen als De-facto-Standard.

Das ist das schöne in der Cloud. Da kann man erst einmal mit dem Finger auf den Anbieter zeigen. Ist aber meine persönliche Meinung.

Ich habe nach einem TLSA-DNS-Eintrag für nospamproxy.com geschaut und keinen gefunden. Deshalb bin ich etwas stutzig.

Wir reden von zwei verschiedenen Dingen. Du redest von der Bereitstellung eines DANE Eintrags für (d)eine Cloud Instanz. Ich rede davon, dass NoSpamProxy einen vorhandenen DANE Eintrag des vermeidlichen Absenders auswertet (Link).

Gruß,
Daniel

 

[Fabian]

Sehe ich anders:

• CBC gehört aus meiner Sicht heute nicht mehr in eine moderne Konfiguration.
• Diffie-Hellman mit weniger als 2048 Bit ist bereits grenzwertig – zukunftsorientiert sollte man eher 4096 Bit ansetzen.
• TLS 1.3 betrachte ich inzwischen als De-facto-Standard

Bei uns wurde jüngst auch die Entscheidung gegen CBC getroffen
Begleitet von einer Impact-Analyse der MSSQL-DB (was so noch mit CBC spricht/ sprach) wurde nun final der Stecker gezogen.

Hauptbegründung neben den wenigen Partnern, die es noch benötigen: Das BSI empfehle die Verwendung der CBC-Cipher-Suiten nur mit der TLS-Erweiterung „Encrypt-then-MAC".

Da Windows dies nicht bietet + wenig Verkehr-> Weg damit.

Ggf. eine Argumentationshilfe für andere Betriebe.

LG
Fabian

 

[JanJäschke]

Hallo zusammen =)

Ich melde mich hier im neuen Jahr auch mal noch zu Wort:
DANE ist mittlerweile für alle Shared Cloud Kunden aktiv ausgerollt.
Wir hatten damit bereits Ende letzten Jares begonnen und letzte Woche wurde dies final für alle ausstehenden durchgezogen =)
Wenn ihr nun eine Prüfung macht nicht wundern es werden einige Zertifikate angezeigt und das ist richtig so.

TLS 1.3 wird noch für alle Kunden kommen, ein Teil haben dies bereits. Daniel hat es schon erkannt es liegt hier einfach an den Windows Server Versionen die auch mit Updates einfach leider nicht sauber TLS 1.3 bekommen, das bedeutet wir müssen die kompletten Instanzen austauschen. Dies machen wir entsprechend mit größter Vorsicht und möglichst so, dass es keiner mitbekommt - was uns ja bei einigen schon geglückt ist
Hier heißt es also noch etwas gedulden.
Damit einhergehend werden auch die TLS Richtlinien von uns verschärft werden, bisher liefen wir im "Kompatibilitäts-Modus" um möglichst wenig Aufruhr bei den Kunden zu haben, da die Anfragen sich aber häufen werden wir nun die Strikteren Richtlinien umsetzen und dann entsprechend auf Anfragen auf reagieren, es gibt eben nur entweder / oder ^^


LG
Jan

 

[Marvin]

Hallo zusammen =)

Ich melde mich hier im neuen Jahr auch mal noch zu Wort:
DANE ist mittlerweile für alle Shared Cloud Kunden aktiv ausgerollt.
Wir hatten damit bereits Ende letzten Jares begonnen und letzte Woche wurde dies final für alle ausstehenden durchgezogen =)
Wenn ihr nun eine Prüfung macht nicht wundern es werden einige Zertifikate angezeigt und das ist richtig so.

TLS 1.3 wird noch für alle Kunden kommen, ein Teil haben dies bereits. Daniel hat es schon erkannt es liegt hier einfach an den Windows Server Versionen die auch mit Updates einfach leider nicht sauber TLS 1.3 bekommen, das bedeutet wir müssen die kompletten Instanzen austauschen. Dies machen wir entsprechend mit größter Vorsicht und möglichst so, dass es keiner mitbekommt - was uns ja bei einigen schon geglückt ist
Hier heißt es also noch etwas gedulden.
Damit einhergehend werden auch die TLS Richtlinien von uns verschärft werden, bisher liefen wir im "Kompatibilitäts-Modus" um möglichst wenig Aufruhr bei den Kunden zu haben, da die Anfragen sich aber häufen werden wir nun die Strikteren Richtlinien umsetzen und dann entsprechend auf Anfragen auf reagieren, es gibt eben nur entweder / oder ^^


LG
Jan

Vielen Dank für euren Einsatz.

 

[869288141]

Hallo Jan,

Daniel hat es schon erkannt es liegt hier einfach an den Windows Server Versionen die auch mit Updates einfach leider nicht sauber TLS 1.3 bekommen, das bedeutet wir müssen die kompletten Instanzen austauschen.

auch nicht mit einem Reset mit Hilfe von IIS Crypto? Funktionierte hier auf mehreren 100 Servern problemlos.

Wenn ihr nun eine Prüfung macht nicht wundern es werden einige Zertifikate angezeigt und das ist richtig so.

Bis dato sehe ich auf nospampoxy.com nach wie vor nur ein TLS Wirdcard Zertifikat. Ausnahme von der Regel?

Damit einhergehend werden auch die TLS Richtlinien von uns verschärft werden,

Ja bitte, unbedingt! Höchste Eisenbahn.


Gruß,
Daniel

 

[869288141]

Hallo @Marvin

Ich wurde gestern von comcrypto kontaktiert und mir wurde eine Erläuterung angeboten, Daniel.
Nächste Woche gebe ich dazu eine Rückmeldung.

was ist in dem Gespräch herausgekommen?


Gruß,
Daniel

 

[JanJäschke]

Hey =)

Nein auch mit den IIS Crypto Anpassungen nicht.

Die Domäne "nospamproxy.com" hat nichts mit der Cloud oder dessen Infrastruktur zu tun, diese wird rein vom unternehmen in Ihrer eigenen Umgebung verwendet und von der IT verwaltet. Hin und wieder wird damit auch mal was ausprobiert um Impact am Produktiven Mail Verkehr zu testen, das bedeutet diese kann nicht immer zwangsläufig als Referenz verwendet werden.

LG
Jan

 

[869288141]

Hallo Jan,

Nein auch mit den IIS Crypto Anpassungen nicht.

Du hast mein Interesse geweckt. Ist es denkbar solch eine VM ohne Kundendaten/Installation und Lizenzschlüssel zu exportieren und zur Verfügung zustellen? Mich würde die Ursache brennend interessieren. Meine Finger jucken schon...


Gruß
Daniel

 

[JanJäschke]

Haha das verstehe ich, ist aber technisch nicht sinnvoll für uns umsetzbar ^^

Die letzten Systeme wurden jetzt am WE umgezogen, damit sollte sich das nun ehverledigt haben. Nun müssen nur noch die TLS Anpassungen vorgenommen werden.
Daher machen wir da nun endlich einen Haken hinter

 

[869288141]

Hallo Jan,

Haha das verstehe ich, ist aber technisch nicht sinnvoll für uns umsetzbar ^^

Oha, sinnvoll und umsetzbar in einem Satz. Du wärst ein Kandidat für unser Buzzword-Bingo auf Arbeit. Immer gefährdet.
Schade.

Bis dato sehe ich auf nospampoxy.com nach wie vor nur ein TLS Wirdcard Zertifikat. Ausnahme von der Regel?

ch habe mir mehrere Kunden aus der DNS-Zone mail.cloud.nospamproxy.com angesehen. Bei allen Tests wird ausschließlich das TLS-Wildcard-Zertifikat *.mail.cloud.nospamproxy.com ausgeliefert. Übersehe ich hier etwas, oder erfolgt die Anpassung/Umstellung erst beim nächsten Zertifikats-Renew?

Abgesehen davon ist es Absicht, dass die DH weiterhin bei 1024 Bits ist?

 x9f     DHE-RSA-AES256-GCM-SHA384         DH 1024    AESGCM      256      TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
 x9e     DHE-RSA-AES128-GCM-SHA256         DH 1024    AESGCM      128      TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
...
DH group offered:            RFC2409/Oakley Group 2 (1024 bits)
...
OGJAM (CVE-2015-4000), experimental      VULNERABLE (NOT ok): common prime: RFC2409/Oakley Group 2 (1024 bits),

Gruß
Daniel

 

[JanJäschke]

ch habe mir mehrere Kunden aus der DNS-Zone mail.cloud.nospamproxy.com angesehen. Bei allen Tests wird ausschließlich das TLS-Wildcard-Zertifikat *.mail.cloud.nospamproxy.com ausgeliefert. Übersehe ich hier etwas, oder erfolgt die Anpassung/Umstellung erst beim nächsten Zertifikats-Renew?

Da hab ich mich was ungenau ausgedrückt.
Es sind mehrere Public Key Hashes.

Auf TLS Ebene werden wir vorerst bei einem wildcard Zertifikat bleiben.
Im DANE record wird TLSA certificate usage als „3 1 1“ beschrieben. Wir machen damit ein explizites pinning auf den public key des aktuell genutzten Zertifikats in gehashter Form.
Eine simple Aufschlüsselung haben wir hier mal erklärt:

Absenderreputation und E-Mail-Sicherheit – Teil 5: DANE | NoSpamProxy

In Teil 5 unserer Artikelserie zum Thema "Verfahren zur Überprüfung der Absenderreputation" geht es um DANE. Was ist DANE?

www.nospamproxy.de

Abgesehen davon ist es Absicht, dass die DH weiterhin bei 1024 Bits ist?

Die Härtung kommt erst noch, die Aktualisierung erfolgt in zwei Etappen.

 

[Marvin]

Hallo @Marvin

was ist in dem Gespräch herausgekommen?


Gruß,
Daniel

Entschuldigt die verspätete Rückmeldung.

[...] das sendende System prüft weder die Authentizität der Empfänger noch die Sicherstellung der Datenintegrität und das ist sowohl für personenbezogene Daten, als auch im Sinne der Informationssicherheit nicht zulässig. [...]
=> Der Testserver bietet keinerlei Sicherheit:
U.a. Testaufbau mit groben Sicherheits-Mängeln u. A. Zertifikat 01.01.1970, Schlüssellängen nur RSA 1024bit, unsichere Cipher Suites aktiviert, nur TLS 1.1 aktiv [...]

Hier steht es ausführlich: https://www.comcrypto.de/wissen/unsicheren-mailserver-aufsetzen & https://www.comcrypto.de/tools/mail-server-test

 

[JanJäschke]

Entschuldigt die verspätete Rückmeldung.



Hier steht es ausführlich: https://www.comcrypto.de/wissen/unsicheren-mailserver-aufsetzen & https://www.comcrypto.de/tools/mail-server-test

Lese ich das richtig, dass sie sagen wir haben ein TLS Zertifikat mit Datum 01.01.1970 rausgegeben?