SSL: Nach Heartbleed nun Poodle

[daemotron]

Wieder mal gibt es eine kritische Lücke, diesmal allerdings im Design des SSLv3-Stack selbst. Ähnlich der BEAST Attacke zielt auch der neue Angriff auf eine Schwäche, die aus der Umsetzung des Cipher Block Chaining Modus in SSLv3 herrührt - kein Programmierfehler also wie bei Heartbleed, sondern eine Design-Schwäche. Dieses Problem trifft damit alle SSL-Implementierungen; nicht nur OpenSSL ist betroffen, sondern auch GnuTLS und LibreSSL, sowie natürlich die diversen browserseitigen Implementierungen.

Da es nicht mit einem einfachen Bugfix getan ist und SSLv3 ein veraltetes, längst durch TLSv1.x überholtes Protokoll ist, besteht der beste verfügbare Fix darin, SSLv3 nicht mehr zu unterstützen. Bei Apache sähe das so aus:

Code: Select all

SSLProtocol All -SSLv2 -SSLv3

Zu bedenken wäre allerdings, dass auch andere Dienste wie Mail- und IMAP-Server entsprechend konfiguriert werden, um nur noch TLS (am besten nur noch in den Versionen 1.1 und 1.2) zu unterstützen.

Hier gibt's einen netten Artikel dazu; enthält auch einige weiterführende Links:
https://community.qualys.com/blogs/secu ... dle-attack

[Joe User]

Empfohlene SSL/TLS Konfigurationen für Apache, Postfix und Dovecot:

Apache:

Code: Select all

SSLCompression Off
SSLHonorCipherOrder On
SSLStrictSNIVHostCheck On
SSLProtocol -ALL +TLSv1 +TLSv1.2
SSLCipherSuite "EECDH+AES256 EECDH+AES128 EDH+AES256 EDH+AES128 !CAMELLIA !RC4 !3DES !IDEA !SEED !PSK !SRP !DSS !eNULL !aNULL !LOW !EXP"

Postfix:

Code: Select all

smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers = CAMELLIA, RC4, 3DES, IDEA, SEED, PSK, SRP, DSS, eNULL, aNULL
smtp_tls_mandatory_ciphers = medium
smtp_tls_mandatory_exclude_ciphers = CAMELLIA, RC4, 3DES, IDEA, SEED, PSK, SRP, DSS, eNULL, aNULL
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = may
smtp_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_tls_ciphers = medium
smtpd_tls_eecdh_grade = strong
smtpd_tls_exclude_ciphers = CAMELLIA, RC4, 3DES, IDEA, SEED, PSK, SRP, DSS, eNULL, aNULL
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_mandatory_exclude_ciphers = CAMELLIA, RC4, 3DES, IDEA, SEED, PSK, SRP, DSS, eNULL, aNULL
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_use_tls = yes
tls_daemon_random_bytes = 64
tls_high_cipherlist = EECDH+AES256 EECDH+AES128 EDH+AES256 EDH+AES128
tls_medium_cipherlist = EECDH+AES256 EECDH+AES128 EDH+AES256 EDH+AES128 EECDH EDH
tls_preempt_cipherlist = yes
tls_random_bytes = 64
tls_ssl_options = NO_COMPRESSION

Dovecot:

Code: Select all

ssl_cipher_list = EECDH+AES256 EECDH+AES128 EDH+AES256 EDH+AES128 !CAMELLIA !RC4 !3DES !IDEA !SEED !PSK !SRP !DSS !eNULL !aNULL !LOW !EXP
ssl_dh_parameters_length = 4096
ssl_parameters_regenerate = 0
ssl_prefer_server_ciphers = yes
ssl_protocols = !SSLv2 !SSLv3

[daemotron]

Ein paar Anmerkungen zur Konfiguration:

• Neben TLSv1.2 sollten derzeit auch TLSv1.1 und TLSv1 nutzbar bleiben - letzteres v. a. für mobile Endgeräte wie Android und iOS
• Bei den Cipher Suites sollte AES im GCM Modus vor anderen Modi bevorzugt werden, um den Schwächen von CBC aus dem Weg zu gehen
• ECDHE und DHE für den Schlüsselaustausch bieten Forward Secrecy und sollten deswegen gegenüber anderen Schlüsselaustauschverfahren (wie etwa RSA) bevorzugt werden. SRP und PSK sollten gar nicht mehr für den Schlüsselaustausch genutzt werden, genauso wie ADH.
• An AES128 vs. AES256 scheiden sich die Geister: AES256 hat zwar die größere Schlüssellänge, ist aber anfällig für einen Timing-Angriff, gegen den AES128 immun ist. AES128 gilt auch weiterhin als nicht gebrochen und berechnet wesentlich schneller als AES256. Das SSLLabs Rating zieht für AES128 Punkte ab (128 Bit Schlüssellänge), in der Praxis ist AES128 aber keine schlechtere Wahl als AES256.

