it-swarm-eu.dev

Gibt es eine Möglichkeit, BEAST zu entschärfen, ohne AES vollständig zu deaktivieren?

Es scheint, dass der einfachste Weg, Benutzer vor dem BEAST-Angriff auf TLS <= 1.0 zu schützen, darin besteht, RC4 zu bevorzugen oder sogar alle anderen (CBC) Cipher Suites insgesamt zu deaktivieren, z. durch Angabe von etwas wie

SSLCipherSuite RC4-SHA:HIGH:!ADH

in der Apache mod_ssl Konfiguration.

Das Problem mit CBC scheint jedoch in TLS> = 1.1 behoben worden zu sein. Gibt es eine Möglichkeit, diese Chiffren für Clients (erneut) zu aktivieren, die behaupten, TLS 1.1 oder 1.2 zu unterstützen? Es scheint eine Problemumgehung zu geben:

SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

dies führt den Trick aus, indem Cipher Suites angegeben werden, die nur in TLS> = 1.1 verfügbar sind. Dies scheint den Nebeneffekt zu haben, dass TLS> = 1.1-Clients daran gehindert werden, eine der "älteren" Cipher Suites zu verwenden.

Gibt es wirklich keine Möglichkeit, mod_ssl explizit anzuweisen, CBC-Modus-Chiffren für TLS> = 1.1 zu verwenden, sondern nur RC4 für SSL/TLS <= 1.0? Dies scheint eine optimale Kombination aus Sicherheit und Kompatibilität zu sein.

24
lxgr

Eine Möglichkeit, BEAST zu mildern, besteht darin, nichts zu tun . Es kommt vor, dass die in BEAST verwendete Sicherheitsanfälligkeit zwar immer noch vorhanden ist, es jedoch ziemlich schwierig ist, sie auszunutzen. Es erfordert die Fähigkeit, domänenübergreifende Anforderungen mit einem hohen Maß an Kontrolle über die in der Anforderung gesendeten Daten auszuführen. Insbesondere benötigt es "binäre" Daten. Duong und Rizzo haben keine Möglichkeit gefunden, den Angriff auf einfache <img> - Tags abzubilden (feindliches Javascript, das solche Tags mit einem vom Angreifer ausgewählten Pfad erzeugt: Der Pfad wird in die Anforderung aufgenommen, ist jedoch nur Text). . In ihrer Demonstration konnten sie zwei domänenübergreifende Lücken verwenden, eine in einer Entwurfsversion von WebSockets, die andere in der Implementierung von Java von Oracle. Beide Lücken wurden seitdem behoben, daher richtig Jetzt gilt BEAST nicht mehr (es sei denn, Sie haben Ihren Browser länger als ein Jahr nicht aktualisiert. In diesem Fall haben Sie wahrscheinlich größere Probleme).

Da es bestenfalls schwierig ist, sich auf das Nichtvorhandensein domänenübergreifender Sicherheitslücken zu verlassen, haben Browser-Anbieter auch einige zusätzliche Gegenmaßnahmen mit Datensatzaufteilung aufgenommen. Wenn der Browser einen Block von n Datenbytes senden möchte, teilt er ihn nicht in einen SSL-Datensatz, sondern in zwei Datensätze auf, den ersten sehr klein sein. Datensatzgrenzen haben in SSL/TLS keine semantische Bedeutung, sodass Sie eine solche Aufteilung durchführen können, ohne die Bedeutung zu ändern. Jeder Datensatz endet jedoch mit einem MAC , der über die Datensatzdaten berechnet wird und einer Sequenznummer Und unter Verwendung eines von abgeleiteten Schlüssels der anfängliche Schlüsselaustausch. Dies wirkt irgendwie als Pseudozufallszahlengenerator. Daher "emuliert" der kleine Datensatz die zufällige IV-Generation, die TLS 1.1+ immun gegen BEAST macht.

Im Idealfall wäre die Aufteilung 0/n: ein Datensatz ohne Daten (aber immer noch mit einem MAC), gefolgt von einem Datensatz mit den tatsächlichen Daten. Datensätze mit der Länge Null sind zulässig (gemäß Standard ), aber fehlerhafte Client- und Server-Implementierungen tolerieren sie nicht (insbesondere IE 6.0); stattdessen verwenden Browser a 1/n-1 Split, was genauso gut ist, um BEAST zu besiegen, aber auch mit fast allen vorhandenen SSL/TLS-Clients und -Servern funktioniert. Zumindest Chrome und Firefox haben es gepusht letztes Jahr .

Die gute Lösung ist TLS 1.1 + , aber selbst unter SSL 3.0 und TLS 1.0 kann das BEAST-Problem zumindest im Webkontext als behoben angesehen werden. Verwenden Sie daher AES und seien Sie glücklich.

15
Thomas Pornin

OpenSSL hat ein Minderung für BEAST , das seit 0.9.6d standardmäßig aktiviert ist, solange Ihre OpenSSL-Version diese Version oder höher ist und Sie nicht SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS Festgelegt haben Sie müssen keine Chiffren einschränken oder TLS 1.0 deaktivieren.

10
mgorven

Mein Verständnis ist, dass TLS <1.1 mit jeder Blockverschlüsselung im CBC-Modus für BEAST anfällig ist. Nach meinem Verständnis besteht Ihre einzige Möglichkeit darin, TLS 1.1 oder höher oder eine Stream-Verschlüsselung zu verwenden.

Oder Sie könnten natürlich ein anderes Protokoll verwenden, das von BEAST nicht betroffen ist, wie SSH :)

0
atk