it-swarm-tr.com

AES'i tamamen devre dışı bırakmadan BEAST'ı hafifletmenin bir yolu var mı?

Kullanıcıları TLS <= 1.0'daki BEAST saldırısına karşı korumanın en kolay yolu RC4'ü tercih etmek veya hatta tüm diğer (CBC) şifre paketlerini tamamen devre dışı bırakmaktır, ör. gibi bir şey belirterek

SSLCipherSuite RC4-SHA:HIGH:!ADH

apache mod_ssl yapılandırmasında.

Ancak, CBC ile ilgili sorun TLS> = 1.1; TLS 1.1 veya 1.2'yi desteklediğini iddia eden müşteriler için bu şifreleri etkinleştirmenin (yeniden) bir yolu var mı? Bir çözüm var gibi görünüyor:

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

sadece TLS> = 1.1'de bulunan şifre paketlerini belirterek hile yapar. Bu, TLS> = 1.1 istemcilerin "eski" şifre paketlerinden herhangi birini kullanmasını engellemenin yan etkisine sahip gibi görünüyor.

Mod_ssl'ye TLS> = 1.1 için CBC mod şifrelerini kullanmasını açıkça söylemenin bir yolu yok, sadece SSL/TLS <= 1.0 için RC4? Bu, güvenlik ve uyumluluğun optimal bir kombinasyonu gibi görünmektedir.

24
lxgr

BEAST'i azaltmanın bir yolu hiçbir şey yapmamaktır . Bu yüzden BEAST'ta kullanılan güvenlik açığı hala mevcut olsa da, sömürmek oldukça zordur. İstekte gönderilen veriler üzerinde yüksek düzeyde denetim ile etki alanları arası istekleri gerçekleştirme yeteneğini gerektirir; özellikle "ikili" verilere ihtiyaç duyar. Duong ve Rizzo, ovadaki saldırıyı eşlemek için bir yol bulamadı <img> tags (saldırgan tarafından seçilen bir yolla bu tür etiketler üreten düşmanca Javascript: yol istekte bulunur, ancak yalnızca metindir). Gösterilerinde, biri WebSockets'in taslak sürümünde, diğeri Java. artık BEAST artık geçerli değil (tarayıcınızı bir yıldan fazla bir süredir güncellemediyseniz, bu durumda muhtemelen daha büyük sorunlarınız var demektir).

Etki alanları arası güvenlik açıklarının bulunmamasına güvenmek, en iyi ihtimalle, dayanıksız olduğu için, tarayıcı satıcıları kayıt bölme ile bazı ek önlemler de içermektedir. Tarayıcı bir SSL kaydına koymak yerine n bayt veri bloğu göndermek istediğinde, bunu ilk önce iki kayıtlara böler çok küçük olmak. Kayıt sınırlarının SSL/TLS'de anlamsal bir önemi yoktur, bu nedenle bu bölmeyi anlamını değiştirmeden yapabilirsiniz. Ancak, her kayıt, kayıt verileri üzerinden hesaplanan bir MAC ile biter ve ve bir sıra numarası ile ve ilk anahtar değişimi. Bu bir şekilde sahte rasgele sayı üreteci gibi davranır. Bu nedenle, küçük kayıt TLS 1.1+ 'ı BEAST'tan bağışıklık kazandıran rastgele IV neslini "taklit eder".

İdeal olarak, bölünme 0/n: veri içermeyen bir kayıt (ama yine de bir MAC ile) ve ardından gerçek verilerle bir kayıt olacaktır. Sıfır uzunluktaki kayıtlara izin verilir ( standart uyarınca) ancak buggy istemci ve sunucu uygulamaları bunları tolere etmez (özellikle IE 6.0); bunun yerine tarayıcılar bir 1/n-1 split, BEAST'ı yenmek için iyi, aynı zamanda neredeyse tüm mevcut SSL/TLS istemcileri ve sunucuları ile de çalışır. En azından Chrome ve Firefox itti geçen yıl .

İyi çözüm TLS 1.1 + , ancak SSL 3.0 ve TLS 1.0'da bile, BEAST sorunu en azından Web bağlamında düzeltilmiş olarak düşünülebilir. Bu nedenle, AES kullanın ve mutlu olun.

15
Thomas Pornin

OpenSSL, 0.9.6d'den beri varsayılan olarak etkinleştirilmiş olan BEAST için azaltma değerine sahiptir, bu nedenle OpenSSL sürümünüz bu sürüm veya sonraki bir sürüm olduğu ve SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS Şifreleri kısıtlamaya veya TLS 1.0'ı devre dışı bırakmaya gerek yok.

10
mgorven

Anladığım kadarıyla, CBC modunda herhangi bir blok şifresiyle TLS <1.1, BEAST'a karşı savunmasızdır. Anladığım kadarıyla, tek seçeneğiniz TLS 1.1 veya daha üstünü kullanmak veya bir akış şifresi kullanmaktır.

Veya tabii ki BEAST, SSH gibi etkilenmeyen farklı bir protokol kullanabilirsiniz :)

0
atk