David SSL Sicherheit nach Rollout vom 31.10.2014 schlechter als zuvor [gelöst]

Jens Osterwohldt · 2. November 2014

Hallo,

auf der Webseite von Qualys SSL Labs kann man die SSL Sicherheit von Servern im Netz prüfen.
Diesen Test kann jeder über den Link mit seinem
eigenen Server ausführen. Ein selbst erstelltes Zertifikat führt jedoch direkt zu einer Abwertung.
Die vergebenen Noten orientieren sich am amerikanischen Notensystem A = 1 bis F = 6.

Wenn ein David Server mit einem Zertifikat eines Trustcenters nun auf diesem Weg getestet wird, war das
Ergebnis mit C (bis Webbox Version 944 aus dem September Rollout) schon nicht berauschend.
Mit dem neuen Oktober Rollout wurde es jedoch schlechter statt besser, nun gibt es die schlechteste Note
(ein F), die man mit einem Zertifikat bekommen kann.

Hier das Testergebnis des gleichen Servers einmal mit dem September Rollout, und ein weiteres Mal nach
dem Update auf das Oktober Rollout.

Test 1 (September Rollout): SSL Labs Rating C

Test 2 (Oktober Rollout): SSL Labs Rating F

Es ist zu hoffen, dass Tobit hier schnellstmöglich nachbessert und die bekannten SSL Lücken in der
David Webbox schließt. So ist die Sicherheit eher trügerisch. Als Workaround kann man die webbox.exe
aus dem September Rollout aus einer ggf. vorhandenen Sicherung wiederherstellen, dann stehen die
Neuerungen des Rollout aber natürlich für die Webbox nicht zur Verfügung.

Viele Grüße
Jens Osterwohldt

*stylistics* · 3. November 2014

Tobit sollte ganz auf SSL verzichten und die Kommunikation über TLS 1.x absichern, TLS wird von allen modernen Systemen beherrscht.
Auch die Absicherung über PFS wäre wünschenswert. Da die meiste Kommunikation über EAS laufen soll, und die meisten Smartphones
auch PFS/TLS beherrschen sehe ich keine Probleme, die "alt" Clients wie XP die Probleme haben können, sind das einzige Problem.
Auch das der Postman DANE nicht kann ist sehr schade!

PS: bei StartSSL.com bekommt man kostenlose SSL/TLS Server Zertifikate, einziger Nachteil die haben nur 12 Monate Gültigkeit.

Cento · 3. November 2014

Hallo

Die Web Seite überprüft nur, welche Verschlüsselungsverfahren der
Server unterstützt, nicht wie sicher die tatsächlich Zustande gekommene
Verbindung ist. Das F bedeutet also, dass die WebBox Verbindungen
auch von Clients akzeptiert, die minderwertige Verfahren benutzen.
Das ist aber in der Regel nur bei veralteten Clients der Fall. Ein kurzer
Test mit Chrome und Firefox und meinem Handy (via ActiveSync)
ergab, dass sie anders als vorher das sichere Schlüsselaustauschverfahren
per Diffie-Hellman Algorithmus benutzen. Das heißt, hier ist die
Verbindung im Gegenteil sicherer als vorher. Das nur als Anmerkung.

Es sollte aber schon in der Tat so sein, dass per Default keine
problematischen Verfahren akzeptiert werden, also solche Clients
vom Zugriff ausgeschlossen bleiben. Am besten wäre es, wenn das
überhaupt konfigurierbar wäre, eben auch ob SSL v3 zulässig ist
oder nicht etc.

Übrigens: Der Austausch der WebBox bringt gar nichts. Die SSL/TLS
Verbindungen werden durch die DLL davidtls.dll geregelt.

Cento

Cento · 3. November 2014

Hallo

Korrektur

Zitat von Cento

Übrigens: Der Austausch der WebBox bringt gar nichts. Die SSL/TLS
Verbindungen werden durch die DLL davidtls.dll geregelt.

Das stimmt wohl nicht, der Austausch von WebBox.exe allein scheint schon auszureichen.

Cento

Genesis · 5. November 2014

Sie schreiben doch

Q-111.578 SSL Optimierungen

Sagte ja keiner was von Verbesserung ;-O

*moep*

Jens Osterwohldt · 7. November 2014

Hallo,

