On 01/10/2012 04:52 AM, Norm Green wrote:
Hi,
I am testing my application with the 1.0.1 beta and noticed the errors generated are not
very friendly when SRP credentials are incorrect. The problem is that the error codes
returned in no way indicate that the problem is incorrect credentials. Instead I see
errors about "bad record mac" (see below).
two things:
- your server code may choose to react with a
o "unknown_psk_identity" (115) - this alert MAY be sent by a server
that receives an unknown user name. This alert is always fatal.
SeeSection 2.5.1.3 <http://tools.ietf.org/html/rfc5054#section-2.5.1.3>
for details.
this can be done in the callback if one chooses so.
- when a user provides a bad password, there is no common secret,
there is only one possible error:
"something was wrong during the handshake"
Everything works just fine when the correct credentials are used. What I need
a way to discern if incorrect credentials were supplied, or there is some other
error. As it stands now, I would have to assume that the credentials are wrong
whenever SSL_connect() or SSL_accept() fail, which seems like a poor assumption.
You can only assume that either a wrong password is given or
some network problem has occured.
You cannot determine whether you are talking to the right partner
without a successful handshake.
I'm still fairly new to SSL and SRP and am grateful for any and all help.
does that help?
btw: if your server needs non blocking behaviour (even if no),
and you need time to lookup a credential (a verifier) in a database,
you can indicate in your callback to interrupt the accept call
(in blocking and non blocking mode) and repeat the accept as
soon as the data are there.
Norm Green
VMware, Inc.
Peter Sylvester
