Bagaimana cara menambal / mengatasi kerentanan POVLE SSLv3 (CVE-2014-3566)?

Setelah serangan BEAST dan Heartbleed bug , sekarang saya telah mendengar tentang kerentanan baru di SSL / TLS yang disebut POODLE . Bagaimana cara melindungi diri dari eksploitasi?

• Apakah hanya server atau klien yang terpengaruh?
• Apakah OpenSSL / GnuTLS ini spesifik?
• Layanan apa yang terpengaruh? Hanya HTTPS atau juga IMAPS, SMTPS, OpenVPN, dll.?

Tolong tunjukkan saya contoh tentang cara menghindari kerentanan ini.

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 iptablesaturan 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.mindan 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.desktopfile, 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 .desktopfile 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.confuntuk 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 restartdan 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_CONFIGbagian 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-sslfile 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.cfgfile dan temukan bindbaris 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.

Mungkin bukan ubuntu spesifik tetapi untuk mengatasi kerentanan Poodle di Node.js Anda dapat mengatur secureOptionsuntuk require('constants').SSL_OP_NO_SSLv3ketika Anda membuat server https atau tls.

Lihat https://gist.github.com/3rd-Eden/715522f6950044da45d8 untuk informasi tambahan

"Fix" untuk kurir menonaktifkan tls 1.1 dan tls 1.2. Tampaknya tidak ada cara untuk menjalankan kurir dengan tls 1.1 atau lebih tinggi. Pemindaian PCI pada server Anda dapat kembali dengan rekomendasi:

Konfigurasikan server SSL / TLS untuk hanya menggunakan TLS 1.1 atau TLS 1.2 jika didukung. Konfigurasikan server SSL / TLS untuk hanya mendukung suite sandi yang tidak menggunakan sandi blok.

Karena POODLE Vulnerability adalah cacat desain pada protokol itu sendiri dan bukan bug implementasi, tidak akan ada patch. Satu-satunya cara untuk mengurangi ini adalah dengan menonaktifkan SSLv3 di server apache. Tambahkan baris di bawah ini ke ssl.conf dan lakukan restart apache yang anggun.

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"