Saya mendapatkan kesalahan: SSL3_GET_RECORD: gagal mendekripsi atau mac catatan buruk

7

Saya memiliki server sendiri (tempat saya menjalankan Apache/2.4.27), dan hari ini saya menyadari bahwa dari (Berani dan Google Chrome - komputer yang berbeda) saya mendapatkan kesalahan dari situs web saya ini;

This site can’t provide a secure connection

mywebsite.com sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

Dan anehnya, saya mendapatkan kesalahan ini setiap klik kelima di situs web saya.

Dari file conf saya:

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/mywebsite/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mywebsite/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/mywebsite/chain.pem
SSLCompression off

dari options-ssl-apache.conf;

SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite          EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLHonorCipherOrder     on
SSLCompression          off

Saya telah memeriksa file log dari situs web tetapi tidak ada, juga tidak ada di sini; /var/log/apache2/error.log

Saya mencoba mencari tahu apa yang menyebabkan kesalahan ini, ada ide di mana saya dapat menemukan lebih banyak info atau lebih baik lagi, bagaimana menyelesaikan masalah ini?

EDIT:

Jika saya mencoba openssl s_client -connect mywebsite.com:443, itu akan kembali:

Saya menggunakan: OpenSSL 1.1.0f

CONNECTED(00000003)

...

3073276480:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:../ssl/record/ssl3_record.c:469:

EDIT LAIN:

Seperti yang disarankan @quadruplebucky, saya mengubah opsi-ssl-apache.conf menjadi:

SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite           HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1
SSLHonorCipherOrder     on
SSLCompression          off

#SSLSessionTickets       off

Saya juga mencoba menambahkan SSLProtocol all -SSLv2 -SSLv3ke file conf virtualhost saya, dan pada saat yang sama saya mengubah beberapa hal di sini;/etc/apache2/mods-available/ssl.conf

#SSLCipherSuite HIGH:!aNULL
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1

SSLHonorCipherOrder on

#   The protocols to enable.
#   Available values: all, SSLv3, TLSv1, TLSv1.1, TLSv1.2
#   SSL v2  is no longer supported
SSLProtocol all -SSLv2 -SSLv3

EDIT:

Setelah mengubah LogLevel ke Infodalamnya kembali:

[Sat Jul 08 13:34:53.374307 2017] [ssl:info] [pid 8710] [client] AH02008: SSL library error 1 in handshake (server mywebsite:443)
[Sat Jul 08 13:34:53.374717 2017] [ssl:info] [pid 8710] SSL Library Error: error:140940F4:SSL routines:ssl3_read_bytes:unexpected message
[Sat Jul 08 13:34:53.374750 2017] [ssl:info] [pid 8710] [client] AH01998: Connection closed to child 1 with abortive shutdown (server mywebsite:443)

EDIT:

Jika saya menjalankan dengan opsi -crlf, seperti ini:

openssl s_client -crlf -connect mywebsite:443

Saya tidak mendapatkan kesalahan?

Satu hal lagi jika saya mengubah LogLevel menjadi debug, sebelum kesalahan itu saya mendapatkan ini:

[Tue Jul 11 23:00:38.641568 2017] [core:debug] [pid 26561] protocol.c(1273): [client 188.64.25.162:23165] AH00566: request failed: malformed request line
[Tue Jul 11 23:00:38.641634 2017] [headers:debug] [pid 26561] mod_headers.c(900): AH01503: headers: ap_headers_error_filter()

Jadi setelah ini kesalahan yang sama akan terjadi:

SSL Library Error: error:140940F4:SSL routines:ssl3_read_bytes:unexpected message

