“SSL error parse tlsext” pada komit besar ke SVN via Apache, Gentoo


10

Ini hanya terjadi pada komit besar (menghasilkan komit yang gagal):

Bagian yang jelas dari konfigurasi host virtual di Apache

   <LimitExcept DAPATKAN LAPORAN OPSI PROPFIND>
      Membutuhkan pengguna yang valid
   </LimitExcept>
   Dav svn
   SVNPath / home / svn /

Hasil komitmen:

Mengirim data file .............................. svn: Komit gagal
(detail ikuti):
svn: PUT dari
'/!svn/wrk/48583f7d-0e01-410d-8941-33d2ba3574b4/WAP/.../htdocs/images/rt.gif'::
Negosiasi SSL gagal: Kesalahan SSL: parse tlsext (https: // ...)

Saya menemukan referensi untuk itu di sini: http://code.google.com/p/support/issues/detail?id=1395

menyatakan bahwa OpenSSL harus dikompilasi dengan ekstensi TLS, tetapi dalam kasus saya, itu tidak salah pada awalnya, hanya pada komit besar.

Ada ide? Terima kasih


apakah ada tiket bugtracker apache httpd untuk bug ini?
user28271

Jawaban:


7

Saya belum pernah mengalami masalah ini, tetapi saya menghabiskan waktu mencari di Google dan menemukan bahwa itu mungkin telah diperkenalkan di Apache 2.2.12 atau 13. Disarankan bahwa menurunkan versi ke 2.2.11 dapat memperbaikinya, serta mengatur SSLProtocol - ALL + SSLv2 + SSLv3 di konfigurasi Apache Anda. Tidak ada yang tampak definitif. Semoga berhasil! Semoga Anda menemukan solusinya.

http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393204


Menambahkan SSLProtocol -ALL + SSLv2 + SSLv3 juga berfungsi untuk saya.

Untuk apa nilainya, saya memiliki masalah yang sama dan menambahkan SSLProtocol -ALL + SSLv2 + SSLv3 seperti yang disebutkan di atas memperbaiki masalah ini untuk saya.
Adam Carr

Saya mengalami masalah yang sama ketika mencoba terhubung dari Ruby 1.9.3. Ruby 1.9.2 bukan masalah karena alasan apa pun. Dan kesalahan terjadi segera saat menggunakan sertifikat klien. Mengubah konfigurasi saya dari SSLProtocol all -SSLv2untuk SSLProtocol ALL -SSLv2 -TLSv1memperbaiki masalah bagi saya.
aNoble


5

MEMPERBARUI

Setelah membaca utas http-dev tentang masalah ini, diarsipkan di http://www.gossamer-threads.com/lists/apache/dev/375633 , sepertinya masalah ini disebabkan oleh bug di pustaka OpenSSL sisi klien di berkaitan dengan bagaimana Tiket SSL / ID ditangani, yang menjelaskan mengapa kesalahan tidak terjadi segera, tetapi membutuhkan beberapa detik hingga beberapa menit. Resolusi ini ditentukan pada 2 November, tiga hari sebelum OpenSSL 0.9.8l keluar. Utas tidak secara eksplisit menyatakan jika / ketika perbaikan diterapkan ke OpenSSL, tapi saya pikir itu adalah sesuatu yang bisa kita antisipasi diperbaiki di 0.9.8m, yang saya percaya tercakup oleh entri ini di m-beta changelog:

*) Perbaikan untuk penanganan melanjutkan sesi stateless. Gunakan initial_ctx saat mengeluarkan dan mencoba mendekripsi tiket jika terjadi perubahan selama penanganan nama server. Gunakan ID sesi panjang yang tidak nol ketika mencoba melanjutkan sesi stateless: ini memungkinkan untuk menentukan apakah resume telah terjadi segera setelah menerima server halo (beberapa tempat di OpenSSL mengasumsikan ini secara halus) alih-alih di jabat tangan kemudian.

POST ASLI

Saya mengalami masalah serupa di Apache-2.2.14 di Gentoo. Untuk referensi, inilah bendera USE saya:

[ebuild   R   ] dev-libs/openssl-0.9.8l-r2  USE="zlib -bindist -gmp -kerberos -sse2 -test" 4,082 kB
[ebuild   R   ] www-servers/apache-2.2.14-r1  USE="ssl -debug -doc -ldap (-selinux) -static -suexec -threads" APACHE2_MODULES="actions alias auth_basic auth_digest authn_dbd authn_default authn_file authz_default authz_groupfile authz_host authz_user autoindex dav dav_fs dav_lock dbd deflate dir env expires headers include info log_config logio mime mime_magic negotiation proxy proxy_balancer proxy_connect proxy_http rewrite setenvif status unique_id userdir -asis -authn_alias -authn_anon -authn_dbm -authz_dbm -authz_owner -cache -cern_meta -charset_lite -disk_cache -dumpio -ext_filter -file_cache -filter* -ident -imagemap -log_forensic -mem_cache -proxy_ajp -proxy_ftp -speling -substitute -usertrack* -version -vhost_alias" APACHE2_MPMS="prefork -event -itk -peruser -worker" 5,088 kB
[ebuild   R   ] net-misc/neon-0.29.0  USE="expat nls ssl zlib -doc -gnutls -kerberos -libproxy -pkcs11" LINGUAS="-cs -de -fr -ja -nn -pl -ru -tr -zh_CN" 859 kB
[ebuild   R   ] dev-util/subversion-1.6.6  USE="apache2 bash-completion dso nls perl python ruby webdav-neon -berkdb -ctypes-python -debug -doc -emacs -extras -gnome-keyring -java -sasl -test -vim-syntax -webdav-serf" 5,384 kB

Ini terjadi dengan kombinasi SSLProtocol dengan yang TLSv1disertakan

Jika saya menyesuaikan SSLProtocoluntuk dihapus TLSv1, saya mendapatkan kesalahan baru:

svn: PUT of '/!svn/wrk/0b9f5a96-15aa-11df-ad6a-0f71b873281b/project/trunk/path/btn_Cancel.gif': SSL handshake failed: SSL error: bad decompression (https://svn.mudbugmedia.com)

Ini terjadi kira-kira bersamaan dengan saat saya menemukan kesalahan "parse tlsext".


Memutakhirkan klien SVN saya dari 1,6 menjadi 1,7 memecahkan masalah "parse tlsext" untuk saya, mendukung saran oleh @ gabe-martin-dempesy bahwa "masalah ini disebabkan oleh bug di perpustakaan OpenSSL sisi klien"
Jared Beck

0

Masalah ini paling mungkin karena menggunakan beberapa VirtualHost yang diaktifkan SSL di Apache httpd 2.2.12 - 2.2.14 dan OpenSSL 0.9.8f - 0.9.8l.

Tambalan berikut ini sepertinya memecahkan masalah bagi saya.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.