PHP & SSL for secure cookies

[ast3r3x]

I'm trying to implement the protocol used at
http://www.cse.msu.edu/~alexliu/publ...kie/cookie.pdf to
create cookies that can't be forged. I got everything working, except
I have run into one problem:

I don't know how to get the session key used for the encryption. I'm
completely new to SSL and I just installed it on my server, and got it
all set up that it works using http://mydomain.com. So that said, to
my understanding, using public/private key encryption, the server and
client negotiate a key to encrypt data with from that point on, and
that this doesn't change for a client, but it unique for every client.

It seems like that cookie protocol requires that you get that session
key and store it in the cookie to verify that the cookie hasn't been
stolen.

I guess my question is really that I just want to make sure I am
understanding what they mean by session key properly, and how you
would get it. I figured I should have access to it since I am the
server.

-Dustin

[shimmyshack]

On May 23, 9:37 pm, [e-mail] wrote:

I'm trying to implement the protocol used athttp://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdfto
create cookies that can't be forged. I got everything working, except
I have run into one problem:

I don't know how to get the session key used for the encryption. I'm
completely new to SSL and I just installed it on my server, and got it
all set up that it works usinghttp://mydomain.com. So that said, to
my understanding, using public/private key encryption, the server and
client negotiate a key to encrypt data with from that point on, and
that this doesn't change for a client, but it unique for every client.

It seems like that cookie protocol requires that you get that session
key and store it in the cookie to verify that the cookie hasn't been
stolen.

I guess my question is really that I just want to make sure I am
understanding what they mean by session key properly, and how you
would get it. I figured I should have access to it since I am the
server.

-Dustin

it's not the SSL symmetric key, its the php session key, the PHPSESSID

[ast3r3x]

I guess I don't really understand then. I was under the impression
that it was the symmetric key because of section 2.3 in the article.
------------QUOTE------------
Fu's cookie protocol is vulnerable to replay attacks, which could be
launched in the following two steps. The first step is to steal a
cookie that a server issued to another client. An attacker may have
several ways to steal a cookie from someone else. For example, if a
client stores a cookie in his hard disk, an attacker may steal it
using Tro jans, worms, or viruses. An attacker may steal a cookie by
launching a Denning-Sacco Attack [3]. In such an attack, an attacker
first collects a large number of messages that are encrypted by the
same SSL session key, and then obtains the SSL session key using
various methods. In the second step of a replay attack, the attacker
initiates an SSL connection with the server and replays a stolen
cookie that has not yet expired. Consequently, the server incorrectly
authenticates the attacker as the spoofed client, and allows the
attacker to access the spoofed client's account.

To counter replay attacks, we propose to add the SSL session key into
the keyed hash message authentication code of a cookie, i.e., to use
HMAC(username|expiration name|data|session key, sk) as the keyed-hash
message authentication code of each cookie. Therefore, a cookie
becomes session specific. Even if an attacker steals a cookie, he
cannot successfully replay it since the session key is known only to a
legitimate client and the server that creates the cookie.
------------QUOTE------------

What I don't understand is how using the PHPSESSID would make it
anymore secure. You could still replay the cookies if you had physical
access to them, which I thought was what using the session key was
trying to prevent.

[shimmyshack]

On May 24, 11:44 am, [e-mail] wrote:

I guess I don't really understand then. I was under the impression
that it was the symmetric key because of section 2.3 in the article.
------------QUOTE------------
Fu's cookie protocol is vulnerable to replay attacks, which could be
launched in the following two steps. The first step is to steal a
cookie that a server issued to another client. An attacker may have
several ways to steal a cookie from someone else. For example, if a
client stores a cookie in his hard disk, an attacker may steal it
using Tro jans, worms, or viruses. An attacker may steal a cookie by
launching a Denning-Sacco Attack [3]. In such an attack, an attacker
first collects a large number of messages that are encrypted by the
same SSL session key, and then obtains the SSL session key using
various methods. In the second step of a replay attack, the attacker
initiates an SSL connection with the server and replays a stolen
cookie that has not yet expired. Consequently, the server incorrectly
authenticates the attacker as the spoofed client, and allows the
attacker to access the spoofed client's account.

To counter replay attacks, we propose to add the SSL session key into
the keyed hash message authentication code of a cookie, i.e., to use
HMAC(username|expiration name|data|session key, sk) as the keyed-hash
message authentication code of each cookie. Therefore, a cookie
becomes session specific. Even if an attacker steals a cookie, he
cannot successfully replay it since the session key is known only to a
legitimate client and the server that creates the cookie.
------------QUOTE------------

What I don't understand is how using the PHPSESSID would make it
anymore secure. You could still replay the cookies if you had physical
access to them, which I thought was what using the session key was
trying to prevent.

no no you are right, sorry, I just read that, I will read the pdf
later
using this method would make it more secure, it begs the question why
include the session key rather than just a bit of it, and also how
does php get hold of this key as apache deals with the encryption of
the session, but as I say, Ill have to read it later, sorry to have
come back so quickly with a rubbish reply!