Requests: OpenSSL.SSL.Error: [('SSL routines', 'SSL3_GET_RECORD', 'decryption failed or bad record mac')]

Terima kasih untuk ini!

Ya, ini sebenarnya bukan bug permintaan, seperti yang disoroti pertanyaan SO: ini adalah bug Debian atau OpenSSL.

Dengan itu, solusi yang mungkin adalah perpanjangan dari adaptor transportasi yang ditunjukkan di blog saya, di sini: https://lukasa.co.uk/2013/01/Choosing_SSL_Version_In_Requests/

Ini adalah masalah nyata dan saya tidak memiliki konfirmasi bahwa solusinya berhasil. Yang lebih aneh lagi adalah skrip otomatisasi saya yang digunakan untuk meminta server setiap jam untuk beberapa ratus permintaan mulai gagal tiba-tiba, bahkan tanpa saya mengubah apa pun di mesin. Saya kira mereka mungkin telah mengubah konfigurasi server web.

Namun, masalah masih terjadi pada distro terbaru Ubuntu, dengan semua patch dan versi terakhir OpenSSL berumur satu tahun. Kita perlu menerapkan solusi untuk ini.

Juga, saya mencoba solusi yang ditentukan di forum OpenSSL tetapi tidak berhasil, saya akan mencoba pendekatan Anda dan melihat.

Saya setuju bahwa itu masalah nyata. Saya tidak selalu setuju bahwa Permintaan memerlukan solusi untuk setiap bug di salah satu dependensi kami.

Yang tidak jelas bagi saya saat ini adalah seberapa parah bug ini, seberapa luas penyebarannya, dan betapa mudahnya untuk mengatasinya. Juga tidak mudah bagi saya untuk menemukan hal-hal itu hari ini: Saya sedang menghadiri konferensi dan tidak akan punya waktu di dekat laptop. Akan berguna jika @sigmavirus24 bisa melihatnya: kalau tidak, saya harus menggalinya besok.

Hal utama yang perlu diketahui adalah bahwa OpenSSL memiliki bug lain di masa lalu yang belum kami atasi dalam kode inti Permintaan. Terutama, 0.9.8f (saya pikir) yang dikirimkan pada OS X 10.8 memiliki bug serupa di dalamnya yang belum pernah kami tangani.

Kami tidak diharuskan untuk memperbaiki setiap bug di semua dependensi kami, terutama yang implisit. Kami _mungkin_ memperbaiki yang ini, tapi saya belum tahu.

Perhatikan bahwa solusi lain adalah menggunakan versi OpenSSL yang berbeda. Hanya mengatakan.

Solusi Anda tidak berhasil kali ini, saya mencobanya dan kesalahan yang sama. Dan mengenai penggunaan openssl baru, itu tidak mudah sama sekali openssl sangat terikat dengan sistem dan saya membayangkan menginstal yang lain hanya akan membawa lebih banyak masalah.

Jika kita memiliki solusi kerja, itu akan baik-baik saja, saya tidak keberatan menerapkan tambalan ke skrip ini, tetapi itu tidak berhasil. Saya mencoba dengan ssl_version=ssl.PROTOCOL_TLSv1

... Saya mencoba sekarang untuk membangun kasus uji minimal.

Ups, sepertinya itu ikan haring merah, tidak ada hubungannya dengan ini. Sebaliknya tampaknya terkait dengan multiprocessing. Saya menggunakan multiprocessing untuk melakukan permintaan pada 10 utas, untuk mempercepat proses. Ini bekerja dengan baik selama berminggu-minggu tetapi tiba-tiba berhenti bekerja beberapa hari yang lalu ... dengan kesalahan ini.

Seperti apa kode multiprosesor Anda? Jika Anda membagikan objek Session di seluruh proses, hal buruk akan terjadi. =)

Saya tidak membagikan sesi apa pun, sebenarnya saya memanggil fungsi pada setiap utas, melewati parameter dan di dalam fungsi ini saya memiliki kode saya yang membuat sesi, melakukan 2-3 permintaan dan kembali. Aku tahu, aneh.

Itu sangat aneh. Apakah itu mudah direproduksi?

@ssbarnea bisakah Anda setidaknya membagikan URL sehingga kami dapat mencoba mereproduksinya? Sejauh ini saya pikir kami memiliki informasi yang hampir cukup, kami hanya perlu URL atau karakteristik server untuk mereproduksinya:

