Eric,
Thanks, I was understanding exactly that too. This make me suspect
that our function that checks in which context a packet come from is
broken. Which side has the responsability to ask for a re-negotiation
of the session ID / Keys? Is it the client or the server or both? I
would expect the server to be in control of such negotiation right?
Yannick Koehler
Eric Greenberg wrote:
>Hi Yannick,
>The session ID should not be changed for each new page. SSL was designed
>with this session ID to enhance performance so as to not require the need to
>renegotiate keys (and thus the associated session ID) between the client and
>server for each "transaction" (in this case web page load). That is, SSL
>introduces the notion of a "session" and a sequence of events (e.g. web
>pages) associated with that transaction. This differentiates it from
>non-session oriented security protocols.
>
>In the earlier days of Netscape server development, the server would cache
>session ID's for no longer than 30 seconds. This placed a heavier processing
>burden on the server since it was forced to renegotiate a new session ID,
>and associated keys, every 30 seconds. Later we extended it to 24 hours and
>this improved performance considerably. The caching of a session ID on the
>server-side (your device is the equivalent of the server) is expected
>behavior.
>
>Correlating the IP address and session ID is a reasonable thing to do in my
>opinion. If they do not match you should merely request that the client
>reauthenticate themselves at which point you can establish a new session ID.
>
>Eric Greenberg
>http://www.seinedynamics.com
>
>-----Original Message-----
>From: Yannick Koehler [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, May 30, 2001 12:39 PM
>To: [EMAIL PROTECTED]
>Subject: SSL Session Id Chaning?
>
>
>Hello,
>
> I'm working at Colubris Networks Inc. and we're building wireless
>802.11b access point bridge/router. The device is configurable through
>the web and use SSL. We've tested many browsers and at the moment
>Mozilla is the only one we can't use to configure the product. Other
>browser that have been tested are IE (Windows/Mac), Opera, Netscape
>4.75, Netscape 6.
>
> I'm no expert with SSL and therefore I'm not impliyng that there's a
>bug with Mozilla. I am looking for advice and tips on finding how I can
>resolve that issue.
>
> Here's the way that our web server and configuration module handle
>the SSL session in hope that one may find a better way or help me out.
>
> When the user point his browser on our product's IP address, his IP
>is stored and a login page is presented, the user enter his
>authentication information and we validate them, upon successful
>authentication the SSL Session ID and source IP address of the
>authentication is stored and verified constantly. If one or the other
>(IP or SSL ID) changes we drop access to the configuration pages.
>
> The problem seems that Mozilla's SSL change the SSL ID each time it
>ask for a configuration page. I'm assuming that as the IP doesn't
>change. Is this normal that the session ID for an SSL session change
>each time a new web page is loaded? Our code seems to work fine with
>other browser. The reason we're looking at the SSL Session ID is to
>remove the possibility that another PC using the same IP address
>connects to the product and try to change the configuration (while a
>session was opened with that IP address).
>
>Yannick Koehler
>
>NOTE: If you feel more confortable sending me a direct email please do so.
>
>
>