das Rollout vom 07.11.2014 ändert an der SSL Sicherheit leider nichts. Wenn ein David Server mit nicht selbst erzeugtem Zertifikat den Test ausführt, bekommt man noch immer die schlechteste Note F (6).
Bis zum September Update war der David Server nur aufgrund der SSL Lücke zum Thema SSL3 (auch bekannt unter dem Namen Poodle) auf die Note C (3) heruntergestuft. Dieser SSL Bug ist auch noch immer vorhanden.
Den Fehler, der die Sicherheit auf Note F bringt, lässt sich durch das Wiederherstellen der Webbox.exe aus dem Rollout vom 03.09.2014 immerhin beseitigen. Hoffen wir also auf das nächste Rollout.

Viele Grüße
Jens Osterwohldt

Jens Osterwohldt · 1. Dezember 2014

Hallo,

mit dem Rollout vom 01.12.2014 wurde die SSL Schwachstelle behoben. Im KB Eintrag "Q-111.602 Weitere SSL Optimierungen" ist beschrieben wie Anpassungen der SSL Sicherheit gemacht werden können. Per Default Einstellung erhält der David Server nach dem neuen Rollout die Note C, wenn man die Datei "davidtls.ini" im Ordner \Windows\system32 auf dem David Server anlegt und den folgenden Inhalt einfügt:

[Settings]
SSLv3=no

verbessert sich die Note auf A- und damit wesentlich. Vielen Dank an den Support von Tobit für die schnelle Änderung.

Viele Grüße
Jens Osterwohldt

*stylistics* · 3. Dezember 2014

Mit dieser Konfig bekomme ich ein "A"

[Settings]
CipherSuite=EECDH+AES EDH+AES -SHA1 EECDH+RC4 EDH+RC4
EECDH+AES256 EDH+AES256 AES256-SHA !aNULL !eNULL !EXP !LOW
!MD5
SSLv3=no
TLS10=yes
TLS11=yes
TLS12=yes

Alledings bleiben OSse wie XP 2003 damit außen vor.

Mit dem Rollout vom 01.12.2014

stsm · 3. Dezember 2014

Zitat

Alledings bleiben OSse wie XP 2003 damit außen vor.

Rein aus Neugier: In Bezug auf was bleiben die aussen vor?

*stylistics* · 20. Juni 2016

Zitat von stsm

Rein aus Neugier: In Bezug auf was bleiben die aussen vor?

SSLv3 und die Chiffren

Baumi · 20. Juni 2016

Hallo,

muss die davidtls.ini immer noch bei Rollout 252 im Ordner \Windows\system32 liegen? In der Knowledgebase stand damals, das hier noch eine davidtls.dll liegen sollte.
Diese finde ich hier aber nicht.
Welche Einstellungen sollte man nutzen, wenn man nur die Synchronisierung per ActiveSync mit iPhones nutzen möchte. Webmail wird bei uns nicht genutzt.

Danke
Baumi

barabas · 21. Juni 2016

Hallo Baumi,

die Datei davidtls.ini muss nicht im Verzeichnis c:\windows\system32 liegen, sondern im gleichen Verzeichnis wie die Datei davidtls.dll, die z.B. bei 64-Bit-Windows in c:\windows\syswow64 zu finden ist

CU
Barabas

*stylistics* · 21. Juni 2016

Zitat von Baumi

Hallo,

muss die davidtls.ini immer noch bei Rollout 252 im Ordner \Windows\system32 liegen? In der Knowledgebase stand damals, das hier noch eine davidtls.dll liegen sollte.
Diese finde ich hier aber nicht.
Welche Einstellungen sollte man nutzen, wenn man nur die Synchronisierung per ActiveSync mit iPhones nutzen möchte. Webmail wird bei uns nicht genutzt.

Danke
Baumi

Wenn du die Einstellungen aus meinem Beispiel verwendest aber "TLS10=no" setzt reicht das völlig für iOS Geräte, sowie aktuelle Androiden und W10 Mobile.

Das sieht dann nach dem Check so aus:

Protocols enabled: TLS1.2 TLS1.1
Protocols not enabled: TLS1.0 SSLv3 SSLv2
Secure Renegotiation: Enabled
Downgrade attack prevention: Enabled
Next Protocol Negotiation: Not Enabled
Session resumption (caching): Enabled
Session resumption (tickets): Enabled
Strict Transport Security (HSTS): Not Enabled
SSL/TLS compression: Not Enabled
Heartbeat (extension): Enabled
RC4: Not Enabled
OCSP stapling: Not Enabled

Vulnerabilities checked:
Heartbleed, Poodle (TLS),Poodle (SSLv3),FREAK,BEAST,CRIME