• Multiprocessing menggunakan _10 utas_
• Fungsi yang membuat Sesi dan membuat lebih dari satu permintaan (sepertinya ke server yang sama) dengannya.

Mulai menjalankan ini juga https://github.com/edx/dyno-slayer

Masalah dimulai saat mengubah:

DEFAULT_MIN_TIMING_WINDOW = 60
DEFAULT_MAX_TIMING_WINDOW = 120

ke:

DEFAULT_MIN_TIMING_WINDOW = 20
DEFAULT_MAX_TIMING_WINDOW = 30

@crizCraig Saya tidak terbiasa dengan proyek itu. Apa pentingnya nilai-nilai itu? Apakah mereka:

• Nilai file konfigurasi?
• Nilai lingkungan?
• Lainnya?

Maaf, mereka hanya menentukan lama waktu untuk mengambil sampel log heroku melalui API mereka. Seluruh program adalah file ini:

https://github.com/edx/dyno-slayer/blob/master/scripts/slayer.py

Kami membutuhkan diagnostik yang jauh lebih baik daripada yang saya khawatirkan. =) Bisakah Anda memberi kami traceback, misalnya?

Saya ingin tahu apakah seseorang yang bekerja @heroku dapat membantu kami. Mereka mungkin memiliki beberapa wawasan. @catsby dapatkah Anda memberi kami beberapa info tentang konfigurasi SSL pada kotak Heroku default? Bisakah Anda mengarahkan kami pada seseorang yang bisa?

@crizCraig Ping. =)

Saya mengalami masalah ini di Windows 7 dengan Python 2.7.9 x32

SSLError: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:581)

@zvodd Sudahkah Anda mencoba memaksa negosiasi SSL pada versi yang berbeda, sesuai artikel ini ?

Ditutup karena tidak aktif.

Mengalami masalah ini menggunakan multiprocessing. Belum bisa memperbaikinya.

@maxcountryman dapatkah Anda memberikan detail yang kami minta?

@ sigmavirus24 yah, saya tidak menggunakan Heroku. Detail apa lagi yang Anda inginkan?

@maxcountryman

• Versi python dan openssl Anda
• Anda sistem operasi dan versi
• Cuplikan kode pemecah minimal
• Jika memungkinkan, URL publik yang memicu bug (bersama dengan cuplikan kode yang disebutkan)

Hai @Lukasa @sigmavirus24 @t-8ch ,
Apakah artikel Anda (https://lukasa.co.uk/2013/01/Choosing_SSL_Version_In_Requests/) kompatibel dengan Python 3? Benarkah masalah saat ini akan diselesaikan dengan memperbarui python ke versi 2.7.9?

@ulandj Artikel harus kompatibel dengan Python 3. Memutakhirkan ke Python 2.7.9 akan menyelesaikan banyak masalah.

@Lukasa yaitu setelah memutakhirkan ke Python 2.7.9 Saya tidak perlu menggunakan adaptor Anda di artikel, kan? Dan

import requests
conn = requests.Session()
conn.put(url, data=body, headers=headers)
conn.delete(url, data=body, headers=headers)

akan bekerja dengan hitungan multiproses?

Jika Anda mengalami masalah ini dengan multiprocessing, saya tidak pernah diberikan skenario repro untuk itu, jadi saya tidak benar-benar tahu apa yang terjadi. Jika Anda dapat menunjukkan masalahnya dengan sedikit kode contoh, saya ingin melihatnya.

nah, pertama kita upgrade ke python 2.7.9 dan akan coba dijalankan dengan multiprocessing. jika kesalahan ini muncul lagi, saya akan memberi tahu Anda. Terima kasih.

@Lukasa pelanggan kami mengatakan bahwa mereka memiliki kesalahan berikut:

Traceback (most recent call last): 
File "/opt/SketchSync/WorkersApp.py", line 230, in run self.producer.release_job(self.worker_id, payload, done) 
File "/opt/SketchSync/SketchSyncProducer.py", line 88, in release_job self.queue.delete_job(payload) 
File "/opt/SketchSync/SketchSyncProducer.py", line 177, in delete_job self.queue.delete(mid) 
File "/usr/local/lib/python2.7/site-packages/iron_mq.py", line 58, in delete result = self.client.delete(url) 
File "/usr/local/lib/python2.7/site-packages/iron_core.py", line 233, in delete retry=retry, body=body) 
File "/usr/local/lib/python2.7/site-packages/iron_core.py", line 152, in request r = self._doRequest(url, method, body, headers) 
File "/usr/local/lib/python2.7/site-packages/iron_core.py", line 117, in _doRequest r = self.conn.delete(url, data=body, headers=headers) 
File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 527, in delete return self.request('DELETE', url, **kwargs) 
File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 456, in request resp = self.send(prep, **send_kwargs) 
File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 559, in send r = adapter.send(request, **kwargs) 
File "/usr/local/lib/python2.7/site-packages/requests/adapters.py", line 382, in send raise SSLError(e, request=request) 
SSLError: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1750) 

