Liebe Kolleginnen und Kollegen,
Anfang 2020 werden die führenden Browserhersteller die Unterstützung von TLS 1.0 und TLS 1.1 deaktivieren. Aus diesem Anlass hat der Arbeitskreis Informationssicherheit der deutschen Forschungseinrichtungen (AKIF) eine Empfehlung erstellt.
Kern der Empfehlung ist es, nur noch Verschlüsselungen mit TLS 1.2 auf den Servern der RWTH zuzulassen und TLS 1.0 und TLS 1.1 zu deaktivieren.
Der Empfehlung möchten wir uns anschliessen. Sie ist dieser E-Mail angehängt.
Mit freundlichen Grüßen,
Guido Bunsen, Jens Hektor, Bernd Kohler
PS. Die Webseite https://cipherli.st/ enthält Hinweise zur Umsetzung der Empfehlungen
PS. Die Webseite https://cipherli.st/ enthält Hinweise zur Umsetzung der Empfehlungen
Was ich an dieser Webseite schon immer merkwürdig fand: Sie empfiehlt für NGINX >=1.13.0 das Aktivieren von nur TLSv1.3 - das ist eine sehr schlechte Idee, wenn man sich die Geräte-Unterstützung anschaut[1]. Für Apache empfiehlt sie, 1.2 und 1.3 zu aktivieren (bzw alle anderen zu deaktivieren), das ist die viel bessere Variante, für NGINX sollte man also neben 1.3 auch 1.2 aktivieren.
Das AKIF-Dokument empfiehlt für die praktische Umsetzung die Website bettercrypto.org (auf Seite 2 am Ende), die aber auch als Best Practices für Apache+NGINX (und weitere, zB Dovecot, Postfix, ...) TLS 1.0 und 1.1 aktiviert lässt, und für NGINX 1.3 nicht aktiviert. Das wirkt daher wie eine veraltete Empfehlung (die eben sogar der AKIF-Empfehlung widerspricht), cipherli.st erscheint hier sinnvoller (mit obiger Notiz). Warum die Autoren der (ansonsten technisch fundierten) Empfehlung dies nicht entsprechend benannt haben verstehe ich nicht?
Hallo Rene.
Thx für deine Ergänzung.
Am 25.04.19 um 15:03 schrieb Rene Pasing:
... Das AKIF-Dokument empfiehlt für die praktische Umsetzung die Website bettercrypto.org (auf Seite 2 am Ende), die aber auch als Best Practices für Apache+NGINX (und weitere, zB Dovecot, Postfix, ...) TLS 1.0 und 1.1 aktiviert lässt, und für NGINX 1.3 nicht aktiviert. ...
Genau das ist mir auf [0] auch aufgefallen, daher der Hinweis in der initialen E-Mail. Du hast zudem natürlich recht, dass es noch weitere Dienste gibt, bei denen TLS modern implementiert werden sollte ;)
Das mit der Aktualität wurde übrigens bereits auf der passenden Mailingliste [1] diskutiert: "it is at least extremely passive"
VG
Bernd
[0] https://bettercrypto.org/#_apache
[1] https://lists.cert.at/pipermail/ach/2018-October/002311.html
Das wirkt daher wie eine veraltete Empfehlung (die eben sogar der AKIF-Empfehlung widerspricht), cipherli.st erscheint hier sinnvoller (mit obiger Notiz). Warum die Autoren der (ansonsten technisch fundierten) Empfehlung dies nicht entsprechend benannt haben verstehe ich nicht?
[1] = https://caniuse.com/#feat=tls1-3 _______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
Das Dokument empfiehlt die Deaktivierung von SHA1 in TLS 1.2 und verweist dabei auf [1]. Dort ist zu lesen, dass es dabei um signature_algorithms geht, welches von Clients gesetzt wird. RFC5246 schreibt zudem:
If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension.
Man hat als Serverbetreiber also nicht die Möglichkeit das zu deaktivieren.
Gruß Damian
[1] https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-00
Am 25.04.19 um 14:22 schrieb Guido Bunsen:
Liebe Kolleginnen und Kollegen,
Anfang 2020 werden die führenden Browserhersteller die Unterstützung von TLS 1.0 und TLS 1.1 deaktivieren. Aus diesem Anlass hat der Arbeitskreis Informationssicherheit der deutschen Forschungseinrichtungen (AKIF) eine Empfehlung erstellt.
Kern der Empfehlung ist es, nur noch Verschlüsselungen mit TLS 1.2 auf den Servern der RWTH zuzulassen und TLS 1.0 und TLS 1.1 zu deaktivieren.
Der Empfehlung möchten wir uns anschliessen. Sie ist dieser E-Mail angehängt.
Mit freundlichen Grüßen,
Guido Bunsen, Jens Hektor, Bernd Kohler
PS. Die Webseite https://cipherli.st/ enthält Hinweise zur Umsetzung der Empfehlungen
rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
Ich habe mich geirrt. Es gilt zwar:
foo@bar:~ openssl s_server -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 | grep -i SHA Shared ciphers:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES256-GCM-SHA384 Signature Algorithms: RSA+SHA1 Shared Signature Algorithms: RSA+SHA1 Shared Elliptic groups: X25519:P-256:X448:P-521:P-384 CIPHER is ECDHE-RSA-AES256-GCM-SHA384
foo@bar:~ openssl s_client -connect 127.0.0.1:4433 -sigalgs RSA+SHA1 2>/dev/null | grep SHA Peer signing digest: SHA1 New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Cipher : ECDHE-RSA-AES256-GCM-SHA384
aber es gibt in OpenSSL diverse Security Level:
foo@bar:~ openssl s_server -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384@SECLEVEL=2 | grep -i SHA ERROR 139855415625536:error:1414F178:SSL routines:tls1_set_server_sigalgs:no shared signature algorithms:../ssl/t1_lib.c:1260:
foo@bar:~ openssl s_client -connect 127.0.0.1:4433 -sigalgs RSA+SHA1 CONNECTED(00000003) 140381272287040:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1536:SSL alert number 40
In Debian ist Security Level 2 derzeit Systemdefault.
Allerdings ist die Empfehlung aus [1] nicht mehr in der derzeit aktuellen Fassung 03 vorhanden:
"Removed SHA-1 deprecation (section 8 of -00)" [2]
[1] https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-00 [2] https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-03
Am 25.04.19 um 18:01 schrieb Damian Lukowski:
Das Dokument empfiehlt die Deaktivierung von SHA1 in TLS 1.2 und verweist dabei auf [1]. Dort ist zu lesen, dass es dabei um signature_algorithms geht, welches von Clients gesetzt wird. RFC5246 schreibt zudem:
If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension.
Man hat als Serverbetreiber also nicht die Möglichkeit das zu deaktivieren.
[1] https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-00
Hallo zusammen,
das BSI hat hierzu folgende Meinung [0]:
- TLS 1.3 oder TLS 1.2 - kein Erwähnung (Empfehlung?!?) von eTLS (siehe [1]) - Perfect Forward Secrecy (PFS)
Gefunden via [2].
Hier der Vollständigkeit halber FYI
VG
Bernd
[0] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Mindeststandards/Mindest...
[1] https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.02.01_60/ts_1...
rwth-security@lists.rwth-aachen.de
-
Bernd Kohler -
Damian Lukowski -
Guido Bunsen -
Rene Pasing