On Wed, 21 Aug 2002, Asif Qamar wrote: > This is not necessarily true. For example, while the entire session
Well, that's why I said "probably" :-). > may be controlled by a session-id which may be visible in > plain-text, one may want to move over "the purchasing with > credit-card" part over to HTTPS > > Thus on returning to http from https, while the same session-id is > preserved, and an evesdropper can potentially gain access to the > session, the credit-card number is still not compromised. Yes, but if someone has managed to get that session ID, what's to stop them from going back to the secure site and viewing/changing the account/credit card info? Whether they can do that depends on how the app is set up, of course, but some that I've used do allow that. This issue is not so clearcut, and may involve some analysis of the particular situation/application to see what the issues are, and what will and won't work/be secure. Also, I don't know what the spec has to say about this issue (sharing sessions across http/https connections), but I believe some servlet containers don't allow and some do (or, at least, they can be configured to allow it). Also, it may make a difference as to whether you're using cookies or URL rewriting for sessions. > -----Original Message----- > From: Milt Epstein [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 21, 2002 8:34 AM > To: [EMAIL PROTECTED] > Subject: Re: about SSL on servlet > > > On Wed, 21 Aug 2002, randie ursal wrote: > > > i guess using SSL through out the whole transaction even when not > > necessary can have some performance drawbacks....or am i wrong? =) > > Probably there is a performance penalty. But using http presents a > security penalty. If there is a need for https for part of the web > application, probably it should be used for all of it. Note that the > session ID itself is sensitive information -- if compromised, someone > can access/impersonate the session -- and if other parts of the > transactions should be encrypted, probably the session ID should be as > well. > > > > Adrian Janssen wrote: > > > > >as i undersand it this is what is suppused to happen i.e. sessions are > NOT > > >shared across http / https boundaries. I assume for security reasons. > > > > > >Why do you not just continue in https after login? > > > > > > > > >>-----Original Message----- > > >>From: randie ursal [SMTP:[EMAIL PROTECTED]] > > >>Sent: 21 August 2002 08:23 > > >>To: [EMAIL PROTECTED] > > >>Subject: about SSL on servlet > > >> > > >>hi, > > >> > > >> has anyone use SSL support for accessing your Servlet? > > >> > > >> because i have a question about session tracking on using both http > > >>and https to > > >> access my web applicaiton. > > >> > > >> here is the scenario, i make use of "https" (ex. > > >>"https://duncan:8443/test/LogIn.html";) > > >> for user login then i shift to "http" protocol for ordinary query by > > >>specifying the > > >> complete URL for the servlet > > >> (ex. "http://duncan:8080/test/testServlet";) to be called on the HTML > > >>form. > > >> > > >> what happen is that when i shift to "http" a new session has been > > >>created, > > >> is this really the behavior?...is there a way for me to keep only one > > >>session for both > > >> "http" and "https" request? > > >> > > >>thanks > > >> > > >> randie Milt Epstein Research Programmer Systems and Technology Services (STS) Campus Information Technologies and Educational Services (CITES) University of Illinois at Urbana-Champaign (UIUC) [EMAIL PROTECTED] ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