Cipher suites enabled:
TLS_RSA_WITH_AES_128_CBC_SHA (0x002F)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003C)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003D)
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006B)
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009C)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009D)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009E)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009F)

Prüfen kann man das hier:
https://cryptoreport.websecurity.symantec.com/checker/

S&P · 23. Juni 2016

Zitat von stylistics

Mit dieser Konfig bekomme ich ein "A"

[Settings]
CipherSuite=EECDH+AES EDH+AES -SHA1 EECDH+RC4 EDH+RC4
EECDH+AES256 EDH+AES256 AES256-SHA !aNULL !eNULL !EXP !LOW
!MD5
SSLv3=no
TLS10=yes
TLS11=yes
TLS12=yes

Alledings bleiben OSse wie XP 2003 damit außen vor.

Mit dem Rollout vom 01.12.2014

Alles anzeigen

Hallo,
wenn ich die Einstellung 1:1 übernehme bauen einige Clients mit W7 keine Verbindung mehr zu David auf und Phones mit W10 mobile synchronisieren nicht.

cossys · 23. Juni 2016

Zitat von S&P

Hallo,
wenn ich die Einstellung 1:1 übernehme bauen einige Clients mit W7 keine Verbindung mehr zu David auf und Phones mit W10 mobile synchronisieren nicht.

Kann ich leider hinsichtlich iPhone auf einem Server 2008 R2 bestätigen

[mit nur SSLv3=no funktionierts]

Muß der Server danach eigentlich komplett neu gestartet werden oder reicht ein Neustart der Webbox / des Service-Layers

*stylistics* · 24. Juni 2016

Zitat von cossys

Kann ich leider hinsichtlich iPhone auf einem Server 2008 R2 bestätigen

[mit nur SSLv3=no funktionierts]

Muß der Server danach eigentlich komplett neu gestartet werden oder reicht ein Neustart der Webbox / des Service-Layers

Seit ein paar Monaten werden folgende Einstellungen genutzt:

[Settings]
CipherSuite=HIGH !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS
SSLv3=no
TLS10=no
TLS11=yes
TLS12=yes
ServerCipherOrder=no

Es werden nur Hohe/Starke Verschlüsselungs Chiffren mit über 128Bit Länge unterstützt. Es sind auch ein
paar Chiffren mit 128Bit dabei (für die Kompatibilität).
Es wird kein RC4 oder eNULL/aNULL also Chiffren ohne Verschlüsselung oder Authentifizierung verwendet,
und alles andere was nicht sicher ist wird "!" deaktiviert.

Alte Androiden/Windows Phones werden wohl wegen des wegfalls von TLS1.0 nicht mehr laufen....
Mehr Infos zu den mögliches Chiffren gibt es hier:

https://www.openssl.org/docs/manmaster/apps/ciphers.html

Wir nutzen diese Einstellung bei gut über hundert iOS Geräten bei Kunden, Ohne Probleme.... HostOSse der Server: 2008R2/2012/2012R2.
Aber ich nutze fast immer offizielle (kostenlose) Zertifikate von StartSSL...

Neu start der Webbox reicht.

Das wird daran liegen das hier die angegebenen Verschlüsselung Chiffren von den Clients und oder Browsern nicht unterstützt werden, bei Windows Phones in der Version bis 8
konnte ich diesen Fehler beim EAS beobachten. In der Testumgebung mit einem W10 Phone (Technical Preview) hatte ich keine Probleme. Bei Desktop Clients mit W7 liegt es
meist an den Browsern bzw. deren Einstellungen. Da hier nur die aktuellen Sicheren Chiffren welche z.b. Perfect Forward Secrecy unterstützen genutzt werden.
Da die meisten Benutzer meiner Kunden die Webbox fast ausschließlich für EAS benutzen hatte ich damit nie Probleme.

ag1 · 24. Juni 2016

Hallo,

auch ich konnte mit erst genannten Einstellungen von meinem IPHone aus keine Verbindung mehr zum Server aufbauen. Hab dann gerade mal die von stylistics heute geposteten Einstellungen probiert. Funktioniert zumindest bei mir (sogar noch Server 2003 R2) einwandfrei.

Danke!

Viele Grüße
ag1

georg2006 · 24. Juni 2016

Vielen Dank stylistics für die Bereitstellung deiner Einstellungen. Ich habe diese bei mir übernommen und habe mit unseren iOS Geräten und EAS damit keine Probleme.

David SSL Sicherheit nach Rollout vom 31.10.2014 schlechter als zuvor [gelöst]

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema