On 12/20/11 14:38, Adriano dos Santos Fernandes wrote: > On 20/12/2011 08:19, Alex Peshkoff wrote: >> On 12/20/11 13:54, Adriano dos Santos Fernandes wrote: >>> On 20/12/2011 06:57, Alex Peshkoff wrote: >>>> connect: client's public key, login and database name => server >>>> accept: server's public key and salt => client >>>> attach: client's proof => server >>>> response: success if client's proof == server's proof >>>> >>>> >>> What I would like to know is that if there is a way to configure the >>> client to know if the server is a trusted one, cause if you only use >>> generated keys you don't prevent man in the middle attacks. >> The power [ sorry for too beautiful words :) ] of SRP is that it DOES >> prevent man in the middle attack even with generated keys. This works >> cause in fact a kind of small key - password's hash - is placed on the >> server in advance. And that hash is used as a part of server's public >> key, returned to client. Correct session secret (and based on it proof) >> can be built from that public key only knowing login, salt (this 2 are >> not a problem certainly) and password, which is supposed to be unknown >> to attacker. If you want more details - http://srp.stanford.edu/ >> >> > I really can't read a security spec and fully understand it, sorry, but > I do not think this scheme prevents what I mean. >
To be completely sure it could be useful to understand mathematics of that protocol, but telling true I did not finish with that task too :( > Suppose someone intercepts client op_connect and acts like a server to > the client. This middle-man then acts like a client to the real server. To do it he must know the password. Therefore SRP protects from such attack. I know it's something strange from the first glance, but from all what I've read in the net about it it's true. Looking at the code to the place where the keys are built also makes me think that SRP is resistant for that kind of attack. > He's then able to intercept the whole connection, but probably can't > reuse the password for future connections. > > That may be inevitable per see, so it's why I think we must have in the > client a way to know (and otherwise prevent) if the connection is really > made with the real (trusted) server. This is AFAIK how browsers shows to > you that you're connected to real (trusted) server, . It's possible for a client to check is the server really correct using SRP. Client sends client's proof to the server, which calculates it in the same way as client does. (Pay attention - session's secret key, one of proof's parameters, is calculated differently on server and client.) If we require server to calculate server's proof, we can send it to client to let it check that this is real server which really knows client's hash. ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
