RootForum Community

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: 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

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

Apache: Postfix: Dovecot:

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.

daemotron wrote: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.

daemotron wrote: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.

Joe User wrote:Alle Punkte sind in meinen obigen Empehlungen berücksichtigt.

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

Joe User wrote: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.

Joe User wrote: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).

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.

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

Klappt es mit dieser Liste? Falls nicht, kann es sein, dass Du RC4 oder 3DES leider zulassen und aus diesen Listen löschen musst: 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.

[quote="Joe User"]Klappt es mit dieser Liste? 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.

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

Danke für die Rückmeldung.