On 04/04/2012 11:01 AM, Christian Weber wrote:
Dear users and developers,
we just read through some of the code examples for SRP usage.
Concerning the necessary callbacks we wonder why in
s_server.c the verifier parametrization is being delayed.
Within apps/s_server.c we can find the comment:
When the callback is called for a new connection we return
with a negative value. This will provoke the accept etc to return with
an LOOKUP_X509. The main logic of the reinvokes the suspended call
(which would normally occur after a worker has finished) and we
set the user parameters.
There seems to be something missing between 'the' and 'reinvokes',
so we cannot understand what's being meant.
application:
Imagine a server that has a large base of users. When the callback is
invoked, it would start with some asynch ldap call or whaever else
to read a verifier. The callback would return -1, and the SSL_accept
fails with the return code ERROR_LOOKUP_X509 (well, I know, by this
name was the only one available, borrowed by a reciprooque feature
in the client. The application would do some select call on whatever
filedescriptors. As soon as the verifier is available, the application
stores this somewhere, and calls SSL_accept again, which in this
case will cause the callback to return the verifier.
Nothing about srp is documented so far.
The code in apps/server.c is not doing any select loop, it just
calls the SSL_accept twice. This is done to illustrate the
possibilities of the callback. The callback 'pretends' that
the data are not there.
I do not really like to use the verifier file as it is done in the example,
since one needs to restart a server after modifying a user.
May it be a security impact to implement the lookup within the
callback itself (as done in ssl/ssltest.c, based on user's password)
or may there be other error conditions which are covered by
relocating the lookup to init_ssl_connection in apps/s_cerver.c?
As I wrote abone, the while loop to do SSL_accept is not exactly
what you would want to do in a real application.
The simulated logic flow is:
i=SSL_accept(con);
if ( i = 0 SSL_get_error(con,i) == SSL_ERROR_WANT_X509_LOOKUP )
do whatever is necessary to get the verifier, in this case simulated by
srp_callback_parm.user = SRP_VBASE_get_by_user(srp_callback_parm.vb,
srp_callback_parm.login);
since there is nothing async to do in the example.
and then do another
i=SSL_accept(con);
I could have folded out the loop to get out the init_ssl_connection etc.
Any opinions about possible security weakening against implementing
the lookup within the callback?
There may be many ways to store and create a verifier.
One could for example on the fly generate a one time password,
send it as an SMS, store the verifiers in an LDAP.
Therefore the callback allows an application to choose whatever means
it wants to implement, openssl is not charged to read files, make network
requests or whatever.
Peter
TIA
-- Christian Weber
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