openssl version
OpenSSL 1.1.0f  25 May 2017
pengguna134969
sumber
Seharusnya tidak mungkin terjadi kesalahan konfigurasi titik akhir yang menyebabkan 'dekripsi buruk atau mac' (peringatan 20). Apakah ada sesuatu di jaringan antara klien ini dan server ini, seperti firewall, IDS, IPS, DLP, atau bahkan router 'pintar'? Dapatkah Anda menguji berulang kali (karena ini mungkin tergantung data dan dengan demikian kuasi-acak) menghubungkan dari server itu sendiri, atau dari mesin pada segmen yang sama dengan server?
dave_thompson_085
perlihatkan konten yang relevan dari * .443 virtualhost (seluruh virtualhost jika diperlukan), juga output dari "apachectl -S" sehingga kita dapat membuang kesalahan konfigurasi.
ezra-s
pesan kesalahan, keluhan tentang SSL v3, namun dalam konfigurasi Anda dinonaktifkan ...
alexus
Anda mengatakan Anda menggunakan OpenSSL 1.1.0f. Adalah bahwa pada kedua server dan pada mesin di mana Anda mengeluarkan perintah s_client di atas? Platform apa yang dijalankan oleh server Anda? Anda mungkin ingin melihat apakah kesalahan terjadi dengan ciphersuites tertentu, Misalnya apa yang terjadi jika Anda menambahkan "-cipher AES128-SHA" di akhir perintah s_client Anda?
Matt Caswell
ninjaed: @alexus: nama fungsi dan file dan beberapa literal ssl3*dan SSL3*di OpenSSL juga digunakan untuk TLS (1.0 hingga 1.2) karena kesamaan teknis antara protokol-protokol tersebut. user134969: 'panjang terlalu pendek' juga tidak boleh disebabkan oleh konfigurasi apa pun. Jika itu dapat diulang, cobalah untuk mendapatkan s_client -debug(dengan RSA polos -cipherjika Anda tidak melakukannya di server) dan penangkapan wireshark untuk acara yang sama sehingga kami dapat melihat data kawat yang sebenarnya dan membandingkannya dengan apa yang dilihat program.
dave_thompson_085

Jawaban:

8

Anda tidak dapat mengetahui dari kesalahan itu jika server Anda sedang melakukan negosiasi SSLv3 atau TLSv1 (Anda mungkin ingin melihat pertanyaan ini di Unix & Linux dan pastikan itu dinonaktifkan di mana-mana di apache ...) --- the 1.1.0f kode sumber di sini di GitHub sengaja mengaburkan keduanya ...

   if (enc_err < 0) {
    /*
     * A separate 'decryption_failed' alert was introduced with TLS 1.0,
     * SSL 3.0 only has 'bad_record_mac'.  But unless a decryption
     * failure is directly visible from the ciphertext anyway, we should
     * not reveal which kind of error occurred -- this might become
     * visible to an attacker (e.g. via a logfile)
     */
    al = SSL_AD_BAD_RECORD_MAC;
    SSLerr(SSL_F_SSL3_GET_RECORD,
           SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC);
    goto f_err;
}

Jadi, Anda mungkin ingin menyusun ulang paket sandi Anda:

SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1

Posting ini di askubuntu tentang kerentanan POODLE memiliki daftar sumber daya yang sangat baik untuk inspeksi dan pemasangan pipa SSL.

Generator konfigurasi Mozilla adalah layanan publik yang sangat baik .

Komentar "menerima kesalahan ini setiap klik kelima" agak aneh. Apakah maksud Anda klik , atau setiap baris kelima adalah permintaan yang buruk di log? Coba mulai apache single-threaded (flag -X) dan lihat apakah itu melakukan hal yang sama ... atau mungkin pengaturan SSLSessionTickets off.

Pemikiran saya di sini adalah untuk menghilangkan threading dan sesi / cache koherensi / konsistensi sebagai sumber masalah. Menjalankan apache single-threaded (memulainya dengan flag -X) adalah salah satu cara untuk mencapai ini, cara lain adalah dengan mengatur MaxClients=1(setidaknya dengan model MPM). Tiket sesi telah menjadi sumber masalah di masa lalu dengan TLSv1.2 dan diaktifkan secara default, ini adalah alasan di baliknya SSLSessionTickets off(perhatikan ini adalah bagian dari pesan "Server Hello" SSL, bukan cookie sesi atau sejenisnya). Kesalahan 'setiap klik kelima' masih mengganggu saya - saya tidak bisa tidak melihat bahwa sebagian besar browser akan menyalurkan empat permintaan sumber daya dalam satu permintaan ...) dan membuka koneksi baru (jabat tangan ssl baru, dll ...) untuk yang kelima ... tanpa tangkapan paket, sulit untuk mengatakan apa yang sebenarnya terjadi.

