On Mon, Jan 25, 1999 at 11:35:00AM -0600, Jeff Bauer wrote:
Kevin's point is correct, despite how one particular browser and one particular server might maintain a persistent state. Robert is best advised to conduct his entire session via secure socket layer if the information is sensitive. Moreover, I think Robert's concern was the possible performance hit by using SSL rather than a regular socket connection. This hardly adds enough overhead to warrant dropping into an insecure session.
Based on real-world benchmarks, SSL generally has a order of magnitude impact (sometimes more) on performance... the key negotiation is a huge CPU burdon, and must be perfomred with the start of each SSL session (which under HTTP/1.0 is every HTTP query)... what I've recommended to a lot of people doing "high performance" servers is to use SSL to gather UID/password, then issue a "ticket" (aka cookie) that is valid, and then let the cookie be passed around. While this isn't 100%, and does allow for certain types of replay/mim vectors, it does provide a good bit more real world security than passing uids in the clear. Christopher -- | Christopher Petrilli | petrilli@amber.org