Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 88822 invoked from network); 6 May 2003 15:21:37 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 6 May 2003 15:21:37 -0000 Received: (qmail 8367 invoked by uid 97); 6 May 2003 15:23:41 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@nagoya.betaversion.org Received: (qmail 8360 invoked from network); 6 May 2003 15:23:40 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 6 May 2003 15:23:40 -0000 Received: (qmail 87131 invoked by uid 500); 6 May 2003 15:21:10 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 87087 invoked from network); 6 May 2003 15:21:09 -0000 Received: from unknown (HELO tim.zserve.com) (64.122.16.222) by daedalus.apache.org with SMTP; 6 May 2003 15:21:09 -0000 Received: (qmail 7458 invoked from network); 6 May 2003 15:21:11 -0000 Received: from unknown (HELO zserve.com) (127.0.0.1) by localhost with SMTP; 6 May 2003 15:21:11 -0000 Message-ID: <3EB7D2E7.7080601@zserve.com> Date: Tue, 06 May 2003 09:21:11 -0600 From: Tim Shadel Organization: ZServe, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tomcat-user@jakarta.apache.org Subject: Re: HTTPS --->> HTTP ? References: In-Reply-To: X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N This really is an interesting discussion. I ran into something the other day that Mozilla's bug tracker does that I thought was interesting. They have an option on the login page to restrict your session to "this IP address." That seems like an option worth consideration in many cases. Granted, there will be some that won't be able to use it, and it's not foolproof either. But the idea of making session hijacking a bit more difficult is interesting and noteworthy. http://bugzilla.mozilla.org/query.cgi?GoAheadAndLogIn=1 Which situations would not allow this kind of thing? I suspect that AOL users would have problems, but I'm not sure which others might. I assume with an end user application, you'd prefer to choose that option behind the scenes rather than try to educate them on why they might like to use it. What do you think? --Tim Mufaddal Khumri wrote: > A session > Id is unique to a particular session. Maybe a snooper could catch hold > on "a session id" ... and yes he could masquerade as the legitimate > user. Sites that require an initial login are usually sites that offer > subscription based services. These sites see if the user has paid an X > amt to read the news on Mars !. To have a newspaper site fully done > using ssl would be foolish. The reason being the high computation > intensive cryptographic functions needed to be performed. Doing a > customized encryption using javascript is easily hackable and moreover > those kind of symmetric key algorithms developed by a programmer are > full of loop holes. Its safer to use SSL even if it is just for the > initial login. Moreover, no matter what the reasons are ... it should > be a choice given to tomcat's users whether they want to use ssl or no > ssl on particular pages. Tomcat should not be deciding that for them !. > Flexibility is a necessity not luxury in case of software products. It > might very well be that the designers of tomcat realized this need much > later and find it very difficult in incorporating this change . > > On Monday, May 5, 2003, at 09:24 AM, Jacob Kjome wrote: > >> >> See >> http://marc.theaimsgroup.com/?l=tomcat-user&m=103516036701820&w=2 >> >> >> Developers who feel that it's sufficient to use https only for the login >> screen, but want to use http for the rest of the session, are fooling >> themselves that they have accomplished anything useful (from a security >> perspective). >> >> >> It doesn't matter whether someone knows you username/password or >> not. If they snoop your session id, they can act as you at that >> moment in time and that is as good as being you. Unless you are only >> using the login to be able to print "Hi John Doe" to the screen, you >> are putting your users at risk. In fact, if this is the only reason >> to have them log in, then you might as well pass this stuff in clear >> text anyway. If you are sure you aren't going to store anything >> important after login, then just encrypt the username/password on the >> client side using javascript before form submission and decrypt it on >> the server. That way, you never have to go into https and your >> username/password combo is safe. Just make damned sure that nothing >> that gets put in the session is insecure and no special privileges >> are given to logged-in users. And you should re-authenticate when >> moving to ssl in this case to make sure that higher privileges given >> under ssl can't be used by people who grabbed the session under http >> and decide to see if it gives them more access under ssl. >> >> >> That said, you might want to read this thread where 2 scenarios are >> posed that might be considered "safe" but, IMHO, less than useful and >> the second would take some thought to figure out how to implement.... >> http://marc.theaimsgroup.com/?l=tomcat-user&m=104220440608500&w=2 >> See also >> http://marc.theaimsgroup.com/?l=tomcat-user&m=104218348320174&w=2 >> >> Actually, the whole thread is good. >> >> >> The fact remains that if Tomcat allowed https ---> http to happen, it >> would introduce a huge security hole in Tomcat as most people would >> not force re-authentication for every request to a protected >> resource. It would kind of blow the user experience as well. >> >> >> Jake >> >> >> At 09:03 AM 5/2/2003 -0600, you wrote: >> >>> I agree, your choice has to be made based on the level of risk >>> you're willing to take. The SSLExtention to Struts has libraries to >>> help make switching from HTTPS to HTTP fairly easy, if that's what >>> you decide is best for your app. Check out >>> http://sslext.sourceforge.net/, or search the struts-user list for >>> more info. >>> >>> Tim >>> >>> Mufaddal Khumri wrote: >>> >>>> Craig's >>>> reasoning is correct. But ... it depends why you would go from >>>> HTTPS to HTTP. The reason not to go is to keep the session id secure. >>>> HTTPS through out keeps your username and password (any data) and >>>> session id secure .. thru the users session. >>>> HTTPS for login only keeps only the username and password secure. >>>> session id is exposed. >>>> Out of the above two it depends on your business model to choose >>>> what you want to do depending on content and keeping in mind that >>>> username and password once compromised for a user is absolutely >>>> horrible. Getting hold of a session id for the user on one occasion >>>> is bad. but tolerable since that session id is only valid for a >>>> particular session. >>>> Therefore using HTTPS to login and HTTP later is not that bad. >>>> Infact not at all bad if the content or service you are providing >>>> is of that nature. >>>> Thanks. >>>> On Friday, May 2, 2003, at 12:04 AM, Jacob Kjome wrote: >>>> >>>>> >>>>> This is completely insecure. The session can be hijacked once it >>>>> goes outside the safety of SSL and since after login the user, >>>>> presumably, has more access to the app, everyone has more access >>>>> to the app. >>>>> Tomcat doesn't support this because it is inherently insecure. >>>>> Search the archives for many messages on this topic. Craig R. >>>>> McClanahan has written about this many times. >>>>> >>>>> Jake >>>>> >>>>> At 11:11 AM 5/1/2003 +0530, you wrote: >>>>> >>>>>> Hi Everybody, >>>>>> >>>>>> I have a servlet that allows a user to login using a username and >>>>>> password. For this I use SSL set up with Tomcat. >>>>>> >>>>>> For example: >>>>>> https://www.myserver.com/myapp/Login.jsp >>>>>> >>>>>> Now after the user has been authenticated I use >>>>>> >>>>>> response.sendRedirect(response.encodeRedirectURL("/myapp/ >>>>>> Home.jsp")); >>>>>> >>>>>> When I do this ... the browser goes to: >>>>>> https://www.myserver.com/myapp/Home.jsp >>>>>> >>>>>> Now after the initial login, I do not want to use HTTPS .. just >>>>>> HTTP. >>>>>> I would like to know suggestions / best ways to do this ?? >>>>>> >>>>>> I could specify the complete URL in the redirect, but that would >>>>>> tie me with the name of the server. >>>>>> >>>>>> Any suggestions ? >>>>>> >>>>>> Thanks. >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org >>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-user-help@jakarta.apache.org