SSLv3: Abschalten ist angesagt...

[raymond]

@raymond
Outlook war nur ein Bsp. Was ist mit alten Mailservern/mailversendenden Anwendungen welche Dir Mails zustellen wollen und die nur SSLv3 (oder schlechter) können? Die zwingst du dann unverschlüsselt zu übermitteln. Wobei JEDE SSLv3 Verschlüsselung von der Sicherheit her der Plaintextübertragung vorzuziehen ist. SSLv3 zu deaktivieren ist gut bei Verbindungen welche nur verschlüsselt funzen (z.B. https oder IMAPS). Bei oportuinistischem SSL (z.B. STARTTLS bei SMTP) senkt das Deaktivieren von SSLv3 die Sicherheit aber

Dann muss die Anwendung angepasst werden und nicht ältere und unsichere Protokolle sollten bis in die Ewigkeit unterstützt werden.

 

[Frogman]

Kann es sein, dass ich über den Bootstrap-Installer noch die IPKG installieren muss?! Habe dazu hier was gelesen: http://www.synology-wiki.de/index.php/Bootstrap_Installer und das hat mich dann zu den Infos gebracht, wie die IPKG konfiguriert werden soll (http://www.synology-wiki.de/index.php/IPKG#Konfiguration). Muss ich da komplett durch nur um den MC zu installieren, damit ich SSLv3 installieren kann?!

Also weder benötigst Du IPKG, um den mc zu installieren, noch geht es hier darum, SSLv3 zu installieren (denn das soll deaktiviert werden). Und auch mc musst Du nicht installieren - wie gesagt, der mc wäre eine Unterstützung, wenn Du Dich auf der Konsole unwohl fühlst. Alle Änderungen kannst Du - wie oben beschrieben - direkt auch auf der Konsole mit dem vi-Editor machen.

 

[hopeless]

Oder du installierst dir auf deinem Windows Rechner WinSCP und bearbeitest damit die Dateien. Das ist IMHO der einfachste Weg.

 

[jahlives]

Dann muss die Anwendung angepasst werden und nicht ältere und unsichere Protokolle sollten bis in die Ewigkeit unterstützt werden.