Apakah itu mengatakan tentang sesuatu?

Menggunakan:
ular piton (2.7.9)
permintaan (2.3.0)

@ulandj terdengar seperti Anda mengalami http://stackoverflow.com/a/3724938/1953283

@sigmavirus24
Anda berpikir bahwa jika saya memindahkan baris kode ini (dari konstruktor kelas) - https://github.com/iron-io/iron_core_python/blob/master/iron_core.py#L162 di sini - https://github.com/ iron-io/iron_core_python/blob/master/iron_core.py#L188 , maka itu akan berfungsi tanpa kesalahan?

@ulandj fwiw kode yang rusak dalam aplikasi saya melibatkan pembungkus IronIO yang sama.

@ulandj Saya telah membuat perubahan yang Anda sarankan dan sejauh ini tampaknya berfungsi dengan baik di mesin pengembangan lokal saya. Saya harus dapat meluncurkan ini ke pementasan segera di mana kesalahan lebih umum.

@ulandj meluncurkan perubahan di atas ke staging dan sejak itu berjalan lancar. Saya ragu mereka akan digabungkan ke hulu karena Anda benar-benar kehilangan manfaat dari sesi tetapi bagaimanapun juga tampaknya itu memperbaikinya.

@maxcountryman terima kasih,
Kami menawarkan pelanggan kami untuk menginstal iron_core dari cabang ulan-multiprocessing-sslerror . Kami akan mengamatinya. Semoga langkah "permintaan" akan membantu menyelesaikan kesalahan ssl dalam multiprosesor.

@Lukasa deskripsi repro sederhana:

1. Buat sesi dalam proses master
2. Buat beberapa permintaan ke situs berkemampuan SSL
3. Mulai 2 proses multiproses
4. Yang pertama, buat beberapa permintaan lagi ke situs berkemampuan SSL yang sama (jadi penyatuan koneksi dimulai)
5. Yang kedua, tunggu sebentar, lalu buat permintaan ke situs berkemampuan SSL yang sama

Saya tidak dapat memposting skrip saya yang mengenai ini, tetapi saya akan melihat apakah saya dapat membuat skrip sederhana yang mereproduksi ini dengan httpbin.

Mengapa ini terjadi: Dua anak proses berbagi status SSL pada awalnya, dan menggunakan soket yang sama untuk komunikasi, tetapi begitu salah satu dari mereka membuat permintaan, status menjadi tidak sinkron, jadi ketika yang lain mencoba menggunakannya, dekripsi SSL gagal .

Beberapa kemungkinan perbaikan:

• Buang koneksi SSL dari kumpulan koneksi setelah membuka sesi dan tutup objek soket yang terkait
  
  
  
  • Ini bagus karena menutup objek soket hanya menutup deskriptor file proses itu; koneksi yang mendasarinya tidak akan ditutup sampai semua deskriptor file yang menunjuk ke sana ditutup
  
  
  • Lakukan pada unpickling alih-alih mencegah koneksi membuatnya menjadi acar sehingga Anda dapat membersihkan deskriptor file dalam proses anak
  
  
• Buang seluruh kumpulan koneksi saat unpickling
  
  
  
  • Mungkin ide yang terbaik, karena hal-hal mungkin akan rusak
  
  
• Peringatkan/ledakan saat membuka sesi yang memiliki SSL/koneksi apa pun di kumpulan koneksinya

Skrip reproduksi:

#!/usr/bin/env python3.4

import multiprocessing
import requests
import signal
import sys

session = None
stop = None

def sub_1():
    signal.signal(signal.SIGINT, signal.SIG_IGN)
    while not stop.wait(2):
        session.get('https://httpbin.org/ip')

def sub_2():
    signal.signal(signal.SIGINT, signal.SIG_IGN)
    while not stop.wait(20):
        session.get('https://httpbin.org/ip')