Brauchbare Konfigurationsvorschläge gibt es ansonsten hier:

• Jacob Applebaum (bekannt von seiner Arbeit an TOR) hat ein GitHub-Repository mit Konfigurationsdateien angelegt: https://github.com/ioerror/duraconf - hier würde ich allerdings empfehlen, bei den Cipher Suites alles rauszuwerfen, was noch mit 3DES in Verbindung steht (HIGH).
• Im Mozilla Wiki finden sich gleich drei Konfigurationsvorschläge, je nach Aktualität der eingesetzten Software: https://wiki.mozilla.org/Security/Server_Side_TLS - der Aufbau der Priorisierung ist sehr logisch und dort auch gut erklärt.

[Joe User]

Ein paar Anmerkungen zur Konfiguration:

• Neben TLSv1.2 sollten derzeit auch TLSv1.1 und TLSv1 nutzbar bleiben - letzteres v. a. für mobile Endgeräte wie Android und iOS
• Bei den Cipher Suites sollte AES im GCM Modus vor anderen Modi bevorzugt werden, um den Schwächen von CBC aus dem Weg zu gehen
• ECDHE und DHE für den Schlüsselaustausch bieten Forward Secrecy und sollten deswegen gegenüber anderen Schlüsselaustauschverfahren (wie etwa RSA) bevorzugt werden. SRP und PSK sollten gar nicht mehr für den Schlüsselaustausch genutzt werden, genauso wie ADH.
• An AES128 vs. AES256 scheiden sich die Geister: AES256 hat zwar die größere Schlüssellänge, ist aber anfällig für einen Timing-Angriff, gegen den AES128 immun ist. AES128 gilt auch weiterhin als nicht gebrochen und berechnet wesentlich schneller als AES256. Das SSLLabs Rating zieht für AES128 Punkte ab (128 Bit Schlüssellänge), in der Praxis ist AES128 aber keine schlechtere Wahl als AES256.

Alle Punkte sind in meinen obigen Empehlungen berücksichtigt. Lediglich AES256 ziehe ich AES128 vor, da der Geschwindigkeitsvorteil selbst auf schwacher Hardware keine signifikante Rolle spielt. Die derzeit bekannten Timing-Attacken gegen AES256 sind selbst bei Kryptologen nicht als echte Gefahr angesehen, könnten dies aber in Verbindung mit künftigen weiteren Angriffsvektoren werden. Bis dahin kann AES256 aber relativ bedenkenlos eingesetzt werden.

Brauchbare Konfigurationsvorschläge gibt es ansonsten hier:

• Jacob Applebaum (bekannt von seiner Arbeit an TOR) hat ein GitHub-Repository mit Konfigurationsdateien angelegt: https://github.com/ioerror/duraconf - hier würde ich allerdings empfehlen, bei den Cipher Suites alles rauszuwerfen, was noch mit 3DES in Verbindung steht (HIGH).
• Im Mozilla Wiki finden sich gleich drei Konfigurationsvorschläge, je nach Aktualität der eingesetzten Software: https://wiki.mozilla.org/Security/Server_Side_TLS - der Aufbau der Priorisierung ist sehr logisch und dort auch gut erklärt.

Jacob Applebaum ist unbestritten gut in seinem Fachbereich, aber seine Konfigurationsvorschläge auf Github sind das genaue Gegenteil und alles Andere als empfehlenswert. Bitte nicht verwenden!
Die Empfehlungen aus dem Mozilla Wiki hingegen sind in Ordnung, wobei sich die dortige Ciphersuite-Liste verlustfrei auf meine obige Kurzform zusammenschrumpfen lässt und somit deutlich übersichtlicher wird.

[daemotron]

Alle Punkte sind in meinen obigen Empehlungen berücksichtigt.

War auch mehr als ergänzende Erklärung gedacht, falls hier noch jemand mitliest