und du glaubst du kannst die Gegenseite durch Deaktivieren von SSLv3 dazu zwingen? Die bekommt es ja nichtmal mit
Es gibt mehrere prominente deutsche Firmen die bei SMTP-zu-SMTP noch mit SSLv3 reinkommen (das ist aktuell gerade ein ziemlicher Brüller auf der Postfix Mailingliste

 

[Frogman]

...Es gibt mehrere prominente deutsche Firmen die bei SMTP-zu-SMTP noch mit SSLv3 reinkommen

Tatsächlich mit SSLv3 als Maximum? Das wär ja echt 'n Witz... But anyway, wie Du ja auch zuvor zu Recht gesagt hast, letztlich ist die Deaktivierung von SSLv3 nur ein Puzzleteil im Ganzen, es geht im Kern auch darum, dass ein unnötiges Protokolldowngrade verhindert oder zumindest erschwert werden sollte (eben auch für höhere TLS). Eben jenes wird jetzt mit der gerade freigegebenen OpenSSL 1.0.1j nachgezogen (bzw. mit den Versionen 1.0.0o und 0.9.8zc für die älteren Zweige), wo per default die Unterstützung von TLS_FALLBACK_SCSV als Fallback Protection enthalten ist. Damit wird verhindert, dass bei einer MITM-Attacke das Protokoll geringer festgelegt werden kann als das kleinere der beiden, die von Server bzw. Client maximal unterstützt werden. Da Synology in der jüngsten Zeit recht flott war mit dem Nachziehen ihrer Sicherheitsupdates, darf man ja hoffen, dass die neue Version zeitnah mit einem Update Einzug hält...

 

[mic_wag]

Also weder benötigst Du IPKG, um den mc zu installieren, noch geht es hier darum, SSLv3 zu installieren (denn das soll deaktiviert werden). Und auch mc musst Du nicht installieren - wie gesagt, der mc wäre eine Unterstützung, wenn Du Dich auf der Konsole unwohl fühlst. Alle Änderungen kannst Du - wie oben beschrieben - direkt auch auf der Konsole mit dem vi-Editor machen.

ja, das hattest du ja geschrieben, dass man das auch über den vi-Editor machen kann. Aber du hast dann auch geschrieben, dass der MC komfortabler ist. Ich habe mir darauf hin mal versucht den vi-Editor anzuschauen, um mir eine eigenens Bild zu machen. Konnte ihn auf meiner DS erst mal nicht finden und habe dann schließlich im Wiki nach mehr Infos über den vi gesucht (http://www.synology-wiki.de/index.php/Vi) und danach war mir eigentlich klar, dass ich es lieber mit dem MC versuchen wollte.
Den vi habe ich auf meiner DS übrigens immer noch nicht gefunden und weiß immer noch nicht, wie er aufgerufen wird.
Und der MC läuft auch noch nicht und auch da bin ich weiterhin ratlos.
Vielleicht sollte ich auf ein zeitnahes Sicherheitsupdate von Synology hoffen?! Eigentlich nicht meine favorisierte Lösung ...

 

[mic_wag]

@hopeless
Danke für den Hinweis, das schaue ich mir gerne mal an. Mal schauen, ob ich damit besser zum Ziel komme.

 

[Frogman]

...Den vi habe ich auf meiner DS übrigens immer noch nicht gefunden und weiß immer noch nicht, wie er aufgerufen wird....

In der Konsole anmelden (wie ebenfalls im Wiki beschrieben) und dort ein vi Pfad/Dateiname eingeben... steht alles im Wiki

 

[jahlives]

Zum Thema gerade noch was gefunden: http://www-01.ibm.com/support/docview.wss?uid=swg27039743&aid=1 (Folie 3 ist interessant). Da hat also IBM sicher Nachholbedarf

 

[Frogman]

Habe gerade die gestrige offizielle Verlautbarung von Synology zum POODLE gefunden. Nebenbei erfahren wir dort, dass die DSM-5.1 Release im November erscheint (gut, das war jetzt nicht sooooo eine Überraschung ) und den Patch (vermutlich die Integration der OpenSSL 1.0.1j) enthalten wird.

 

[Frogman]

Wie vermutet enthält die gerade erschienene DSM-5.1 die aktuelle OpenSSL 1.0.1j-fips 15 Oct 2014. Damit wird also die Fallback-Protection unterstützt. SSLv3 ist standardmäßig für den Webserver und auch SMTP-Serverkommunikation deaktiviert (smtpd_tls_protocols = !SSLv2, !SSLv3 sowie smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3).

 

[Frogman]

Den einen oder anderen mag es interessieren - Synology hat sich dieses Mal für das Release der DSM-5.1 erheblich Gedanken um die Sicherheit bei den SSL-Einstellungen gemacht (die waren in den letzten Versionen nicht so wirklich das Gelbe vom Ei, wie man in diesem Thread nachlesen kann). Nicht nur die Deaktivierung von SSLv3 war dabei ein Thema, sondern auch die Cipher-Einstellungen und deren Priorisierung.
Der Standard in der httpd-ssl.conf-common lautet nun

SSLCipherSuite HIGH:!EXPORT:!eNULL:!aNULL:!DES:!RC4:!RC2:!MD5:!IDEA:!SEED:!CAMELLIA:+AES128:+AES256:+3DES:+kEECDH:+kRSA:!EDH:!aECDH:!aECDSA:!kECDHe:!SRP:!PSK
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3

womit alle EC-Ciphren hoch priorisiert werden, gefolgt von AES:

DS713> openssl ciphers -V HIGH:!EXPORT:!eNULL:!aNULL:!DES:!RC4:!RC2:!MD5:!IDEA:!SEED:!CAMELLIA:+AES128:+AES256:+3DES:+kEECDH:+kRSA:!EDH:!aECDH:!aECDSA:!kECDHe:!SRP:!PSK
          0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
          0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
          0xC0,0x13 - ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
          0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
          0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
          0xC0,0x14 - ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
          0xC0,0x12 - ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
          0x00,0x9C - AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
          0x00,0x3C - AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
          0x00,0x2F - AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
          0x00,0x9D - AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
          0x00,0x3D - AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
          0x00,0x35 - AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
          0x00,0x0A - DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1

Ob nun AES128 oder AES256 höher priorisiert werden, ist eher dem eigenen Geschmack überlassen - 128bit ist hier perfomanceseitig im Vorteil, die Stärke ist trotz theoretischer Betrachtung dabei immer noch in Gänze unangefochten. Alle DHE-Ciphren werden dagegen ausgeschlossen - hier ergibt sich wegen der Nutzung des Apache in Version 2.2.x ja immer noch die Reduktion in den DH-Parametern auf einen effektiven Schlüssel mit 1024 bit.
Allenfalls sollte man darüber nachdenken, 3DES auszuschließen, dieses wird nur aus Kompatibilitätsgründen mitgeschleppt - der IE8 unter WindowsXP kann eben nix anderes.
Mit der hier erwähnten Anpassung für HTTP Strict Transport Security ergibt sich damit beim Servertest der SSLLabs aktuell dieses Ergebnis:





Resumee für die User: per default also schon sehr gut eingestellt, echten Handlungsbedarf für Optimierungen gibt es praktisch nicht!

 

[hopeless]

Resumee für die User: per default also schon sehr gut eingestellt, echten Handlungsbedarf für Optimierungen gibt es praktisch nicht!

Komisch, ich bekomme nach dem Einfügen von

Header add Strict-Transport-Security: "max-age=15768000"

in die httpd-conf nur ein:

 

[Frogman]

Nimm einmal den Doppelpunkt heraus - und das Ganze dann in die httpd-alt-port-ssl-setting.conf bzw. httpd-ssl.conf-common, nicht in die httpd.conf

 

[hopeless]

Ops, der Doppelpunkt war gar nicht drin, da ich die Synokonfig nicht mehr offen hatte, habe ich das von einer anderen Webseite kopiert. Aber egal, auch mit dem Einfügen in die httpd-alt-port-ssl-setting.conf bzw. httpd-ssl.conf-common bekomme ich ein "F".

Benutze ich die alten, von mir angepassten httpd-alt-port-ssl-setting.conf bzw. httpd-ssl.conf-common, bekomme ich ein "A".

Hier die original httpd-alt-port-ssl-setting.conf:

ServerName *
ServerAlias *

SSLEngine on
SSLCipherSuite HIGH:MEDIUM
SSLProtocol all -SSLv2
SSLCertificateFile /usr/syno/etc/ssl/ssl.crt/server.crt
SSLCertificateKeyFile /usr/syno/etc/ssl/ssl.key/server.key
SSLCertificateChainFile /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt

und die original httpd-ssl.conf-common:

SSLRandomSeed startup builtin
SSLRandomSeed connect builtin

AddType application/x-x509-ca-cert  .crt
AddType application/x-pkcs7-crl     .crl

SSLPassPhraseDialog  builtin

SSLSessionCache         "shmcb:/run/httpd/ssl_scache(512000)"
SSLSessionCacheTimeout  300

SSLMutex "file:/run/httpd/ssl_mutex"

SSLCipherSuite HIGH:!EXPORT:!eNULL:!aNULL:!DES:!RC4:!RC2:!MD5:!IDEA:!SEED:!CAMELLIA:!AESGCM:+AES128:+AES256:+3DES:+kEECDH:+kRSA:!EDH:!aECDH:!aECDSA:!kECDHe:!SRP:!PSK
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3

SSLCertificateFile      "/usr/syno/etc/ssl/ssl.crt/server.crt"
SSLCertificateKeyFile   "/usr/syno/etc/ssl/ssl.key/server.key"

SSLCertificateChainFile /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt

#SSLCACertificatePath "/etc/httpd/conf/ssl.crt"
#SSLCACertificateFile "/etc/httpd/conf/ssl.crt/ca-bundle.crt"

#SSLCARevocationPath "/etc/httpd/conf/ssl.crl"
#SSLCARevocationFile "/etc/httpd/conf/ssl.crl/ca-bundle.crl"

 

[Frogman]

Du hast nach den Änderungen neugestartet und auf SSLabs auch auf 'Cache löschen' geklickt und einen neuen Check gemacht?
Mit der Zeile

[COLOR=#333333]SSLCipherSuite HIGH:!EXPORT:!eNULL:!aNULL:!DES:!RC4:!RC2:!MD5:!IDEA:!SEED:!CAMELLIA:!AESGCM:+AES128:+AES256:+3DES:+kEECDH:+kRSA:!EDH:!aECDH:!aECDSA:!kECDHe:!SRP:!PSK
[/COLOR]

kommen nur die von mir oben geposteten Cipher-Suites zu Anwendung - der Downgrade auf "F" wegen anonymer Ciphren kann nicht sein.

 

[jahlives]

nur so aus Neugier Wieso kein AESGCM und dann ein 3DES erlauben

 

[Frogman]

Ups, ich hab die Zeile nur von hopeless' Post kopiert.
Oben bei meinem Post #32 ist AESGCM nicht ausgeschlossen, wie man dann darunter in der Cipherliste auch sieht - und das sind die Default-Werte bei der 713+. Sollte es tatsächlich bei unterschiedlichen Modellen unterschiedliche Cipher-Konfigs geben?
Gut, AESGCM hat eine kleine Schwäche in der OpenSSH 6.2/6.3, wie ich gerade nachgelesen habe. Aber das dürfte hier kaum ziehen...

 

[hopeless]

Du hast nach den Änderungen neugestartet und auf SSLabs auch auf 'Cache löschen' geklickt und einen neuen Check gemacht?

Ja hatte ich . Ich forsche da jetzt auch nicht weiter, sondern benutzte einfach meine angepassten httpd-alt-port-ssl-setting.conf bzw. httpd-ssl.conf-common.

Sollte es tatsächlich bei unterschiedlichen Modellen unterschiedliche Cipher-Konfigs geben?

Das wäre natürlich ganz bitter

 

[Frogman]

Welche DS hast Du denn hier?

Aber wenn Du bei den Einstellungen oben tatsächlich ein 'F' hast, dann müssen woanders noch andere SSL-Einstellungen bei Dir herumschwirren. Wie gesagt - anonyme Ciphren sind zumindest nach der Festlegung in der httpd-ssl.conf-common ausgeschlossen.