Hi,

Today I dumped the communication and it looks that we pass the
> akka.remote.secure-cookie in plain-text over the wire. My look at
> AkkaProtocolTransport.scala confirmed that. I understand that this is not
> supposed to be strong authentication but still it is pretty weak one.
>

This is completely true, and it is not meant to be an authentication
solution, its basic purpose is to avoid unrelated actor systems to
accidentally talk to each other. Also please note that Akka remoting and
Clustering assumes a trusted network in the general case, it is not meant
to be exposed to uncontrolled environments (although with TLS and some care
it is possible).


>
> What I am proposing:
>
> 1. Add a configuration key akka.remote.cooke-digest with the name of the
> digest algorithm.
>
> 2. If it is not present - continue using the same logic as now: sending
> plain text over the network and textual comparison for verification. This
> guarantees backward compatibility.
>
> 3. If the cookie-digest key is defined:
>
> - construct standard java.security.MessageDigest with the algorithm that
> is the value of the key
>
> - use the secure-cookie value as a salt and compute a digest over the
> string representation of protocol + system + host + port
>
> - use a textual representation of the digest value as a cookie value that
> goes into HandshakeInfo
>
> - into Associate event processing construct the same text digest
> representation and compare with the received cookie in order to validate.
>
> I am willing to implement the proposed change if you think it will be
> generally useful. It will not change the messaging protocol so I think it
> will be backward compatible. I will also backport it to 2.2 branch.
>
> Do you think the proposed addition make sense? I am open to all kind of
> critique and suggestions.
>

Thank you for your writeup. We are aware of challenge-handshake schemes but
we never meant to use this cookie mechanism as high security solution but
mostly to protect from mistakes (as opposed to malicious strategic
opponent). We do not really plan to change it -- there is way more to gain
by adding advanced authentication features to the SSL/TLS layer -- so if
you would like to contribute, that would be a better target.

-Endre


>
> Thank in advance,
> luben
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: http://akka.io/faq/
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam

-- 
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: http://akka.io/faq/
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to