Perfect Forward Secrecy - Synology DS?

[Mike0185]

Hallo Community,

ich bin kein Profi und kein Sicherheitsexperte, aber dazu gibt es ja euch!

Ich habe eine DS-212+ und habe hierzu auch von StartSSL ein kostenloses SSL-Zertifikat. Nun habe bei heise.de den Bericht über "Perfect Forward Secrecy" gelesen und frage mich ob es:

a) möglich ist dies auch auf einer DS zu aktivieren? (und wenn ja: wie?)
b) hierzu auch ein neues SSL-Zertifikat benötigt wird?
c) es Sinn macht für einen Standard-User mit ein bisschen Webstation, Photostation, VPN, FileStation, usw. überhaupt so etwas zu nutzen?


Ich bin gespannt... oder nutzt ihr gar schon diese Art der Verschlüsselung?


Greetz `
Mike

 

[jahlives]

a) dem Apache mitteilen welche Ciphren er in welcher Reihenfolge offerieren soll (https://community.qualys.com/thread/9652?tstart=30)
b) nope
c) das musst du wissen
(d) ich nutze es bei mir, allerdings mit nginx als Webserver

 

[Mike0185]

Hallo Jahlives,

danke für deine Antwort.

Ich habe mal ein etwas rumgesucht... kann es sein dass die apache version auf der DS noch auf einem etwas älteren stand ist und daher einige Möglichkeiten eingeschränkt sind? Ich habe mal bei ssllabs ein test meines certs gemacht... Ich erhalte ein "B", mit den Hinweisen:

This server does not mitigate the BEAST attack. Grade capped to B.

Secure Renegotiation Supported
Secure Client-Initiated Renegotiation No
Insecure Client-Initated Renegotiation No
BEAST attack Vulnerable INSECURE
Compression No
RC4 No
Forward Secrecy (Experimental) No NOT DESIRABLE
Next Protocol Negotiation No
Session resumption No (IDs empty)
Session tickets Yes
OCSP stapling No
Strict Transport Security No
Long handshake intolerance No
TLS extension intolerance No
TLS version intolerance TLS 2.98
SSLv2 handshake compatibility Yes

Hat hier vielleicht noch jemand das ein oder andere HowTo dazu?


Grüße
Mike

 

[jahlives]

es hängt nicht primär von der Anwendung ab (Webserver oder Mailserver) welche Verschlüsselung genutzt werden kann. Denn die Anwendungen nutzen die Möglichkeiten der ssl-Library auf dem System. Es hängt also von der ssl-Lib an
Beim Apache gibt es unter obigem Link ja den Tip die Ciphren so auszuliefern

[COLOR=#4B4B4B][FONT=Arial][COLOR=#000000]SSLProtocol all -SSLv2[/COLOR][/FONT][/COLOR]
[COLOR=#4B4B4B][FONT=Arial][COLOR=#000000]SSLHonorCipherOrder On[/COLOR][/FONT][/COLOR]
[COLOR=#4B4B4B][FONT=Arial][COLOR=#000000]SSLCipherSuite 'AESGCM:RC4:SHA384:SHA256:AES[/COLOR][COLOR=#000000]!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!kEDH:!PSK:!SRP:!kECDH'[/COLOR]

Gegen die BEAST Attacke kannst du nur schützen wenn du RC4 Ciphren sehr weit vorne auslieferst. Denn RC4 ist nicht anfällig auf diese Art des Angriffs. Forward Secrecy wirst du eh nicht in allen Browsern schaffen. Dafür sind die verwendeten SSL/TLS Implementationen der Browser zu alt. Solange nicht alle Hersteller nicht mindestens TLS1.1+ unterstützen wird man leider solche "Hacks" mit den Ciphren machen müssen. Am besten wäre es nur noch TLS1.2 zu verwenden, aber dann sperrt man leider 90% der heutigen Browser aus
[/FONT][/COLOR]

 

[Mike0185]

Danke Jahlives für die Info! Ich habe es nun zumindest geschafft die "BEAST attack"-Problematik auszumerzen. Dabei hat mir auch diese Anleitung geholfen.

Meine Verbindung ist nun "nur" noch 128 Bit verschlüsselt mit TLS1.1 und RC4_128 (SHA1 / RSA wird für den Schlüsseltausch verwendet). Reicht das aus bzw. ist das nun normal (vorher 256 Bit)?

Habe genau dein Code eingefügt:

SSLProtocol all -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite 'AESGCM:RC4:SHA384:SHA256:AES!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!kEDH:!PSK:!SRP:!kECDH'

Beim SSLTest-Lab habe ich nun ein "A" geschafft:

 

[jahlives]

die 256bit von vorher waren wahrscheinlich eine CBC Ciphre und die sind eben anfällig auf BEAST. Durch das "Vorschieben" von RC4 umgehst du zwar BEAST, hast aber meist nur 128bit
Bei meinen Servern habe ich vor RC4 noch

ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:......

Die Warnung bei RC4 ist normal wenn man RC4 bevorzugt. Und ForwardSecrecy wird man kaum bei allen Browsern erreichen. Eine Note A ist auf jeden Fall sehr gut

 

[Mike0185]

Der Gesamte code wäre dann so richtig?

SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:SHA384:SHA256:AES!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!kEDH:!PSK:!SRP:!kECDH

ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:SHA384:SHA256:AES!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!kEDH:!PSK:!SRP:!kECDH



AESGCM entfällt dann (vor RC4 im ersten Code)?


DANKE!

 

[Joesix]

MailServer

Ich habe mir heute mal den Spass gegönnt und den MailServer unter die Lupe genommen. Für SMTP (Port 25 STARTTLS) und IMAPS sehen die Ergebnisse sehr erfreulich aus:

SMTP:

Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : ECDHE-RSA-AES256-SHA

IMAPS:

Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-GCM-SHA384

 

[jahlives]

mehr Infos zur Konfig von Apache und Nginx --> http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html
@Joesix
die Server sind nicht das Problem, die können fast immer auch die sicheren TLS Versionen. Problematisch sind die Clients z.B. die Browser welche z.T. nur sehr alte Algos unterstützen. Dann kann der Server noch lange per default TLS1.2 anbieten, wenn es der Client nicht kann wird runterverhandelt bis ein Algo kommt, den der Client akzeptiert

 

[Mike0185]

Danke für die Infos!

Ich habe es anhand dessen nochmal probiert und folgende Einträge in den Dateien der DS hinterlegt...
Es scheint aber nicht so von Erfolg gekrönt zu sein...

Die Folge in der Beschreibung habe ich dann so ersetzt: + als - und die Leerzeichen als Doppelpunkt, die Anführungs- und Schlußzeichen entfernt?

So dass das ganze jetzt so aussieht:

/usr/syno/apache/conf/extra/httpd-alt-port-ssl-setting.conf und
/usr/syno/apache/conf/extra/httpd-ssl.conf-common

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite EECDH-ECDSA-AESGCM:EECDH-aRSA-AESGCM:EECDH-ECDSA-SHA256:EECDH-aRSA-RC4:EDH-aRSA:EECDH:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

Danach habe ich den Apache neu gestartet:

/usr/syno/etc/rc.d/S97apache-sys.sh restart
/usr/syno/etc/rc.d/S97apache-user.sh restart

Bekomme ein Ladefehler beim Aufrufen meiner https-Seite.

 

[jahlives]

Stehen denn die Ciphren wirklich auf einer Zeile? Da darf kein Zeilenumbruch sein

 

[Mike0185]

Jap alles eine Zeile...

Kann es sein, weil die DS Apache 2.2 hat und Forward Secrecy erst ab 2.4 geht?


EDIT: Ja... vielleicht sollte man den Browser auch mal schließen und alles neu aufrufen... Es funktioniert auch mit diesen Einstellungen mit grünem Schloss 128 bit und rc4 blabla... SSLlabs-test ergibt allerdings kein FS

 

[jahlives]

gut möglich. Meine auch dass FS erst ab Apache 2.4. geht weil vorher das ECDHE-Verfahren (Ecpliptic Curve Diffie-Hellman-Exchange) beim Apache ned geht. zudem kommt es wirklich sehr auf den Client an. Ich kriege es z.B. um's Verrecken nicht hin, dass alle IE auch FS machen würden. Klar bei XP geht es nicht, aber z.B. kann es der IE7 unter Vista, aber der verd*** IE 11 unter Win 8.1 kann es ned oder auch alle IE (8-10) unter Win7 können es bei mir ned. Scheinbar kochen die Jungs aus Redmond mal wieder ein eigenes Süppchen

 

[Frogman]

So, ich habe jetzt auch mit der aktuellsten DSM-4.3-3810 ein wenig herumgespielt. Das Optimum, was ich da unter Sicherheitsaspekten erreicht habe (d.h. TLS1.2 mit 256bit hochpriorisiert, darunter TLS1.0 und die 128bit-Varianten):

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-DSS-AES256-SHA256:AES256-GCM-SHA384:AES256-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-DSS-AES128-SHA256:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:AES128-GCM-SHA256:AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DES-CBC3-SHA

Damit wird FS weitgehend unterstützt, RC4 ist ausgeschlossen (BEAST ist bei den Browsern jetzt kein Thema mehr). Wer den IE6 unter WinXP unbedingt bedienen will, schließt SSLv3 nicht aus, wer dagegen auf IE8/XP-Unterstützung auch verzichten kann, schmeißt noch den DES-CBC3-SHA (TLS1.0) am Ende heraus.
Ansonsten kann ich jahlives nur zustimmen, Redmond kocht ein eigenes Süppchen (da ist FS einfach nicht da, obwohl die Ciphern verfügbar sind).

 

[raymond]

Habe ich mir auch schon überlegt: jemand schonmal Synology angeschrieben auf Apache 2.4 umzusteigen um ein höheres Sicherheitslevel zu ermöglichen?

 

[Frogman]

yep...

 

[raymond]

Ich gerade auch...hoffentlich fließt das noch in DSM 5.0 ein bzw. hat Synology schon bedacht.

 

[drago]

Wäre gut zu wissen, wo der Code eingepflegt wird.

 

[drago]

Bei mir steht "Protocol Support" auf "0", bin etwas ratlos.

 

[Buntbaer2001]

So. Aufgrund der Heartbleed-Thematik habe ich jetzt auch auf DSM5 mit neuem Zertifikat aktualisiert. Dabei habe ich mir die CyperSuites nochmals näher angesehen.

Mit diesen Einstellungen

SSLCipherSuite SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on

und dem anschließenden Neustart des httpd

httpd -k restart

bekomme ich jetzt mit ALLEN von SSLLabs getesteten Browsern die Forward Secrecy angezeigt. Da ECDSA vom jetzigen 2.2.26 Apache nicht unterstützt wird, kommt immer RSA zum Einsatz.

Wer lieber 256bit AES möchte, muss einfach umreihen:

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA

Und so sieht's dann aus: