Arkaplan bilgisi
SSL, internetteki taşıma seviyesini güvence altına almak için tasarlanmıştır. 'Web' aka HTTP için bunu HTTPS olarak bileceksiniz, ancak diğer uygulama protokolleri için de kullanılıyor. SSLv2, yaygın olarak kullanılan ilk ulaşım güvenliği protokolüdür, ancak çok geçmeden güvensiz bulundu. Halefler SSLv3 ve TLSv1 şimdi yaygın olarak desteklenmektedir. TLSv1.1 ve TLSv1.2 daha yeni ve çok destek alıyorlar. Çoğu, 2014'ten yayınlanan web tarayıcılarının tümü desteklemiyorsa.
Google mühendisleri tarafından yapılan son keşif, SSLv3'ün artık kullanılmaması gerektiğine işaret ediyor (SSLv2'nin uzun süre önce kullanımdan kaldırıldığı gibi). Sitenize / hizmetinize bağlanamayan müşteriler muhtemelen çok çok sınırlıdır. CloudFlare , ziyaretçilerinin% 0.09'undan daha azının hala SSLv3'e güvendiğini açıkladı .
Basit çözüm: SSLv3'ü devre dışı bırakın.
Ubuntu herhangi bir güncelleme sunuyor mu?
Evet, SCSV özelliğinin eklenmesiyle usn -2385-1 üzerinden , ancak SSLv3'ü devre dışı bırakmadığından ve yamanın sadece bağlantının her iki tarafının da eklenmiş olması durumunda yamayı çözmemesi nedeniyle sorunu tamamen azaltmaz. Paket yöneticinizdeki düzenli güvenlik güncellemeleriniz aracılığıyla alacaksınız.
Yani, yine SİZ (o yapılandırılabilir var) SSLv3 devre dışı bırakmak için eylemi kendinizi almak zorunda. Müşterilerin / tarayıcıların gelecekteki sürümleri, büyük olasılıkla SSLv3'ü devre dışı bırakacaktır. Örneğin Firefox 34 bunu yapacak.
SSLv3'ü uygulama düzeyinde Ubuntu'da varsayılan olarak tamamen devre dışı bırakmak, muhtemelen çok hassas olmayan HTTPS olmayan SSL kullanımları için de bazı şeyleri ortadan kaldıracaktır, bu yüzden bakıcıların bunu yapmayacağını ve yalnızca bu SCSV yamasının uygulanacağını varsayıyorum.
OpenSSL’de usn-2385-1 üzerinden SCSV güncellemesi neden sorunu azaltmıyor?
Gerçekten, bu tür sorular sormayı kesin ve birkaç paragraf atlayın ve SSLv3'ü devre dışı bırakın. Ama, ikna değilseniz, işte buradasınız:
POODLE, CBC şifreli SSLv3'ün bozulduğunu, SCSV uygulamasının bunu değiştirmediğini gösteriyor. SCSV, yalnızca olağan durumlar için gerekli olan Orta Man saldırısı için bazı TLS protokollerinden düşük TLS / SSL protokollerine geçmediğinizden emin olmanızı sağlar.
Eğer hiç TLS sunmayan bir sunucuya, sadece SSLv3'e erişmeniz gerekiyorsa, tarayıcınız gerçekten bir seçeneğe sahip değildir ve SSLv3 kullanarak sunucuyla konuşmak zorunda kalır ve bu da düşürme saldırısı olmadan savunmasız kalır.
Ayrıca TLSv1 + ve SSLv3 sunan bazı sunuculara da erişmeniz gerekiyorsa (bu önerilmez) ve bağlantınızın bir saldırgan tarafından SSLv3'e indirilmeyeceğinden emin olmak istiyorsanız, hem sunucunun hem de istemcinin bu SCSV düzeltme ekine ihtiyacı vardır.
Sorunu tamamen azaltmak için, SSLv3'ün devre dışı bırakılması sonunuz yeterlidir ve düşürülmeyeceğinizden emin olabilirsiniz. Ve sadece SSLv3 sunucularıyla konuşamazsınız.
Tamam, peki SSLv3'ü nasıl devre dışı bırakabilirim?
Uygulamaya özel bölümlerde aşağıya bakın: Firefox, Chrome, Apache, Nginx ve Postfix şimdilik kaplıdır.
Yalnızca sunucular mı yoksa müşteriler de etkileniyor mu?
Güvenlik açığı, hem sunucu hem de istemci SSLv3'ü kabul ederse ortaya çıkar (her ikisi de düşürme saldırısı nedeniyle TLSv1 / TLSv1.1 / TLS1.2 kapasitesine sahip olsa bile).
Bir sunucu yöneticisi olarak, kullanıcılarınızın güvenliği için şimdi SSLv3'ü devre dışı bırakmalısınız .
Bir kullanıcı olarak, hala SSLv3'ü destekleyen web sitelerini ziyaret ederken kendinizi güvenceye almak için şimdi tarayıcınızda SSLv3'ü devre dışı bırakmalısınız .
Bu OpenSSL / GnuTLS / tarayıcıya özgü mü?
Hayır. Bu bir protokol (tasarım) hatasıdır, uygulama hatası değildir. Bu, gerçekten yama yapamayacağınız anlamına gelir (eski SSLv3'ün tasarımını değiştirmiyorsanız).
Ve evet, orada yeni bir var OpenSSL güvenlik serbest bırakma , ancak aşağıya okumak ( Ama gerçekten gerçekten nedeni X için ... SSLv3 desteğe ihtiyacı, Y, Z! ) Daha iyi tamamen SSLv3 devre dışı odaklanmak istiyorum neden.
SSLv3'ü ağ (güvenlik duvarı) düzeyinde öldürebilir miyim?
Evet, muhtemelen. Daha fazla düşünce ve çalışma için bunu ayrı bir blog postasına koydum. iptablesKullanabileceğiniz bazı sihirli kurallarımız olabilir!
Blog yazım: POODLE için iptables kullanarak ağınızda SSLv3'ü nasıl indirebilirim?
Yalnızca HTTPS ile mi yoksa IMAP / SMTP / OpenVPN ve SSL destekli diğer protokoller için de geçerli mi?
Araştırmacılar tarafından gösterildiği gibi mevcut saldırı vektörü, kurbanın makinesinde çalışan Javascript kullanılarak sunucuya gönderilen düz metni kontrol etme ile çalışır. Bu vektör tarayıcı kullanmadan HTTPS olmayan senaryolar için geçerli değildir.
Ayrıca, normal olarak bir SSL istemcisi oturumun SSLv3'e indirgenmesine izin vermez (el sıkışma özelliklerinde TLSv1 + olması), ancak tarayıcılar geriye dönük olarak uyumlu olmak isterler ve bunu yaparlar. Kontrol düz metin ile bir HTTP başlığının oluşturulma şeklini içeren kombinasyon onu sömürülebilir kılar.
Sonuç: HTTPS için SSLv3'ü şimdi devre dışı bırakın, bir sonraki servis pencerenizdeki diğer servisler için SSLv3'ü devre dışı bırakın.
Etkisi nedir? Sunucu sertifikamı iptal edip yeniden oluşturmam gerekir mi? (Heartbleed ile olduğu gibi)
Hayır, bunun için sertifikalarınızı döndürmeniz gerekmez. Güvenlik açığı, oturum verilerinden düz metin kurtarmayı ortaya çıkarır, hiçbir sırya erişim sağlamamaktadır (oturum anahtarı veya sertifika anahtarı değil).
Bir saldırgan, büyük olasılıkla oturum ele geçirme işlemini gerçekleştirmek için yalnızca oturum çerezleri gibi düz metin başlıklarını çalabilir . Ek bir kısıtlama, tam (aktif) bir MitM saldırısına ihtiyaç duyulmasıdır .
Genel olarak SSL yapılandırmamı 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çekte değil. Eh, sadece her zaman en son güvenlik güncellemelerini yükleyin.
Sunucular için Mozilla'nın TLS sunucu kılavuzunu takip edin . Ve Qualys'in SSL Labs testi ile test edin . Sitenizde A + derecesi almak o kadar da zor değil. Paketlerinizi güncelleyin ve önerileri Mozilla kılavuzundan uygulayın.
Ama gerçekten SSLv3 desteğine ihtiyacım var ... neden X, Y, Z! Şimdi ne olacak?
Peki, SSLS3 Geri Dönüş Koruması adı verilen TLSv1 yetenekli istemcilerin düşürme saldırısını engelleyen bir yama var. Bu arada, TLSv1 + güvenliğini de artıracak (düşürme saldırısı zor / imkansız). Ubuntu Güvenlik danışmanlığı usn-2385-1'deki yeni bir OpenSSL versiyonundan destek olarak sunuluyor .
Büyük yakalama: Çalışmak için hem istemciler hem de sunucular bu yamaya ihtiyaç duyar. Dolayısıyla, hem müşterileri hem de sunucuları güncellerken bence sadece TLSv1 + 'a yükseltmelisiniz.
Ancak, lütfen, lütfen, şimdilik ağınızda SSLv3'ü emekli edin. Güvenlik standartlarını yükseltmek için çaba sarf edin ve sadece SSLv3'ü yok edin.
Protokolü düşürme saldırısını ortadan kaldırmak için SCSV desteğini duydum. İhtiyacım var mı?
Yalnızca bazı garip nedenlerden dolayı gerçekten SSLv3'e ihtiyacınız varsa, ancak TLSv1 + 'da da güvenliği artırır, bu yüzden evet, yüklemenizi öneririm. Ubuntu, bu özellik için usn-2385-1'deki bir güncelleme sunmaktadır . Paket yöneticinizdeki düzenli güvenlik güncellemeleriniz aracılığıyla alacaksınız.
Özel olarak barındırılan siteler için güvenlik açığı testi (örneğin, intranet / çevrimdışı).
Sunucularınız yalnızca SSLv3'ü destekliyorsa 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 etkindir. Başarısız olursa, devre dışı bırakılır. Başarısız olduğunda şöyle bir şey görmelisin:
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Kullanarak nmap:
nmap --script ssl-enum-ciphers -p 443 myhostname.tld
' SSLv3: No supported ciphers found' Çıkmalı. Ana bilgisayar adınız / bağlantı noktanız için ayarlayın.
Şifreli tarama kullanarak . İkili dosyayı klonla / indir ve çalıştır:
./cipherscan myhostname.tld
O gerektiğini değil 'protokolleri' sütunu altında SSLv3 ile bir şey sıralar.
Firefox tarayıcısı
Aç about:config, bul security.tls.version.minve değeri olarak ayarla 1. 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 varsayılan olarak SSLv3'ü devre dışı bırakır ve bu nedenle herhangi bir işlem yapmaz ( kaynak ). Ancak, şu anda, 33, sadece serbest bırakılır ve 34, 25 Kasım için ayarlanır.
Google Chrome (Linux)
Edit /usr/share/applications/google-chrome.desktopdosyasını, mesela
sudo nano /usr/share/applications/google-chrome.desktop
Dahil etmekle başlayan tüm satırlarıExec= düzenleyin --ssl-version-min=tls1.
Örneğin bir çizgi
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 .desktopbaşlatıcı dosyasının üzerine yazarak, her google chrome paket güncellemesini tekrarlamanız gerekebilir . SSLv3'ün varsayılan olarak devre dışı bırakıldığı bir Google Chrome veya Chromium tarayıcı, henüz yazma sırasında açıklanmadı.
Apache HTTPD Sunucusu
Şu anda SSLv3'e izin veren bir Apache web sunucusu kullanı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, /etc/httpd/conf.d/ssl.conf dosyasıdır . Apache yapılandırmanıza diğer SSL direktifleriyle aşağıdaki satırı eklemeniz gerekir.
SSLProtocol All -SSLv2 -SSLv3
Bu, SSLv2 ve SSLv3 dışındaki tüm protokollere izin verecektir.
Bu sırada Mozilla’nın TLS sunucu kılavuzunda açıklandığı şekilde, web sunucunuz için şifreleme yapılandırmasını geliştirmeyi düşünebilirsiniz . Ö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"
Ardından yeni yapılandırmanın doğru olup olmadığını kontrol edin (yazım hatası yok):
sudo apache2ctl configtest
Ve sunucuyu yeniden başlatın, örneğin
sudo service apache2 restart
CentOS ve Fedora'da:
systemctl restart httpd
Daha fazla bilgi: Apache belgeleri
Şimdi test edin: Siteniz herkese açıksa , Qualys'in SSL Labs aracını kullanarak test edin .
Nginx sunucusu
Nginx kullanıyorsanız, yapılandırmanıza diğer SSL direktifleri arasına aşağıdaki satırı eklemeniz yeterlidir:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Bu sırada Mozilla’nın TLS sunucu kılavuzunda açıklandığı şekilde, web sunucunuz için şifreleme yapılandırmasını geliştirmeyi düşünebilirsiniz . Ö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, örneğin
sudo service nginx restart
Referans: Nginx belgeleri
Şimdi test edin: Siteniz herkese açık ve uygunsa , Qualys'in SSL Labs aracını kullanarak test edin .
Lighttpd web sunucusu
Lighttpd sürümleri> 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, SADECE SSLv2'yi devre dışı bırakmanıza izin verir. Lütfen Ubuntu 12.04 LTS ve önceki sürümlerin en iyi ışık v1.4.28'de yüklendiğini ve bu nedenle bu dağıtımlar için basit bir düzeltmenin bulunmadığını 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 12.04 veya Debian 6 sürümleri için güncelleştirilmiş bir lighttpd paketi openSUSE deposundan edinilebilir:
http://download.opensuse.org/repositories/server:/http/Debian_6.0
Paket Debian 6 (sıkmak) için tasarlanmıştır, ancak aynı zamanda 12.04'te de çalışır
Düzenlemenizle /etc/lighttpd/lighttpd.confsonra aşağıdaki satırları ekleyin ssl.engine = "enable"direktif
ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"
Ardından, lighttpd hizmetini a ile yeniden başlatmalı sudo service lighttpd restartve değişikliğin başarıyla uygulandığından emin olmak için önceki bölümlerde açıklanan şekilde ssl3 el sıkışma testini gerçekleştirmelisiniz.
Http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL adresinden alınmıştır .
Postfix SMTP
'Fırsatçı SSL' (şifreleme politikası uygulanmayan ve düz de kabul edilebilir) için, hiçbir şeyi değiştirmeniz gerekmez. SSLv2 bile düzlükten iyidir, bu nedenle sunucunuzu güvenli hale getirmeniz gerekiyorsa, yine de 'zorunlu SSL' modunu kullanıyor olmalısınız.
'Zorunlu SSL' modu önceden yapılandırılmış olması için, sadece değiştirmek eklemek / smtpd_tls_mandatory_protocols gelen bağlantıları ve ayarı 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, fırsatçı şifreleme için SSLv3'ü de devre dışı bırakmak istiyorsanız (yukarıda açıklandığı gibi gerekli olmasa da), bu şekilde yapın:
smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3
ve Postfix'i yeniden başlatın:
sudo service postfix restart
Posta göndermek
(Anonim kullanıcı tarafından doğrulanmamış düzenleme, Sendmail ile rahat değilim, lütfen doğrulayın.)
Bu seçenekler içinde yapılandırılır LOCAL_CONFIGbölümünde seninsendmail.mc
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
güvercinlik
Dovecot v2.1 + 'da aşağıdakini /etc/dovecot/local.conf(veya içindeki yeni bir dosyaya /etc/dovecot/conf.d) ekleyin :
ssl_protocols = !SSLv2 !SSLv3
ve Dovecot'u yeniden başlatın:
sudo service dovecot restart
Daha eski sürümler için kaynak kodunu eklemeniz gerekir .
Kurye imap (imapd-ssl)
Courier-imap, SSLv3'ün Ubuntu 12.04 ve diğerlerinde varsayılan olarak kullanılmasını sağlar. Devre dışı bırakmalı ve TLS'yi zorlamak için STARTTLS kullanmalısınız. Senin düzenleme /etc/courier/imapd-sslaşağıdaki değişiklikleri yansıtacak şekilde yapılandırma dosyasını
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 Sunucusu
SSL, HAProxy> = 1.5'te desteklenmektedir.
Edit /etc/haproxy.cfgdosyayı ve bulmak bindhattı. Ekle no-sslv3. Örneğin:
bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3
Referans: HAProxy Belgeleri
OpenVPN
Etkilenmemiş gibi görünüyor ( kaynak ).
OpenVPN isteğe bağlı olarak TLSv1.2 TLS (veya> = 2.3.3 ile) kullanır ve bu nedenle POODLE'den etkilenmez.
Kukla
Kukla, HTTPS üzerinden SSL kullanıyor ancak 'tarayıcı' istemcileri tarafından kullanılmıyor, yalnızca gösterilen saldırı vektörüne karşı hassas olmayan kukla ajanlar kullanmıyor. Ancak, SSLv3'ü devre dışı bırakmak en iyi yöntemdir.
Benim tavsiye kullanmaktır stephenrjohnson / puppetmodule içinde senin Kukla ustası kurmak için Kukla modülünü ben SSLv3 öldüren bir süre önce.