Info latar belakang
SSL dirancang untuk mengamankan tingkat transportasi di internet. Untuk 'web' alias HTTP Anda akan mengetahui ini sebagai HTTPS, tetapi juga digunakan untuk protokol aplikasi lainnya. SSLv2 adalah protokol keamanan transportasi pertama yang banyak digunakan tetapi ditemukan tidak aman tidak lama kemudian. Penerus SSLv3 dan TLSv1 didukung secara luas sekarang. TLSv1.1 dan TLSv1.2 lebih baru dan mendapatkan banyak dukungan juga. Sebagian besar jika tidak semua browser web yang dirilis dari 2014 memiliki dukungan untuk itu.
Penemuan baru-baru ini oleh para insinyur Google menunjukkan bahwa SSLv3 tidak boleh digunakan lagi (seperti SSLv2 sudah lama ditinggalkan). Klien yang tidak dapat terhubung ke situs / layanan Anda mungkin sangat terbatas. CloudFlare mengumumkan bahwa kurang dari 0,09% pengunjung mereka masih mengandalkan SSLv3.
Solusi sederhana: nonaktifkan SSLv3.
Apakah Ubuntu menyediakan pembaruan?
Ya, via usn-2385-1 dengan penambahan fitur SCSV, tetapi tidak mengurangi masalah sepenuhnya karena tidak menonaktifkan SSLv3 dan tambalan hanya akan berfungsi jika kedua sisi koneksi telah ditambal. Anda akan menerimanya melalui pembaruan keamanan rutin Anda di manajer paket Anda.
Jadi, tetap saja ANDA harus mengambil tindakan sendiri untuk menonaktifkan SSLv3 (ini dapat dikonfigurasi). Versi klien / browser yang akan datang kemungkinan besar akan menonaktifkan SSLv3. Misalnya Firefox 34 akan melakukannya.
Menonaktifkan SSLv3 sepenuhnya secara default di Ubuntu pada tingkat implementasi mungkin akan memecahkan beberapa hal di luar sana juga untuk penggunaan SSL non-HTTPS yang tidak terlalu rentan, jadi saya menganggap pengelola tidak akan melakukan itu dan hanya patch SCSV ini yang akan diterapkan.
Mengapa pembaruan SCSV di OpenSSL via usn-2385-1 tidak mengurangi masalah?
Sungguh, berhenti mengajukan pertanyaan seperti itu dan lewati saja beberapa paragraf dan nonaktifkan SSLv3. Tapi hei, jika Anda tidak yakin, ini dia:
POODLE menunjukkan bahwa SSLv3 dengan sandi CBC rusak, menerapkan SCSV tidak mengubah itu. SCSV hanya memastikan Anda tidak menurunkan versi dari beberapa protokol TLS ke protokol TLS / SSL yang lebih rendah seperti yang diperlukan dengan serangan Man-in-the-Middle yang diperlukan untuk kasus-kasus biasa.
Jika Anda harus mengakses beberapa server yang tidak menawarkan TLS sama sekali, tetapi hanya SSLv3, maka browser Anda tidak benar-benar punya pilihan dan harus berbicara dengan server menggunakan SSLv3, yang kemudian rentan tanpa serangan downgrade.
Jika Anda harus mengakses beberapa server yang juga menawarkan TLSv1 + dan SSLv3 (yang tidak disarankan) dan Anda ingin memastikan koneksi Anda tidak akan diturunkan ke SSLv3 oleh penyerang, maka baik server dan klien memerlukan patch SCSV ini.
Untuk benar-benar mengurangi masalah, kecacatan SSLv3 akhir Anda sudah cukup dan Anda dapat yakin bahwa Anda tidak akan diturunkan peringkatnya. Dan Anda tidak akan dapat berbicara dengan server khusus SSLv3.
Oke, jadi bagaimana cara menonaktifkan SSLv3?
Lihat di bawah di bagian spesifik aplikasi: Firefox, Chrome, Apache, Nginx dan Postfix tercakup untuk saat ini.
Apakah hanya server atau klien yang terpengaruh?
Kerentanan ada jika server dan klien menerima SSLv3 (bahkan jika keduanya mampu TLSv1 / TLSv1.1 / TLS1.2 karena serangan downgrade).
Sebagai admin server, Anda harus menonaktifkan SSLv3 sekarang untuk keamanan pengguna Anda.
Sebagai pengguna, Anda harus menonaktifkan SSLv3 di browser Anda sekarang untuk mengamankan diri saat mengunjungi situs web yang masih mendukung SSLv3.
Apakah OpenSSL / GnuTLS / browser ini spesifik?
Tidak. Ini bug protokol (desain), bukan bug implementasi. Ini berarti Anda tidak dapat benar-benar menambalnya (kecuali Anda mengubah desain SSLv3 lama).
Dan ya, ada rilis keamanan OpenSSL baru , tetapi baca di bawah ini ( Tapi saya benar-benar sangat membutuhkan dukungan SSLv3 ... untuk alasan X, Y, Z! ) Tentang mengapa Anda lebih baik fokus menonaktifkan SSLv3 sama sekali.
Bisakah saya membunuh SSLv3 di tingkat jaringan (firewall)?
Ya, mungkin. Saya menempatkan ini di posting blog terpisah untuk pemikiran dan pekerjaan lebih lanjut. Kami mungkin memiliki beberapa iptables
aturan ajaib yang dapat Anda gunakan!
Posting blog saya: Bagaimana cara menghapus SSLv3 di jaringan Anda menggunakan iptables untuk POODLE?
Apakah hanya relevan untuk HTTPS atau juga untuk IMAP / SMTP / OpenVPN dan protokol lain dengan dukungan SSL?
Vektor serangan saat ini, seperti yang ditunjukkan oleh para peneliti, bekerja dengan mengendalikan plaintext yang dikirim ke server menggunakan Javascript yang dijalankan pada mesin korban. Vektor ini tidak berlaku untuk skenario non-HTTPS tanpa menggunakan browser.
Selain itu, biasanya klien SSL tidak mengizinkan sesi untuk diturunkan ke SSLv3 (memiliki TLSv1 + terlihat dalam kemampuan jabat tangan), tetapi browser ingin sangat kompatibel ke belakang dan mereka melakukannya. Kombinasi dengan mengendalikan plaintext dan cara spesifik header HTTP dibangun membuatnya dapat dieksploitasi.
Kesimpulan: nonaktifkan SSLv3 untuk HTTPS sekarang , nonaktifkan SSLv3 untuk layanan lain di jendela layanan Anda berikutnya.
Apa dampaknya? Apakah saya perlu mencabut dan membuat ulang sertifikat server saya? (Seperti dengan Heartbleed)
Tidak, Anda tidak perlu merotasi sertifikat Anda untuk ini. Kerentanan mengekspos pemulihan plaintext dari data sesi, itu tidak memberikan akses ke rahasia apa pun (baik kunci sesi atau kunci sertifikat).
Seorang penyerang kemungkinan besar hanya mampu mencuri header plaintext seperti cookie sesi untuk melakukan pembajakan sesi . Kendala tambahan adalah perlunya serangan MitM penuh (aktif) .
Apakah ada hal lain yang dapat saya lakukan untuk meningkatkan konfigurasi SSL saya secara umum?
Sebagai pengguna, selain menonaktifkan SSLv3 di browser Anda, tidak juga. Yah, selalu instal pembaruan keamanan terbaru.
Untuk server, ikuti panduan server TLS Mozilla . Dan uji dengan uji Lab SSL Qualys . Benar-benar tidak sulit untuk mendapatkan peringkat A + di situs Anda. Cukup perbarui paket Anda dan terapkan rekomendasi dari panduan Mozilla.
Tapi saya benar-benar sangat membutuhkan dukungan SSLv3 ... untuk alasan X, Y, Z! Sekarang apa?
Ya, ada tambalan yang menghindari serangan downgrade dari klien yang mampu TLSv1, yang disebut SSLv3 Fallback Protection. Ini akan meningkatkan keamanan TLSv1 + juga, dengan cara (serangan downgrade lebih sulit / tidak mungkin). Ini ditawarkan sebagai backport dari versi OpenSSL yang lebih baru di Ubuntu Security advisory usn-2385-1 .
Tangkapan besar: Baik klien dan server membutuhkan tambalan ini agar berfungsi. Jadi, menurut pendapat saya saat Anda memperbarui klien dan server, Anda hanya perlu memutakhirkan ke TLSv1 +.
Namun, tolong, tolong, pensiun saja SSLv3 di jaringan Anda untuk saat ini. Berusaha untuk meningkatkan standar keamanan dan hanya membuang SSLv3.
Saya mendengar tentang dukungan SCSV untuk menghilangkan serangan downgrade protokol. Apakah saya membutuhkannya?
Hanya jika Anda benar-benar membutuhkan SSLv3 untuk beberapa alasan aneh, tetapi juga meningkatkan keamanan di TLSv1 +, jadi ya, saya sarankan Anda untuk menginstalnya. Ubuntu menyediakan pembaruan untuk fitur ini di usn-2385-1 . Anda akan menerimanya melalui pembaruan keamanan rutin Anda di manajer paket Anda.
Menguji kerentanan untuk situs yang dihosting secara pribadi (mis. Intranet / offline).
Server Anda rentan hanya jika mereka mendukung SSLv3. Beberapa opsi di sini:
Dengan OpenSSL s_client:
openssl s_client -connect <server>:<port> -ssl3
Jika koneksi berhasil, sslv3 diaktifkan. Jika gagal, itu dinonaktifkan. Ketika gagal Anda akan melihat sesuatu seperti:
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Menggunakan nmap
:
nmap --script ssl-enum-ciphers -p 443 myhostname.tld
Seharusnya menampilkan ' SSLv3: No supported ciphers found
'. Sesuaikan untuk nama host / port Anda.
Menggunakan cipherscan . Klon / unduh biner dan jalankan:
./cipherscan myhostname.tld
Seharusnya tidak mencantumkan apa pun dengan SSLv3 di bawah kolom 'protokol'.
Browser Firefox
Buka about:config
, cari, security.tls.version.min
dan atur nilainya 1
. Kemudian restart browser Anda untuk menjatuhkan koneksi SSL terbuka.
Firefox dari versi 34 dan seterusnya akan menonaktifkan SSLv3 secara default dan karenanya tidak memerlukan tindakan ( sumber ). Namun, pada saat penulisan, 33 baru saja dirilis dan 34 ditetapkan untuk 25 November.
Google Chrome (Linux)
Edit /usr/share/applications/google-chrome.desktop
file, mis
sudo nano /usr/share/applications/google-chrome.desktop
Edit semua baris yang dimulai dengan Exec=
untuk memasukkan --ssl-version-min=tls1
.
Misalnya garis seperti
Exec=/usr/bin/google-chrome-stable %U
menjadi
Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U
Kemudian pastikan untuk sepenuhnya menutup browser (aplikasi Chrome mungkin membuat browser Anda aktif di latar belakang!).
Catatan: Anda mungkin perlu mengulangi setiap pembaruan paket google-chrome ini, menimpa .desktop
file peluncur ini . Google Chrome atau browser Chromium dengan SSLv3 dinonaktifkan secara default belum diumumkan pada saat penulisan.
Apache HTTPD Server
Jika Anda menjalankan server web Apache yang saat ini memungkinkan SSLv3, Anda perlu mengedit konfigurasi Apache. Pada sistem Debian dan Ubuntu file tersebut adalah /etc/apache2/mods-available/ssl.conf . Pada CentOS dan Fedora file tersebut adalah /etc/httpd/conf.d/ssl.conf . Anda perlu menambahkan baris berikut ke konfigurasi Apache Anda dengan arahan SSL lainnya.
SSLProtocol All -SSLv2 -SSLv3
Ini akan memungkinkan semua protokol kecuali SSLv2 dan SSLv3.
Ketika Anda melakukannya, Anda mungkin ingin mempertimbangkan untuk meningkatkan konfigurasi ciphersuite untuk server web Anda seperti yang dijelaskan pada panduan server TLS Mozilla . Tambahkan misalnya:
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"
Kemudian periksa apakah konfigurasi baru sudah benar (tidak ada kesalahan ketik dll.):
sudo apache2ctl configtest
Dan restart server, mis
sudo service apache2 restart
Pada CentOS dan Fedora:
systemctl restart httpd
Info lebih lanjut: Dokumentasi Apache
Sekarang ujilah: Jika situs Anda tersedia untuk umum, ujilah menggunakan alat Lab SSL milik Qualys .
Server nginx
Jika Anda menjalankan Nginx, cukup sertakan baris berikut dalam konfigurasi Anda di antara arahan SSL lainnya:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Ketika Anda melakukannya, Anda mungkin ingin mempertimbangkan untuk meningkatkan konfigurasi ciphersuite untuk server web Anda seperti yang dijelaskan pada panduan server TLS Mozilla . Tambahkan misalnya:
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;
Dan restart server, mis
sudo service nginx restart
Referensi: Dokumentasi Nginx
Sekarang ujilah: Jika situs Anda tersedia untuk umum, ujilah menggunakan alat Lab SSL milik Qualys .
Server web Lighttpd
Versi Lighttpd> 1.4.28 mendukung opsi konfigurasi untuk menonaktifkan SSLv2 dan v3. Rilis Lighttpd sebelum 1.4.28 memungkinkan Anda untuk menonaktifkan SSLv2 SAJA. Harap dicatat bahwa Ubuntu 12,04 LTS dan instal sebelumnya di best lighttpd v1.4.28 dan oleh karena itu perbaikan sederhana tidak tersedia untuk distribusi tersebut. Oleh karena itu perbaikan ini hanya boleh digunakan untuk versi Ubuntu yang lebih besar dari 12,04.
Untuk Ubuntu versi 12.04 atau Debian 6, paket lighttpd yang diperbarui tersedia dari repositori openSUSE:
http://download.opensuse.org/repositories/server:/http/Debian_6.0
Paket ini ditujukan untuk Debian 6 (pemerasan) tetapi berfungsi juga pada 12,04 (tepat)
Edit Anda /etc/lighttpd/lighttpd.conf
untuk menambahkan baris berikut setelah ssl.engine = "enable"
arahan
ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"
Maka Anda harus memulai kembali layanan lighttpd dengan a sudo service lighttpd restart
dan melakukan tes jabat tangan ssl3 seperti yang dijelaskan di bagian sebelumnya untuk memastikan bahwa perubahan tersebut berhasil dilaksanakan.
Diambil dari http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL .
SMTP Postfix
Untuk 'oportunistik SSL' (kebijakan enkripsi tidak ditegakkan dan polos juga dapat diterima), Anda tidak perlu mengubah apa pun. Bahkan SSLv2 lebih baik daripada biasa, jadi jika Anda perlu mengamankan server Anda, Anda tetap harus menggunakan mode 'wajib SSL'.
Untuk mode 'wajib SSL' sudah dikonfigurasikan, cukup tambahkan / ubah pengaturan smtpd_tls_mandatory_protocols untuk koneksi inbound dan smtp_tls_mandatory_protocols untuk koneksi outbound:
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3
Secara opsional, jika Anda juga ingin menonaktifkan SSLv3 untuk enkripsi oportunistik (meskipun itu tidak perlu seperti yang dijelaskan di atas), lakukan sebagai berikut:
smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3
dan mulai kembali Postfix:
sudo service postfix restart
Sendmail
(Suntingan yang tidak diverifikasi oleh pengguna anonim, saya tidak nyaman dengan Sendmail, harap verifikasi.)
Opsi ini dikonfigurasikan di LOCAL_CONFIG
bagian Andasendmail.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
Tempat perlindungan merpati
Di Dovecot v2.1 +, tambahkan yang berikut ke /etc/dovecot/local.conf
(atau file baru Anda /etc/dovecot/conf.d
):
ssl_protocols = !SSLv2 !SSLv3
dan mulai ulang Dovecot:
sudo service dovecot restart
Untuk versi yang lebih lama Anda harus menambal kode sumber .
Courier-imap (imapd-ssl)
Courier-imap memungkinkan SSLv3 secara default di Ubuntu 12.04 dan lainnya. Anda harus menonaktifkannya dan menggunakan STARTTLS sebagai gantinya untuk memaksa TLS. Edit /etc/courier/imapd-ssl
file konfigurasi Anda untuk mencerminkan perubahan berikut
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!>"
Server HAProxy
SSL didukung dalam HAProxy> = 1.5.
Edit /etc/haproxy.cfg
file dan temukan bind
baris Anda . Menambahkan no-sslv3
. Sebagai contoh:
bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3
Referensi: Dokumentasi HAProxy
OpenVPN
Tampaknya tidak terpengaruh ( sumber ).
OpenVPN menggunakan TLSv1.0, atau (dengan> = 2.3.3) secara opsional TLSv1.2 dan karenanya tidak terpengaruh oleh POODLE.
Wayang
Wayang menggunakan SSL melalui HTTPS tetapi tidak digunakan oleh klien 'browser', hanya agen Wayang yang tidak rentan terhadap vektor serangan yang ditunjukkan. Namun, praktik terbaik untuk menonaktifkan SSLv3 saja.
Rekomendasi saya adalah menggunakan modul Stephenrjohnson / puppetmodule Puppet untuk mengatur master Wayang Anda di mana saya membunuh SSLv3 beberapa waktu lalu.