Hello, all
I've tried to use stunnel with keys on the hardware device, supported by OpenSSL engine and encountered some minor problems:
1. Under Unix systems stunnel doesn't provide UI_METHOD for ENGINE_load_private_key. It passes NULL there and engine complains that no user interface provided.
On Unix in many cases default UI_METHOD provided by OpenSSL would do
So, replacing line 302 in the ctx.c (line number are given for release 4.33)
from
uim=NULL ;
to
uim=UI_OpenSSL();
would significanly improve stunnel functionality.
2. OpenSSL UI objects have two methods to pass arbitraty pointers along
1. generic ex_data based macros UI_set_app_data/UI_get_app_data 2. UI-specific UI_add_user_data/UI_get0_user_data
Unfortunately app-specific pointer is set inside engine and retrieved inside a callback, which belongs to application. So author of an engine and author of an application should somehow agree on which metod to use.
All engines shipped with OpenSSL (ones which do provide load_private_key method) use UI_add_user_data to pass data to the callback.
stunnel's pin_cb (for Win32 version of stunnel in the gui.c) uses UI_get_app_data to retrieve ui_data. I wonder what engine was used when this code was developed and debugged.
And it does no check if any meaningful pointer is obtained.
I suggest to add following code after line 602 in gui.c:
/* if set_app_Data haven't-return anything */ if (!ui_data) ui_data=UI_get0_user_data(ui); /* if still no avail */ if (!ui_data) { s_log(LOG_ERR,"Engine haven't passed our callback data to callback. Sorry!"); return 0; }
Or instead of complaining we can use some structure, local to function pin_cb as fallback UI_DATA - just as password buffer, and check if ui_data->section is not NULL before reading ui_data->section->key in the pass_proc (line 543 of gui.c)
Thus it would work even with really broken engines which do not pass userdata from ENGINE_load_private_key to UI callbacks at all.
----- End forwarded message -----