tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Shadel <...@zserve.com>
Subject Re: HTTPS --->> HTTP ?
Date Tue, 06 May 2003 15:21:11 GMT
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
>>
>> <quote name="Craig R. McClanahan">
>> 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).
>> </quote>
>>
>> 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
> 
> 
> </div>



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message