[stunnel-users] stunnel and loading keys from hw devices

Victor Wagner vitus at cryptocom.ru
Fri Jul 9 20:09:53 CEST 2010

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


  uim=NULL ;



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

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) 
  /* 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 -----

More information about the stunnel-users mailing list