Mixing SSL and Non-SSL Redux

[Rob Mikkelsen]

In my web app (NT 5.38) I have several pages that refresh every minute.  Using SSL (wildcard certificate, client using IE8), the pages stop refreshing after a few minutes.  Unecrypted, the pages refresh indefinitely.  Therefore, I believe a mixed SSL environment will be the best option.

I read with interest this topic:  

http://www.nettalkcentral.com/index.php?option=com_smf&Itemid=36&topic=451.0

and learned that the SSL and non-SSL use two different session queues.  Copying the data between the session queues proved doable but I was surprised that in every test I found that the session ID was the same on both servers.

Two Three questions:

1.  Will the session ID always be the same between the SSL and non-SSL servers?

2.  Is there any form of encryption that is applied by NetTalk to the exchange of the cookie containing the session ID?  My security folks require that every exchange of the session ID must be encrypted.

3.  If the cookie is not encrypted, does anyone have a suggestion of how to encrypt it between the browser and server (outside of sending the page securely) to prevent hacking?  I had considered a reversable encryption using the client's IP address as the key but haven't looking into the best place (probably in the webserver procedure) to resolve that.

As mentioned, SSL appears to break the multiple updates of the pages so I am trying to walk the fine line between security and usability.

Thanks!

Rob

[Bruce]

1. - yes - the session id is stored in a cookie, so as long as you are changing the protocol (HTTP / HTTPS) but not the hostname (www.whatever.com) the session number will be the same.

2. Obviously on SSL it's encrypted like everything else. In non-SSL there's no meaningful way to encrypt data with JavaScript (because JavaScript is uncompiled). On the other hand I've never heard of a SessionId needing encryption - if there are any papers on that please ask them for references so I can read up on it.

3. Not sure what hacking you are wanting to prevent - and I'm not sure how encrypting the session Id helps. If I can sniff the "encrypted" SessionId, then I can just use it, in it's "encrypted" form.

There are already properties in the class to "bind" the session to a specific IP address - and there's also an option to force the session number to change whenever the user logs in, or out.

As mentioned above - there's no way to "encrypt" using JavaScript that can't be fairly easily circumvented. (Since the JavaScript code, and key, to do the encryption is set to the browser in the first place.)

Cheers
Bruce

[Rob Mikkelsen]

1.  Glad to hear the session ID doesn't change - it makes the process much simpler.

2.  I thought only the server could be bound to an IP address.  Binding the session to a single IP will prevent the sniffing and reuse of the session ID (but whoever means to do us harm would have to be pretty darned quick about it anyway).  I will look into the class to find that property.

Regarding encrypting the session ID:  Wouldn't it be possible to do so on the server as the cookie was sent to the client using the client's IP address as the key, then unencrypt it on the server when reading the cookie?  Granted, it MAY be possible to send an encrypted cookie from a different computer, but if the passed IP address was not identical the decryption would fail.  However, if the sesssion is bound to the IP address this would accomplish the same thing.

3.  The US Government security folks make their own rules.  It will be a couple months before they write up their security assessment, but the ability to bind the session to a single IP should be sufficient to overcome the "secure exchange of credentials including Session ID" provision.  If I can get my hands on the source document and am not prohibited from sharing I will forward it to you.

Thanks for all the information.  This really helped.

Rob