tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy J Schumacher <Tim.Schumac...@Colorado.EDU>
Subject Re: transport CONFIDENTIAL based on remote ip/host filter?
Date Mon, 04 Jun 2012 21:58:23 GMT
See inline comments below.


Thanks again for your time!
Tim

On 6/4/2012 2:35 PM, Konstantin Kolinko wrote:
> 2012/6/4 Timothy J Schumacher<Tim.Schumacher@colorado.edu>:
>> On 5/31/2012 1:30 PM, Konstantin Kolinko wrote:
>>> 2012/5/31 Timothy J Schumacher<Tim.Schumacher@colorado.edu>:
>>>> Hi,
>>>>
>>>> We are using Apache Tomcat 6.0.35
>>>>
>>>> with
>>>>
>>>> # java -version
>>>> java version "1.6.0_30"
>>>> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
>>>> Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)
>>>>
>>>> in redhat linux.
>>>>
>>>> I am wondering if there is a way to use transport CONFIDENTIAL for all
>>>> hosts
>>>> that are not localhost?  I am guessing the servlet spec does not allow
>>>> this,
>>>> it seems to be all or none in the web.xml config.  Perhaps there is a way
>>>> configure transport NONE in web.xml and then manually configure a
>>>> valve/filter in context.xml that would enforce CONFIDENTIAL to all remote
>>>> hosts but let localhost pass without redirects to port 443?
>>>>
>>>> Any ideas are appreciated!
>>>>
>>> <Connector ... address="127.0.0.1" secure="true" />
>>>
>>> It will
>>> 1. Listen on localhost only.
>>> 2. Be treated by Tomcat as if it were an HTTPS connection.
>>
>> Hi Konstantine, thanks this works!  I have one more question.  I assume that
>> setting secure="true" means that the cookie JSESSIONID has "Secure" set.
>>   This causes my browser (an old version of FF) to not send the cookie which
>> I assume is due to the fact that the communication is over a plain http
>> connection.  Since we have not diligently coded encodeURLs everywhere the
>> application loses the session on occasion.  Is there a way to tell the
>> component that sets the cookie to not set "Secure" only for this particular
>> connector?
>>
> Why do you want to avoid HTTPS so much?

We make a piece of IT equipment with tomcat running inside serving an 
application that acts as the administration console for the device.  
There is also a firefox browser running inside the equipment that 
exposes the web application in question on the front panel touchscreen 
of the device.  The device also can be plugged into a network to 
facilitate remote management via the web application.  We run the local 
firefox in kiosk mode, and when the device is powered on, firefox 
prompts the user about security certificate warnings and alerts the user 
when you are about to view encrypted pages and when you are about to 
leave encrypted pages.  On top of that, if the user isn't there to 
accept the warnings/prompts the local browser seems to timeout and 
become unresponsive which requires a restart of firefox.  I have tried 
to get the certificates loaded and setting preferences inside our local 
firefox, but so far have not had success.  We just want the local front 
panel to show the login screen and not prompt/warn the user and I 
suppose the real fix is to learn the proper way to set up the local 
firefox but all attempts at getting this correct have been unsuccessful 
so far.  Since I am more familiar with tomcat and the tomcat 
documentation is easier to follow than the old firefox docs, I thought 
it could be easier to accomplish this by just configuring something that 
makes tomcat treat the local firefox differently.

>
>
> The recipe that I gave you is usually used in the scenario when Tomcat
> is behind a proxy that uses HTTP protocol (instead of AJP one).
>
> That is: a proxy (a.g. Apache HTTPD) does HTTPS, decodes the
> connection and forwards request through HTTP.
>
> The "secure" attribute that I mentioned is similar to "proxyHost" and
> "proxyPort" connector attributes. It is not there to fool the picture,
> but to provide some information to Tomcat that it does not know by
> itself.
>
> In that scenario the browser will not have any problems with secure
> cookies, because from its side it sees the site through HTTPS.
>
> I think that in your case you can turn off cookies support in browser
> and to rely on sessionid being encoded in URLs.  URLs are not a
> subject to "secure cookies" limitation.

I was afraid this could be the answer...  Unfortunately we have not been 
very good about using url encoding in our app and there are lots of jsps 
with lots of links that need to be wrapped with encodeURL calls but that 
is our problem :)  I was just hoping for "a big hammer" to get it fixed 
in the short term.

> I do not remember any option to turn off "secure" bit in cookies. If
> there were one, I think it would be on Context.  If you want to
> implement a trick, I think a Valve can affect create session cookie or
> "set-cookie" header, clearing the flag.
I will give the valve idea a try.  That seems promising.

> You can look into the code for more details. If you want to try
> running Tomcat with a debugger, there are tips in the FAQ, or ask
> here.
> YMMV.
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>




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


Mime
View raw message