Tampaknya Anda telah menghilangkan negosiasi sandi sebagai sumber kesalahan (Anda dapat menduplikasi kondisi kesalahan di bawah spesifikasi sandi sandi yang jauh lebih ketat, kecuali saya salah). Saya ingin tahu apakah Anda dapat memicu kesalahan dengan menegosiasikan ulang SSL (hanya untuk iseng, katakanlah): openssl s_client -connect server:443lalu ketik 'R', lihat apa kata log.
Lihat juga apakah cache sesi berfungsi dengan -reconnectopsi untuk s_client.
Sesuatu harus berbeda tentang konteks penerimaan untuk permintaan SSL, dan tampaknya cara terbaik untuk mengetahui itu (singkat dari pemeriksaan byte-by-byte dari apa yang terjadi di kawat, yang mungkin sulit untuk dianonimkan) adalah untuk sangat batasi ukuran dari apa yang didengar (yaitu, jumlah pendengar).

Alat debugging lain yang saya coba (dengan anggapan memposting tangkapan paket tidak ada pertanyaan ....)
- ssltap (di libnss3-toolsdalam ubuntu)
- cipherscan
- sslscan

UPDATE Menyodok
ini melalui ssltap terlihat sangat buruk seperti bug OpenSSL # 3712 muncul kembali (negosiasi ulang kunci selama baca / tulis, pada dasarnya). Mencari solusi yang layak yang tidak akan mematikan kinerja. Hal menyenangkan!

quadruplebucky
sumber
1
Saya juga bermain dengan deklarasi SSLCipherSuite yang lebih eksplisit (sesuai dengan konfigurasi Mozilla), atur LogLevel ke info atau debug, tcpdump / wireshark pcaps, dan sebagainya, apa pun untuk mencari tahu apa yang sebenarnya terjadi.
quadruplebucky
1
Mengapa Anda tidak mencoba alat seperti cipherscan github.com/mozilla/cipherscan atau sslscan github.com/rbsec/sslscan (juga dalam banyak repo) untuk mencoba mencari tahu apa yang sebenarnya terjadi sebelum melakukan regresi?
quadruplebucky
Dengan SSLProtocol -SSLv3koneksi pasti bukan SSL3. Ingatlah dalam fungsi OpenSSL (dan sourcefiles) bernama dengan ssl3 masih merupakan bagian dari semua protokol TLS hingga 1.2. Menghapus SSLv3 (dan TLSv1 di 1.1.0 saja) cipher benar-benar mencegah setiap protokol di bawah TLS1.2 sedang dinegosiasikan, tetapi dengan up-to-date browser yang harus baik-baik saja.
dave_thompson_085
@ user134969: untuk wireshark untuk mendekripsi koneksi ini (dan dengan demikian dapat membantu di sini) Anda perlu (sementara) membatasi pertukaran kunci ke RSA biasa; ini paling mudah dilakukan di sisi Apache dengan SSLCiphers RSA+AES. (Dan berikan file privatekey server di Edit / Preferences / Protokol / SSL.) Chrome digunakan untuk mengeluh tentang RSA biasa (yaitu bukan PFS) tapi saya hanya mencoba ulang dan saya tampaknya senang sekarang.
dave_thompson_085
@quadruplebucky dapatkah Anda menunjukkan kepada saya apa lokasi "ssl3_record.c" di sistem?
user134969
6

Saya pernah melihat ini sebelumnya, pernah ini sebelumnya sebenarnya.

Jawaban dalam kasus saya akhirnya menjadi sangat halus.

Adaptor jaringan mengaktifkan TCP Segment Offloading, yang karena bug dari beberapa bentuk adalah mangling (atau memotong, tidak ingat) beberapa byte terakhir dari beberapa pesan - yang kemudian menyebabkan MAC pada catatan SSL gagal.

