tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mufaddal Khumri <>
Subject Re: HTTPS --->> HTTP ?
Date Mon, 05 May 2003 03:28:47 GMT
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
> <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....
> See also
> 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  
>>, 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:
>>>>> Now after the user has been authenticated I use
>>>>> response.sendRedirect(response.encodeRedirectURL("/myapp/ 
>>>>> Home.jsp"));
>>>>> When I do this ... the browser goes to:
>>>>> 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:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message