SSLv3 POODLE açığı (CVE-2014-3566) nasıl yama / geçici çözüm yapabilirim?

158

BEAST saldırısından sonra ve Heartbleed bug , artık SSL / TLS'de yeni bir güvenlik açığı duydum: POODLE . Kendimi sömürüye karşı nasıl koruyabilirim?

  • Yalnızca sunucular mı yoksa müşteriler de etkilendi mi?
  • Bu OpenSSL / GnuTLS özel midir?
  • Ne tür hizmetler etkilenir? Sadece HTTPS veya IMAPS, SMTPS, OpenVPN, vb.?

Lütfen bu güvenlik açığından nasıl korunacağınıza dair örnekler göster.

    
sordu gertvdijk 15.10.2014 01:49

4 cevap

210

Arka plan bilgisi

SSL, ulaşım seviyesini internette güvenceye almak için tasarlanmıştır. 'HTTP' aka HTTP için bunu HTTPS olarak bileceksiniz, ancak diğer uygulama protokolleri için de kullanılır. SSLv2, yaygın olarak kullanılan ilk taşıma güvenlik protokolü idi ancak uzun bir süre sonra güvensiz bulundu. SSLv3 ve TLSv1 başarıları artık geniş çapta destekleniyor. TLSv1.1 ve TLSv1.2 daha yenidir ve çok fazla destek almaktadır. Çoğu, 2014'ten piyasaya sürülen tüm web tarayıcıları desteklemiyorsa.

Google mühendislerinin son keşfi, SSLv3'ün artık kullanılmaması gerektiğine işaret ediyor (SSLv2 uzun bir süre önce kullanımdan kaldırıldı). Sitenize / hizmetinize bağlanamayan istemciler muhtemelen çok sınırlıdır. Google CloudFlare, ziyaretçilerinin% 0,09'undan daha azının hala güvendiğini bildirdi. SSLv3.

Basit çözüm: SSLv3'ü devre dışı bırakın.

Ubuntu herhangi bir güncelleme sağlıyor mu?

Evet, SCSV özelliğinin eklenmesiyle usn-2385-1 aracılığıyla Ancak, SSLv3'ü devre dışı bırakmadığından ve yalnızca bağlantının her iki tarafı da yamalanmışsa, yama çalışacağından sorunu tamamen azaltmaz . Bunu, paket yöneticinizdeki normal güvenlik güncellemelerinizden alırsınız.

Yani, hala YOU 'un SSLv3'ü devre dışı bırakmak için harekete geçmesi gerekiyor (yapılandırılabilir). İstemcilerin / tarayıcıların gelecek sürümleri, SSLv3'ü büyük olasılıkla devre dışı bırakacaktır. Örneğin. Firefox 34 bunu yapacak.

Uygulama düzeyinde Ubuntu’da SSLv3’ü varsayılan olarak tamamen devre dışı bırakmak muhtemelen HTTPS olmayan SSL kullanımı için o kadar çok güvenlik açığından etkilenmeyen bazı kullanımları da kırmayacaktır. Bu nedenle, bakım yapanların bunu yapmayacağını ve yalnızca bu SCSV yamasının uygulanan.

Usn-2385-1 aracılığıyla OpenSSL'de SCSV güncellemesi neden sorunu azaltmıyor?

Gerçekten, bu tür sorular sormayı bırakın ve sadece birkaç paragrafı atlayın ve SSLv3'ü devre dışı bırakın. Ama hey, ikna olmuyorsan, işte gidiyorsun:

POODLE, CBC şifrelerine sahip SSLv3'ün bozulduğunu, SCSV uygulamasının bunu değiştirmediğini gösterir. SCSV, sadece bazı TLS protokolünden, her zamanki durumlar için gerekli olan Man-in-the-Middle saldırısı ile gerektiğinde daha düşük TLS / SSL protokolüne geçmediğinizden emin olmanızı sağlar.

TLS'yi sunmayan bir sunucuya erişmeniz gerekiyorsa, ancak sadece SSLv3 ise, tarayıcınızın gerçekten bir seçeneği yok ve SSLv3 kullanarak sunucuyla konuşması gerekiyor. Bu da herhangi bir indirme saldırısı olmadan savunmasız durumdadır. .

TLSv1 + ve SSLv3'ü de sunan bir sunucuya erişmeniz gerekiyorsa (bu da önerilmez) ve bağlantınızın bir saldırgan tarafından SSLv3'e indirilmediğinden emin olmak istiyorsanız, her ikisi de sunucu ve müşterinin bu SCSV yamasına ihtiyacı var.