Itu adalah mesin virtual di VMWare.

Saya akan mencoba menonaktifkan TSO / GSO / GRO di lingkungan Anda dan melihat apakah masalahnya hilang.

ethtool -K eth0 tso off gro off gso off ufo off
Matthew Ife
sumber
Ia mengembalikan: Tidak dapat mengubah udp-fragmentation-offload
user134969
Lakukan hal yang sama tetapi hilangkan 'ufo off'
Matthew Ife
1
Hal lain yang cukup bodoh untuk dicari yang dapat menyebabkan pemotongan paket adalah masalah MTU (frame jumbo sedang tidak seharusnya) atau penjepitan MSS diperlukan melalui TCP jika Anda mengirim data ke terowongan.
Matthew Ife
3

Ada beberapa keanehan dengan OpenSSL dan multithreading. MPM apa yang Anda gunakan? Jika ini terkait multithreading, "prefork" harus aman sementara "pekerja" dan "acara" mungkin terpengaruh.

Jika profil beban Anda memungkinkan, Anda dapat mencoba beralih ke prefork dan melihat apakah masalah berlanjut.

Andreas Rogge
sumber
jadi setidaknya multithreading dikesampingkan :)
Andreas Rogge
0

Pertama-tama pastikan chrome diperbarui. Versi yang lebih lama memberikan masalah dengan cipher tertentu. Punya masalah dengan chromium sendiri dengan situs umum seperti amazon, dll.

Kedua, saran untuk melarang protokol dalam "daftar sandi" yang Anda ikuti adalah ide yang sangat buruk karena tidak akan melarang protokol, itu akan melarang sebagian besar sandi termasuk yang bekerja "sejak" SSLv3 (tetapi tidak berarti Anda mengaktifkan SSL3 jika Anda mengizinkan cipher SSLv3), gunakan daftar yang lebih umum yang disediakan oleh Mozilla SSL config generator untuk kompatibilitas (perhatikan SSLv2 tidak ada lagi atau didukung di httpd atau openssl jadi tidak ada alasan untuk melarangnya secara eksplisit lagi) dan mungkin kombinasi Anda sebelumnya terlalu ketat) , coba yang ini:

SSLProtocol             all -SSLv3
SSLCipherSuite          ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

Jika Anda masih memiliki masalah, aktifkan debugging untuk SSL dan lihat apa yang dikatakan httpd (hanya kirim 1 atau dua percobaan dan nonaktifkan pencatatan ini, ini terlalu berisik):

LogLevel ssl:trace3

Sidenotes: Anda juga dapat melanjutkan dan menghapus SSLCertificateChainFile karena arahan itu sudah tidak berlaku lagi di 2.4. Anda dapat menambahkan rantai SSLCertificateFile dan mengurutkan semua sertifikat dari daun ke root, atau bahkan mengubah SSLCertificateChainFile ke SSLCACertificateFile (meskipun yang ini terutama digunakan untuk autentikasi SSL).

Anda juga harus menambahkan (jika belum) menambahkan:

SSLRandomSeed startup file:/dev/urandom 2048
SSLRandomSeed connect file:/dev/urandom 2048
SSLSessionCache shmcb:/path/to/log/ssl_gcache_data(512000)

Sunting: Mengikuti percakapan kami, mari kita periksa instalasi openssl dan / atau apakah itu versi yang sama dengan yang digunakan httpd Anda:

Keluarkan perintah ini dan mari kita lihat apa yang dikatakannya: openssl ciphers -v 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS'

Juga untuk memastikan versi openssl adalah yang benar jalankan ini:

openssl version
ezra-s
sumber
Tidak, tidak menyelesaikannya - periksa edit saya, saya diposting log ketika menggunakan ssl: trace3 ...
user134969
Apakah openssl versi pra-kompilasi atau dikompilasi secara manual?
ezra-s
@ user134969 Saya menambahkan perintah sehingga Anda dapat melihat apakah Anda mendapatkan sandi atau cukup sandi dari stok Anda openssl jika ada masalah dengan itu.
ezra-s