Ada solusi yang diberikan untuk masalah ini di beberapa forum OTN (https://kr.forums.Oracle.com/forums/thread.jspa?messageID=3699989). Tapi, akar penyebab masalahnya tidak dijelaskan. Berikut ini adalah upaya saya untuk menjelaskan akar penyebab masalah.
Driver Oracle JDBC berkomunikasi dengan server Oracle dengan cara yang aman. Driver menggunakan java.security.SecureRandom kelas untuk mengumpulkan entropi untuk mengamankan komunikasi. Kelas ini bergantung pada dukungan platform asli untuk mengumpulkan entropi.
Entropi adalah keacakan yang dikumpulkan/dihasilkan oleh sistem operasi atau aplikasi untuk digunakan dalam kriptografi atau penggunaan lain yang memerlukan data acak. Keacakan ini sering dikumpulkan dari sumber perangkat keras, baik dari suara perangkat keras, data audio, gerakan mouse atau generator keacakan yang disediakan secara khusus. Kernel mengumpulkan entropi dan menyimpannya sebagai kumpulan entropi dan membuat data karakter acak tersedia untuk proses sistem operasi atau aplikasi melalui file khusus /dev/random dan /dev/urandom .
Membaca dari /dev/random menguras kumpulan entropi dengan jumlah bit/byte yang diminta, memberikan tingkat keacakan yang tinggi yang sering diinginkan dalam operasi kriptografi. Dalam kasus, jika kumpulan entropi benar-benar terkuras dan entropi yang memadai tidak tersedia, operasi baca di /dev/random blok sampai entropi tambahan dikumpulkan. Karena itu, aplikasi membaca dari /dev/random dapat memblokir untuk beberapa periode waktu acak.
Berbeda dengan di atas, membaca dari /dev/urandom tidak memblokir. Membaca dari /dev/urandom , juga, menguras kumpulan entropi tetapi ketika kekurangan entropi yang cukup, itu tidak memblokir tetapi menggunakan kembali bit dari data acak yang dibaca sebagian. Ini dikatakan rentan terhadap serangan cryptanalytical. Ini adalah kemungkinan teoretis dan karenanya tidak disarankan untuk membaca dari /dev/urandom untuk mengumpulkan keacakan dalam operasi kriptografi.
java.security.SecureRandom kelas, secara default, membaca dari /dev/random file dan karenanya terkadang memblokir untuk jangka waktu acak. Sekarang, jika operasi baca tidak kembali untuk jangka waktu yang diperlukan, server Oracle menghabiskan waktu klien (driver jdbc, dalam hal ini) dan menghentikan komunikasi dengan menutup soket dari ujungnya. Klien ketika mencoba untuk melanjutkan komunikasi setelah kembali dari panggilan pemblokiran menemukan pengecualian IO. Masalah ini dapat terjadi secara acak pada platform apa pun, terutama, di mana entropi dikumpulkan dari kebisingan perangkat keras.
Seperti yang disarankan di forum OTN, solusi untuk masalah ini adalah mengganti perilaku default java.security.SecureRandom kelas untuk menggunakan pembacaan non-pemblokiran dari /dev/urandom alih-alih pemblokiran, baca dari /dev/random . Ini dapat dilakukan dengan menambahkan properti sistem berikut -Djava.security.egd=file:///dev/urandom ke JVM. Meskipun ini adalah solusi yang baik untuk aplikasi seperti driver JDBC, ini tidak disarankan untuk aplikasi yang melakukan operasi kriptografi inti seperti pembuatan kunci kriptografi.
Solusi lain dapat menggunakan implementasi seeder acak berbeda yang tersedia untuk platform yang tidak bergantung pada kebisingan perangkat keras untuk mengumpulkan entropi. Dengan ini, Anda mungkin masih perlu mengganti perilaku default java.security.SecureRandom .
Meningkatkan batas waktu soket di sisi server Oracle juga bisa menjadi solusi tetapi efek sampingnya harus dinilai dari sudut pandang server sebelum mencoba ini.