Lediglich AES256 ziehe ich AES128 vor, da der Geschwindigkeitsvorteil selbst auf schwacher Hardware keine signifikante Rolle spielt. Die derzeit bekannten Timing-Attacken gegen AES256 sind selbst bei Kryptologen nicht als echte Gefahr angesehen, könnten dies aber in Verbindung mit künftigen weiteren Angriffsvektoren werden. Bis dahin kann AES256 aber relativ bedenkenlos eingesetzt werden.

Full ACK. Was mir bei AES viel mehr Sorgen macht, ist die Tatsache, dass wir in Sachen symmetrischer Algorithmen derzeit eine Monokultur haben - es fehlen Cipher Suites mit akzeptablen Alternativen zu AES (z. B. Serpent, Twofish und MARS). Damit fehlen praxiserprobte Fallback-Lösungen, sollte sich AES eines schönen Tages als brechbar erweisen.

Noch lustiger sieht es bei den HMACs aus - etliche Cipher Suites rutschen noch mit SHA(1) durch die Gegend. So langsam aber sicher gehört das IMO zusammen mit RC4 und 3DES auf den Müllhaufen der Krypto-Geschichte.

Jacob Applebaum ist unbestritten gut in seinem Fachbereich, aber seine Konfigurationsvorschläge auf Github sind das genaue Gegenteil und alles Andere als empfehlenswert. Bitte nicht verwenden!

Seine Wahl der Cipher Suites ist zweifelhaft, das sagte ich ja schon. Die übrigen Aspekte seiner Konfiguration decken sich aber sowohl mit den Empfehlungen von Mozilla, als auch mit denen von Ivan Ristic (PDF).

[jan10001]

tls_high_cipherlist = EECDH+AES256 EECDH+AES128 EDH+AES256 EDH+AES128
tls_medium_cipherlist = EECDH+AES256 EECDH+AES128 EDH+AES256 EDH+AES128 EECDH EDH

Die müsste man erweitern, denn Outlook hat Probleme damit oder kennt sie nicht.

[jan10001]

Damit gibt es keine Probleme, scheint das RSA bei Outlook Pflicht ist.

Code: Select all

ECDH+aRSA+AES256:ECDH+aRSA+AES128:AES256-SHA:DES-CBC3-SHA

[Joe User]

Klappt es mit dieser Liste?

Code: Select all

tls_high_cipherlist = EECDH+AESGCM EECDH+SHA384 EECDH+SHA256 EECDH+SHA EDH+AESGCM EDH+SHA384 EDH+SHA256 EDH+SHA
tls_medium_cipherlist = EECDH+AESGCM EECDH+SHA384 EECDH+SHA256 EECDH+SHA EDH+AESGCM EDH+SHA384 EDH+SHA256 EDH+SHA SHA384 SHA256 SHA

Falls nicht, kann es sein, dass Du RC4 oder 3DES leider zulassen und aus diesen Listen löschen musst:

Code: Select all

smtp_tls_exclude_ciphers = CAMELLIA, RC4, 3DES, IDEA, SEED, PSK, SRP, DSS, eNULL, aNULL
smtp_tls_mandatory_exclude_ciphers = CAMELLIA, RC4, 3DES, IDEA, SEED, PSK, SRP, DSS, eNULL, aNULL
smtpd_tls_exclude_ciphers = CAMELLIA, RC4, 3DES, IDEA, SEED, PSK, SRP, DSS, eNULL, aNULL
smtpd_tls_mandatory_exclude_ciphers = CAMELLIA, RC4, 3DES, IDEA, SEED, PSK, SRP, DSS, eNULL, aNULL

Dovecot muss in beiden Fällen jeweils analog angepasst werden.


EDIT: aRSA ist anonymous RSA, also RSA ohne authentication Keys und sollte tunlichst vermieden werden. Da kann man auch gleich auf SSL/TLS verzichten.

[jan10001]

[quote="Joe User"]Klappt es mit dieser Liste?

Code: Select all

tls_medium_cipherlist = EECDH+AESGCM EECDH+SHA384 EECDH+SHA256 EECDH+SHA EDH+AESGCM EDH+SHA384 EDH+SHA256 EDH+SHA SHA384 SHA256 SHA

Mit der Medium Liste gehts, zumindest Outlook 2013 macht mit. Mal schaun ob auch Outlook 2007 geht, ich werde es Montags hören. Laut Log verwendet Outlook 2013 SHA256 und SHA.

[jan10001]

Kann es nun bestätigen mit Outlook 2007 läuft es auch.

[Joe User]

Danke für die Rückmeldung.