if __name__ == '__main__':
    session = requests.Session()
    session.get('https://httpbin.org/ip')
    stop = multiprocessing.Event()
    sub_1_process = multiprocessing.Process(target=sub_1)
    sub_1_process.start()
    sub_2_process = multiprocessing.Process(target=sub_2)
    sub_2_process.start()
    while True:
        try:
            sub_1_process.join()
            sub_2_process.join()
            sys.exit(0)
        except (KeyboardInterrupt, SystemExit):
            if not stop.is_set():
                stop.set()
            else:
                raise

Hasil traceback setelah kira-kira 20 detik:

Process Process-2:
Traceback (most recent call last):
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 376, in _make_request
    httplib_response = conn.getresponse(buffering=True)
TypeError: getresponse() got an unexpected keyword argument 'buffering'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 559, in urlopen
    body=body, headers=headers)
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 378, in _make_request
    httplib_response = conn.getresponse()
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/http/client.py", line 1227, in getresponse
    response.begin()
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/http/client.py", line 386, in begin
    version, status, reason = self._read_status()
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/http/client.py", line 348, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/socket.py", line 378, in readinto
    return self._sock.recv_into(b)
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/ssl.py", line 748, in recv_into
    return self.read(nbytes, buffer)
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/ssl.py", line 620, in read
    v = self._sslobj.read(len, buffer)
ssl.SSLError: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1748)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/adapters.py", line 376, in send
    timeout=timeout
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 588, in urlopen
    raise SSLError(e)
requests.packages.urllib3.exceptions.SSLError: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1748)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/multiprocessing/process.py", line 254, in _bootstrap
    self.run()
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "test.py", line 19, in sub_2
    session.get('https://httpbin.org/ip')
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/sessions.py", line 480, in get
    return self.request('GET', url, **kwargs)
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/sessions.py", line 468, in request
    resp = self.send(prep, **send_kwargs)
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/sessions.py", line 576, in send
    r = adapter.send(request, **kwargs)
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/adapters.py", line 447, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1748)

Saya melakukan skrip reproduksi di 3.4, tetapi mungkin masalah yang sama di setiap versi yang didukung oleh permintaan dan multiprosesor. Skrip ini pada dasarnya adalah apa yang dilakukan kode saya, kecuali menunjuk ke httpbin alih-alih apa yang sebenarnya saya tekan.

Saya agak bingung dengan diagnosis Anda di sini: Saya rasa itu kurang tepat.

Alasannya adalah kolam koneksi tidak terbawa saat memetik/membongkar. Kami secara eksplisit memanggil init_poolmanager saat unpickling untuk memberi kami kumpulan koneksi baru. Namun, itu untuk menyediakan skrip repro: Saya akan menyelami dan melihat apakah saya dapat menemukan apa yang terjadi.

@Lukasa Saya melakukan MITMing koneksi menggunakan proxy transparan. Hanya 1 koneksi yang pernah dibuat.

Aha, sesi ini tidak menjadi acar sama sekali, karena metode awal default untuk multiprocessing pada sistem Unix adalah fork, yang bergantung pada semantik COW sebagai gantinya. Jika Anda beralih ke metode spawn start (dan memperbaiki skrip untuk melewatkan sesi sebagai parameter), sesi akan diasamkan, yang menghapus kumpulan koneksi.

Yup, pengujian saya baru saja menemukan ini di sini juga. =) Jadi masalah ini hanyalah masalah yang lebih mendasar tentang soket.

Saat Anda melakukan fork, orang tua atau anak harus menutup deskriptor file mereka, karena menggunakan keduanya dari utas yang berbeda sangat buruk. Ini pada dasarnya berarti bahwa Anda tidak boleh berbagi sesi di seluruh proses _sama sekali_, atau Anda harus memastikan bahwa ketika Anda melewatkan sesi ke proses lain, Anda kehilangan sesi tersebut dalam proses asli yang menahannya.

Saya tidak percaya ada banyak yang bisa kita lakukan tentang ini.

Atau bersihkan kumpulan koneksi secara manual dalam proses anak-anak. Untuk memperbaikinya dalam permintaan, Anda memerlukan kait after_fork, yang saya tidak percaya diekspos oleh python (beberapa modul stdlib memiliki kode after-fork yang dipanggil dari kode C setelah fork, tetapi mereka spesial ). Mungkin bagus untuk memiliki fungsi after_fork() pada objek sesi, yang mendokumentasikan bahwa itu harus dipanggil setelah panggilan apa pun ke os.fork(), termasuk saat menggunakan multiprosesor dengan fork sebagai metode awal.

