cookies and internet

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

cookies and internet

taesch
if the erlang model would be used over the internet, how would the security
model do with that ?

is the cookie good enough ?

how do u pass it first hand ?

generally, have any study made in this area ? mail postst ? paper ?

thanks
Luc

------------------------------------------------------------
 Get your FREE web-based e-mail and newsgroup access at:
                http://MailAndNews.com

 Create a new mailbox, or access your existing IMAP4 or
 POP3 mailbox from anywhere with just a web browser.
------------------------------------------------------------



Reply | Threaded
Open this post in threaded view
|

cookies and internet

Lon Willett
At 11:23 12/07/01, taesch wrote:
>if the erlang model would be used over the internet, how would the security
>model do with that ?

Not very well.  The current Erlang/OTP implementation pretty much assumes
that the transport layer is secure.

>is the cookie good enough ?

Probably not.  It's not really meant to provide anything more than a very
simple authentication method that assumes the underlying transport
mechanism is secure.  And, BTW, the default cookie generation is very
broken.  This probably doesn't matter, since the mechanism isn't meant to
be cryptographically strong anyway.  But if you decide to implement a
mechanism that is, for example one that uses the cookie as a key to encrypt
and MAC the erlang messages, then you will need to be sure that the cookie
is generated using a good crypto (P)RNG.

>how do u pass it first hand ?

Carefully.  ;-)

But really, if I understand what you're asking, then the answer is that, by
design, this is outside the scope of what Erlang/OTP specifies.  And with
the current Erlang/OTP communications model (where the cookie is sent in
the clear anyway), one needn't be too careful with it, but shouldn't be
careless either (e.g. ftp is probably fine for transporting it, but be sure
that the file protection is set appropriately on the systems where it is
stored).

>generally, have any study made in this area ? mail postst ? paper ?

You can check out the Safe Erlang project at
http://www.ericsson.se/cslab/~dan/proj/safeerlang .  This is an ambitious
attempt to add capabilities based access-control and secure communications
to erlang, but I believe that it is still experimental at this time.  I
also seem to recall hearing rumours that someone made the erlang
communications run over SSL, but this might be mistaken.

I've been intending to implement a simple version of cryptographically
secured communications for Erlang/OTP, but haven't found the time.  If
someone else is working on this (or wants to), then I'd be happy to share
my ideas.  There are some subtle problems involved in setting up such a scheme.

I hope this helps.

/Lon



Reply | Threaded
Open this post in threaded view
|

cookies and internet

Tony Rogvall-3
Lon Willett wrote:

> At 11:23 12/07/01, taesch wrote:
>
>
> But really, if I understand what you're asking, then the answer is
> that, by design, this is outside the scope of what Erlang/OTP
> specifies.  And with the current Erlang/OTP communications model
> (where the cookie is sent in the clear anyway), one needn't be too
> careful with it, but shouldn't be careless either (e.g. ftp is
> probably fine for transporting it, but be sure that the file
> protection is set appropriately on the systems where it is stored).

The cookie is not sent in the clear!
Not since open source erlang anyway. The cookie may be generated or
pasted in
by hand either in the .erlang.cookie file or from the command line
-setcookie <cookie>

When a node connectes with another node, a challenge is sent from the
node connected.
Then it expects the challenge+cookie md5 sum as return (i.e not in the
clear).
After that the connection is ready to be hijacked ;-)

>
>> generally, have any study made in this area ? mail postst ? paper ?
>
>
> You can check out the Safe Erlang project at
> http://www.ericsson.se/cslab/~dan/proj/safeerlang .  This is an
> ambitious attempt to add capabilities based access-control and secure
> communications to erlang, but I believe that it is still experimental
> at this time.  I also seem to recall hearing rumours that someone made
> the erlang communications run over SSL, but this might be mistaken.

I hope we soon can run distribution over SSL.

>
> I've been intending to implement a simple version of cryptographically
> secured communications for Erlang/OTP, but haven't found the time.  If
> someone else is working on this (or wants to), then I'd be happy to
> share my ideas.  There are some subtle problems involved in setting up
> such a scheme.
>
> I hope this helps.

I think SSL is the simple way forward.

/Tony






Reply | Threaded
Open this post in threaded view
|

cookies and internet

Lon Willett
At 19:04 12/07/01, tony wrote:

>The cookie is not sent in the clear!
>Not since open source erlang anyway. The cookie may be generated or pasted in
>by hand either in the .erlang.cookie file or from the command line
>-setcookie <cookie>
>
>When a node connectes with another node, a challenge is sent from the node
>connected.
>Then it expects the challenge+cookie md5 sum as return (i.e not in the clear).
>After that the connection is ready to be hijacked ;-)

Oops.  I should have looked more closely.  That's good to hear
(theoretically, one ought to use a proper MAC, but in this case, a keyed
hash should serve well enough).  Is the cookie generation also fixed?  Last
I saw, it was pretty ridiculously weak (although one could always generate
it oneself, outside of erlang), but again, I didn't delve into the details,
and certainly not recently.

>I hope we soon can run distribution over SSL.

Is there such a version of erlang available?  I'd be interested.

>>I've been intending to implement a simple version of cryptographically
>>secured communications for Erlang/OTP, but haven't found the time.  If
>>someone else is working on this (or wants to), then I'd be happy to share
>>my ideas.  There are some subtle problems involved in setting up such a scheme.
>>
>>I hope this helps.
>
>I think SSL is the simple way forward.

Maybe.  The SSL code is widely available, and the protocol is well
analysed.  These are definite pluses.  The minuses are that SSL is
horrendously complex (and early versions of the protocol were flawed, for
that very reason), and it is easy to misconfigure, and it usually requires
an expensive setup (perhaps overly expensive for something like erlang,
where a node coming up may want to make connections to a large number of
other nodes at the same time).  Note that since erlang nodes only talk to
other compatible erlang nodes via their distribution mechanism, there is no
requirement that the distribution mechanism be "standards compliant"; thus
it would be reasonable to use a simpler protocol.

>/Tony

Thanks, and sorry about the misinformation,

/Lon