Since MCOP servers will listen on a TCP port, potentially everybody (if you are on the Internet) may try to connect MCOP services. Thus, it is important to authenticate clients. MCOP uses the md5-auth protocol.
The md5-auth protocol does the following to ensure that only selected (trusted) clients may connect to a server:
It assumes you can give every client a secret cookie.
Every time a client connects, it verifies that this client knows that secret cookie, without actually transferring it (not even in a form that somebody listening to the network traffic could find it out).
To give each client the secret cookie, MCOP will (normally) put it in
the mcop
folder (under
/tmp/mcop-
). Of
course, you can copy it to other computers. However, if you do so, use a
secure transfer mechanism, such as scp (from
ssh).
USER
/secret-cookie
The authentication of clients uses the following steps:
[SERVER] generate a new (random) cookie R
[SERVER] send it to the client
[CLIENT] read the "secret cookie" S from a file
[CLIENT] mangle the cookies R and S to a mangled cookie M using the MD5 algorithm
[CLIENT] send M to the server
[SERVER] verify that mangling R and S gives just the same thing as the cookie M received from the client. If yes, authentication is successful.
This algorithm should be secure, given that
The secret cookies and random cookies are “random enough” and
The MD5 hashing algorithm doesn't allow to find out the “original text”, that is the secret cookie S and the random cookie R (which is known, anyway), from the mangled cookie M.
The MCOP protocol will start every new connection with an authentication process. Basically, it looks like this:
Server sends a ServerHello message, which describes the known authentication protocols.
Client sends a ClientHello message, which includes authentication info.
Server sends an AuthAccept message.
To see that the security actually works, we should look at how messages are processed on unauthenticated connections:
Before the authentication succeeds, the server will not receive other messages from the connection. Instead, if the server for instance expects a “ClientHello” message, and gets an mcopInvocation message, it will drop the connection.
If the client doesn't send a valid MCOP message at all (no MCOP magic in the message header) in the authentication phase, but something else, the connection is dropped.
If the client tries to send a very very large message (> 4096 bytes in the authentication phase, the message size is truncated to 0 bytes, which will cause that it isn't accepted for authentication) This is to prevent unauthenticated clients from sending for example, 100 megabytes of message, which would be received and could cause the server to run out of memory.
If the client sends a corrupt ClientHello message (one, for which demarshalling fails), the connection is dropped.
If the client send nothing at all, then a timeout should occur (to be implemented).
Would you like to comment or contribute an update to this page?
Send feedback to the TDE Development Team