Konuyu tamamen azaltmak için SSLv3'ün devre dışı kalması yeterlidir ve indirilmeyeceğinizden emin olabilirsiniz. Ve SSLv3 sadece sunucularla konuşamayacaksınız.

Tamam, SSLv3'ü nasıl devre dışı bırakırım?

Uygulamaya özel bölümlerde aşağıya bakın: Firefox, Chrome, Apache, Nginx ve Postfix şimdilik kapsanmıştır.

Yalnızca sunucular mı yoksa müşteriler de etkileniyor mu?

Güvenlik açığı, hem sunucu hem de istemci SSLv3'ü kabul ederse (her ikisi de bir indirme saldırısı nedeniyle TLSv1 / TLSv1.1 / TLS1.2 yeteneğine sahip olsa bile) bulunur.

Bir sunucu yöneticisi olarak, kullanıcılarınızın güvenliği için SSLv3'ü şimdi devre dışı bırakmanız gerekir .

Bir kullanıcı olarak, SSLv3'ü destekleyen web sitelerini ziyaret ederken kendinizi güvenceye almak için tarayıcınızda SSLv3'ü devre dışı bırakmanız gerekir şimdi .

Bu OpenSSL / GnuTLS / tarayıcıya özel mi?

Hayır. Bir protokol (tasarım) hatası, bir uygulama hatası değil. Bu, onu gerçekten eskizlendiremezsiniz (eski SSLv3'ün tasarımını değiştirmediğiniz sürece).

Ve evet, yeni bir OpenSSL güvenlik sürümü var, ancak aşağıda okuyoruz ( Ama ben gerçekten gerçekten SSLv3'ü tamamen reddetmeye daha iyi odaklanmanız için neden X, Y, Z için ) SSLv3 desteğine ihtiyacınız var.

SSLv3'ü ağ (güvenlik duvarı) düzeyinde mi öldürebilirim?

Evet, muhtemelen. Bunu daha fazla düşünce ve çalışma için ayrı bir blogda yazdım. Kullanabileceğiniz bazı iptables kuralı olabilir!

Blog yayınım: Ağınızda SSLv3'ü POODLE için iptables kullanarak nasıl kullanabilirsiniz?

Yalnızca HTTPS veya IMAP / SMTP / OpenVPN ve SSL desteği olan diğer protokoller için uygun mu?

Araştırmacılar tarafından gösterildiği gibi mevcut saldırı vektörü, kurbanın makinesinde çalıştırılan Javascript'i kullanarak sunucuya gönderilen düz metnin kontrol edilmesiyle çalışır. Bu vektör, tarayıcı kullanmadan HTTPS dışı senaryolara uygulanmaz.

Ayrıca, normalde bir SSL istemcisi oturumun SSLv3'e (el sıkışma yeteneklerinde görülen TLSv1 + sahip olmasına) indirgenmesine izin vermez, ancak tarayıcılar çok geriye dönük olarak uyumlu olurlar ve yaparlar. Plaintext'i ve bir HTTP üstbilgisinin oluşturulma biçimini kontrol eden birleşim, onu istismar etmeyi sağlar.

Sonuç: HTTPS için şimdi SSLv3'ü devre dışı bırakın, sonraki hizmet pencerenizdeki diğer hizmetler için SSLv3'ü devre dışı bırakın.

Etki nedir? Sunucu sertifikamı iptal etmem ve yenilemem gerekiyor mu? (Heartbleed'de olduğu gibi)

Hayır, sertifikalarınızı bunun için döndürmeniz gerekmez. Güvenlik açığı, düz metin kurtarmasını oturum verilerinden gösterir, herhangi bir sırra erişim sağlamamaktadır (oturum anahtarı veya sertifika anahtarı).

Saldırganın büyük olasılıkla, yalnızca oturum kaçırma gerçekleştirmek için oturum çerezleri gibi düz metin başlıkları çalabilmesi yeterlidir. Ek bir kısıtlama, tam (etkin) bir MitM saldırısı gerekliliğidir.

SSL yapılandırmamı genel olarak geliştirmek için yapabileceğim başka bir şey var mı?

Bir kullanıcı olarak, tarayıcınızda SSLv3'ü devre dışı bırakmanın yanı sıra, gerçekten de değil. Eh, her zaman en son güvenlik güncellemelerini yükleyin.

Sunucular için Mozilla'nın TLS sunucu kılavuzunu izleyin. Ve Qualys 'SSL Labs testiyle test edin. Sitenizde A + derecelendirmesini almak gerçekten zor değil. Sadece paketlerinizi güncelleyin ve önerileri Mozilla kılavuzundan uygulayın.

Ama gerçekten gerçekten SSLv3 desteğine ihtiyacım var ... neden X, Y, Z için! Şimdi ne?

Peki, SSLv3 Yedekleme Koruması adı verilen TLSv1 yetenekli istemcilerin downgrade saldırısını engelleyen bir yama var. Bu arada TLSv1 + 'nin güvenliğini de artıracaktır (indirme aşaması daha zor / imkansızdır). Ubuntu Güvenlik danışmanı usn-2385-1 'de daha yeni bir OpenSSL sürümünden bir backport olarak sunulur .

Büyük yakalama: Çalışmak için hem istemcilerin hem de sunucuların bu düzeltme eki gerekir. Bu nedenle, hem müşterilerimizi hem de sunucularınızı güncellerken bence, sadece TLSv1 + sürümüne geçmelisiniz.

Ancak lütfen, lütfen, ağınızdaki SSLv3'ü şimdilik kaldırın. Güvenlik standartlarını yükseltmek için çaba harcayın ve sadece SSLv3'ü boşaltın.

Protokol indirgeme saldırısını ortadan kaldırmak için SCSV desteğini duydum. İhtiyacım var mı?

Sadece tek bir sebepten dolayı SSLv3'e gerçekten ihtiyacınız varsa, ancak TLSv1 + 'da da güvenliği artırırsa, evet, yüklemenizi öneririm. Ubuntu, bu özellik için usn-2385-1 adresinde bir güncelleme sağlar. Bunu, paket yöneticinizdeki normal güvenlik güncellemelerinizden alırsınız.

Özel olarak barındırılan siteler için güvenlik açığı test etme (ör. intranet / çevrimdışı).

Sunucularınız SSLv3'ü destekliyorsa kolayca savunmasızdır. Burada birkaç seçenek:

  • OpenSSL s_client ile:

    openssl s_client -connect <server>:<port> -ssl3
    

    Bağlantı başarılı olursa, sslv3 etkinleştirildi. Başarısız olursa, devre dışı bırakılır. Başarısız olduğunda, aşağıdaki gibi bir şey görmelisiniz:

    error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
    
  • nmap değerini kullanma:

    nmap --script ssl-enum-ciphers -p 443 myhostname.tld
    

    ' SSLv3: No supported ciphers found ' çıktı olmalıdır. Ana makine adınız / bağlantı noktanız için ayarlayın.

  • cipherscan 'ı kullanma. İkiliyi klonlayın / indirin ve çalıştırın:

    ./cipherscan myhostname.tld
    

    'Protokoller' sütununun altında SSLv3 ile bir şey listelememelidir .

Firefox tarayıcısı

about:config dosyasını açın, security.tls.version.min değerini bulun ve değeri 1 olarak ayarlayın. Ardından, açık SSL bağlantılarını bırakmak için tarayıcınızı yeniden başlatın.

34 sürümünden itibaren Firefox, SSLv3'ü varsayılan olarak devre dışı bırakacak ve dolayısıyla herhangi bir işlem yapılmasını gerektirmeyecektir ( kaynak ). Ancak, yazı yazıldığı anda, 33 serbest bırakıldı ve 25 Kasım için 34 ayarlandı.

Google Chrome (Linux)

/usr/share/applications/google-chrome.desktop dosyasını düzenleyin, ör.

sudo nano /usr/share/applications/google-chrome.desktop

Exec= öğesini dahil etmek için --ssl-version-min=tls1 ile başlayan tüm satırları düzenleyin.

Örn.

gibi bir satır
Exec=/usr/bin/google-chrome-stable %U

olur

Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U

Ardından, tarayıcıyı tamamen kapattığınızdan emin olun (Chrome uygulamaları tarayıcınızı arka planda etkin durumda tutuyor olabilir!).

Not: Bu her google-chrome paket güncellemesini, .desktop başlatıcısı dosyasının üzerine yazarak tekrar etmeniz gerekebilir. SSLv3 varsayılan olarak devre dışı bırakılmış bir Google Chrome veya Chromium tarayıcısı, yazma sırasında henüz açıklanmadı.

Apache HTTPD Sunucusu

Şu anda SSLv3'e izin veren bir Apache web sunucusu çalıştırıyorsanız, Apache yapılandırmasını düzenlemeniz gerekecektir. Debian ve Ubuntu sistemlerinde dosya /etc/apache2/mods-available/ssl.conf . CentOS ve Fedora'da dosya /etc/httpd/conf.d/ssl.conf .Aşağıdaki satırı Apache yapılandırmanıza diğer SSL yönergelerine eklemeniz gerekir.

SSLProtocol All -SSLv2 -SSLv3

Bu, SSLv2 ve SSLv3 dışındaki tüm protokollere izin verecektir.

Bu sırada, Mozilla'nın TLS sunucusunda açıklandığı şekilde web sunucunuzun şifreleme yapılandırmasını iyileştirmeyi düşünebilirsiniz. yol gösterir. Örneğin ekle:

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on
SSLCompression          off
# Read up on HSTS before you enable it (recommended)
# Header add Strict-Transport-Security "max-age=15768000"

Sonra yeni yapılandırmanın doğru olup olmadığını kontrol edin (yazım hatası vb.):

sudo apache2ctl configtest

ve sunucuyu yeniden başlatın, ör.

sudo service apache2 restart

CentOS ve Fedora'da:

systemctl restart httpd

Daha fazla bilgi: Apache belgeleri

Şimdi test edin: Siteniz herkese açıksa, Qualys’ın SSL Labs aracını kullanarak test edin.

Nginx sunucusu

Nginx çalıştırıyorsanız, diğer SSL yönergelerinde yapılandırmanıza aşağıdaki satırı eklemeniz yeterlidir:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Bu sırada, Mozilla'nın TLS sunucusunda açıklandığı şekilde web sunucunuzun şifreleme yapılandırmasını iyileştirmeyi düşünebilirsiniz. yol gösterir. Örneğin ekle:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
# Read up on HSTS before you enable it (recommended)
# add_header Strict-Transport-Security max-age=15768000;

ve sunucuyu yeniden başlatın, ör.

sudo service nginx restart

Referans: Nginx belgeleri

Şimdi test edin: Siteniz herkese açık, uygunsa Qualys 'SSL Labs aracını kullanarak test edin.

Lighttpd web sunucusu

Lighttpd sürümleri & gt; 1.4.28, SSLv2 ve v3'ü devre dışı bırakmak için bir yapılandırma seçeneğini destekler. 1.4.28'den önceki Lighttpd sürümleri SADECE SSLv2'yi devre dışı bırakmanıza izin verir. Ubuntu 12.04 LTS ve önceki sürümlerinin en iyi lighttpd v1.4.28 sürümüne yüklendiğini ve bu nedenle bu dağıtımlar için basit bir düzeltme yapılmadığını lütfen unutmayın. Bu nedenle, bu düzeltme yalnızca 12.04'ten büyük Ubuntu sürümleri için kullanılmalıdır.

Ubuntu sürüm 12.04 veya Debian 6 için, güncellenmiş bir lighttpd paketi openSUSE deposundan edinilebilir: İşte

Paket, Debian 6 (sıkıştırma) için tasarlanmıştır ancak 12.04 (hassas) da çalışır

/etc/lighttpd/lighttpd.conf direktifinden sonra aşağıdaki satırları eklemek için ssl.engine = "enable" 'nizi düzenleyin

ssl.use-sslv2          = "disable"
ssl.use-sslv3          = "disable"

Ardından, lighttpd hizmetini sudo service lighttpd restart ile yeniden başlatmalı ve değişikliğin başarıyla uygulandığından emin olmak için önceki bölümlerde açıklandığı gibi bir ssl3 el sıkışma testi gerçekleştirmelisiniz.

İşte 'den alınmıştır.

Postfix SMTP

'Fırsatçı SSL' için (şifreleme politikası uygulanmadı ve düz kabul edilemez), hiçbir şeyi değiştirmenize gerek yoktur. SSLv2 bile düzden daha iyidir, bu yüzden sunucunuzu güvenceye almanız gerekiyorsa, 'zorunlu SSL' modunu kullanmalısınız.

Zaten yapılandırılmış olan 'zorunlu SSL' modu için, gelen için smtpd_tls_mandatory_protocols ayarını eklemeniz / değiştirmeniz yeterlidir. bağlantılar ve smtp_tls_mandatory_protocols giden bağlantılar için:

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3

İsteğe bağlı olarak, SSLv3'ü fırsatçı şifreleme için de devre dışı bırakmak istiyorsanız (yukarıda açıklandığı gibi olmasa da), bunu yapın:

smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

ve Postfix'i yeniden başlat:

sudo service postfix restart

Sendmail

(Anonim kullanıcı tarafından doğrulanmamış düzenleme, Sendmail ile rahat değilim, lütfen doğrulayın.)

Bu seçenekler, LOCAL_CONFIG

dosyanızın sendmail.mc bölümünde yapılandırıldı
LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

Dovecot

Dovecot v2.1 + 'da, aşağıdakileri /etc/dovecot/local.conf ' ye (veya /etc/dovecot/conf.d 'deki yeni bir dosyaya) ekleyin:

ssl_protocols = !SSLv2 !SSLv3

ve Dovecot'u yeniden başlat:

sudo service dovecot restart

Daha eski sürümler için kaynak kodunu yamaları gerekir.

Kurye-imap (imapd-ssl)

Kurye-imap, Ubuntu 12.04 ve diğerlerinde varsayılan olarak SSLv3'e izin verir. Devre dışı bırakmalı ve TLS'yi zorlamak için STARTTLS kullanmalısınız. Aşağıdaki değişiklikleri yansıtacak şekilde /etc/courier/imapd-ssl yapılandırma dosyanızı düzenleyin

IMAPDSSLSTART=NO
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="<take those from the Mozilla TLS Server guide!>"

HAProxy Server

SSL, HAProxy = 1.5 sürümünde destekleniyor.

/etc/haproxy.cfg dosyasını düzenleyin ve bind satırınızı bulun. % Co_de% değerini ekleyin. Örneğin:

bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3

Referans: HAProxy Documentation

OpenVPN

Etkilenmemiş gibi görünüyor ( kaynak ).

  

OpenVPN, TLSv1.0 veya isteğe bağlı olarak TLSv1.2'yi (& gt; = 2.3.3) kullanır ve bu nedenle POODLE tarafından etkilenmez.

Kukla

Kukla HTTPS üzerinden SSL kullanıyor, ancak 'tarayıcı' istemcileri tarafından kullanılmıyor, sadece gösterilen saldırı vektörüne karşı savunmasız olan Puppet ajanları.Ancak, SSLv3'ü devre dışı bırakmak en iyi yöntemdir.

Tavsiyem, stephenrjohnson / puppetmodule Kukla modülünü kullanmaktır. "https://github.com/stephenrjohnson/puppetmodule/commit/1adb73f9a400cb5e91c4ece1c6166fd63004f448"> Bir süre önce SSLv3'ü öldürdüm .

    
verilen cevap gertvdijk 15.10.2014 01:49
4

Ubuntu'ya özgü olmamakla birlikte, Node.js'deki Poodle vulnerablity etrafında çalışmak için https veya tls sunucusu oluştururken secureOptions 'si require('constants').SSL_OP_NO_SSLv3 ' ye ayarlayabilirsiniz.

Ek bilgi için İşte konusuna bakın.

    
verilen cevap 3rdEden 15.10.2014 10:59
0

Kurye için "düzeltme" tls 1.1 ve tls 1.2 devre dışı bırakır. Tls 1.1 veya üstü ile kurye çalıştırmanın bir yolu yoktur. Sunucunuzdaki bir PCI taraması öneriyle geri gelebilir:

Desteklendiyse SSL / TLS sunucularını yalnızca TLS 1.1 veya TLS 1.2'yi kullanacak şekilde yapılandırın. SSL / TLS sunucularını yalnızca blok şifrelerini kullanmayan şifreleme paketlerini desteklemek için yapılandırın.

    
verilen cevap PrgWiz 27.02.2015 15:45
-1

POODLE Savunmasızlığı protokolün kendisinde bir tasarım hatası olduğu ve bir uygulama hatası olmadığı için hiçbir yama olmayacaktır. Bunu azaltmanın tek yolu, apache sunucusunda SSLv3'ü devre dışı bırakmaktır. Aşağıdaki satırları ssl.conf dosyasına ekleyin ve zarif bir apache yeniden başlatın.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
    
verilen cevap Lal Krishna 16.10.2014 00:55

Etiketlerdeki diğer soruları oku