Saya secara eksplisit tidak menyebutkan pendekatan itu karena saya pikir tidak mungkin kita melakukannya dengan bijaksana.

Misalnya, satu hal yang mungkin ingin Anda lakukan adalah mengonfigurasi Sesi pada proses utama dan kemudian meneruskannya ke anak: dalam contoh itu, Anda _ingin_ contoh anak untuk mempertahankan koneksinya dan orang tua kehilangannya.

Saya pikir ini adalah sesuatu yang pengguna perlu putuskan untuk dilakukan: jika Anda berbagi sesi di seluruh proses sama sekali (yang saya sarankan untuk tidak dilakukan jika memungkinkan), Anda perlu menelepon tentang apa yang harus dilakukan ketika Anda garpu.

Nah, Anda bisa menyebutkan dalam dokumentasi kasus di mana Anda ingin memanggil after_fork(), dan kapan Anda tidak mau. Dalam kasus saya, yang saya pedulikan hanyalah menyetel beberapa tajuk tertentu, tetapi saya memerlukan beberapa data dari API sebelum saya dapat memulai anak-anak (batas waktu untuk panggilan stop.wait() pada anak-anak sebenarnya berasal dari API, untuk contoh), dan sepertinya boros bagi saya untuk mengatur sesi 3 kali dengan kode pengaturan yang sama persis.

Saya kira satu opsi dalam kasus saya adalah mengirimkan PreparedRequests ke proses utama untuk mengirim kemudian mengirimkan Respons kembali melalui antrian. Atau saya bisa kembali ke threading, karena beban kerja pemrosesan saya yang sebenarnya cukup ringan; yang ini tampaknya lebih mudah dalam kasus saya (tetapi mungkin bukan solusi terbaik untuk orang lain).

@dwfreed Biaya penyiapan sesi sangat rendah: sesi tidak perlu melakukan banyak hal untuk menyiapkan. Secara khusus, mengingat Anda harus menunggu API kembali sebelum menyiapkan anak-anak, saya pikir Anda mungkin bisa membungkus pengaturan sebagai bagian dari fungsi yang Anda panggil dalam proses latar belakang dan pada dasarnya menjadi tidak terlalu mencolok.

Inilah mengapa saya gugup menulis dokumentasi untuk ini: Saya tidak berpikir kami dapat memberikan lebih dari saran umum yang akan bermuara pada: jangan bagikan Sesi di seluruh proses, pertimbangkan baik-baik apakah Anda ingin membagikan Sesi di seluruh utas, saat menulis kode bersamaan cobalah untuk mengadopsi pola desain bersamaan yang baik.

Apa pun lebih dari itu terlalu membatasi sejauh saran berjalan.

Saya tahu ini adalah permintaan lama dan tidak akan diselesaikan oleh proyek permintaan, tetapi ketika Anda buntu googling tentang masalah ini dengan kode python, Anda selalu kembali ke masalah ini.

Kebetulan dalam kasus saya itu terjadi dengan "boto" (yang menggunakan "permintaan" di bawah tenda). Kebetulan boto mencoba melakukan penyatuan koneksi pintar yang rusak parah saat melakukan forking. Penyatuan koneksi pintar ini dinonaktifkan saat Anda menjalankan Google App Engine. Boto mendeteksi jika Anda menggunakan App Engine dengan adanya 3 variabel lingkungan berikut. Menyetelnya membuat bug hilang seluruhnya: USER_IS_ADMIN=fake CURRENT_VERSION_ID=fake APPLICATION_ID=fake .

Sekali lagi, maafkan spam di sini, saya harap ini akan bermanfaat bagi seseorang :-) Dan terus bekerja dengan baik dengan permintaan!!!

@jbbarth kamu adalah pahlawanku. kesalahan ini baru saja mulai terjadi pada saya di boto saat saya menambahkan multiprocessing. solusi Anda tidak berhasil untuk saya (belum). Versi permintaan mana yang Anda gunakan?

@fuzzyami saya pikir itu 2.10, bersama dengan boto 2.38 atau 2.39. Heuristik di boto mungkin telah berubah, saya sarankan Anda melihat mekanisme penyatuan koneksi mereka atau memahami variabel lingkungan yang saya maksud. Semoga beruntung! :)

Saya memiliki masalah yang sama dengan

boto (2.47.0)
boto3 (1.3.1)
botocore (1.5.79)
requests (2.18.1)

@jbbarth Terima kasih banyak untuk solusinya.