From users-return-234659-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org Mon Jun 4 21:59:03 2012
Return-Path:
X-Original-To: apmail-tomcat-users-archive@www.apache.org
Delivered-To: apmail-tomcat-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id 788DACED0
for ; Mon, 4 Jun 2012 21:59:03 +0000 (UTC)
Received: (qmail 41152 invoked by uid 500); 4 Jun 2012 21:59:00 -0000
Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org
Received: (qmail 41101 invoked by uid 500); 4 Jun 2012 21:59:00 -0000
Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: "Tomcat Users List"
Delivered-To: mailing list users@tomcat.apache.org
Received: (qmail 41090 invoked by uid 99); 4 Jun 2012 21:59:00 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jun 2012 21:59:00 +0000
X-ASF-Spam-Status: No, hits=-2.3 required=5.0
tests=RCVD_IN_DNSWL_MED,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of Tim.Schumacher@colorado.edu designates 128.138.128.232 as permitted sender)
Received: from [128.138.128.232] (HELO ipmx2.colorado.edu) (128.138.128.232)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jun 2012 21:58:52 +0000
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EAFAuzU/AqBGa/2dsb2JhbABEtTKCGAEBBAE4FggiBgsLGAkNAQgPCQMCAQIBHyYOBQIEAQEBARkEh2UFrhCJBIsRGoJcAYMZA4hAnFGCf4E3AgUC
X-IronPort-AV: E=Sophos;i="4.75,714,1330930800";
d="scan'208";a="569830489"
Received: from omr-raz-1-priv.int.colorado.edu ([192.168.17.154])
by ipmx2-priv.int.colorado.edu with ESMTP; 04 Jun 2012 15:58:29 -0600
Received: from 69.15.86.83 (EHLO _192.168.100.110_) ([69.15.86.83])
by omr-raz-1-priv.int.colorado.edu (MOS 4.1.10-GA FastPath queued)
with ESMTP id HOE74050 (AUTH schumact);
Mon, 04 Jun 2012 15:58:28 -0600 (MDT)
Message-ID: <4FCD2F7F.5070106@colorado.edu>
Date: Mon, 04 Jun 2012 15:58:23 -0600
From: Timothy J Schumacher
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: users@tomcat.apache.org
Subject: Re: transport CONFIDENTIAL based on remote ip/host filter?
References: <4FC7A774.8060309@colorado.edu> <4FCCF22F.5000807@colorado.edu>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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:
>> On 5/31/2012 1:30 PM, Konstantin Kolinko wrote:
>>> 2012/5/31 Timothy J Schumacher:
>>>> 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!
>>>>
>>>
>>>
>>> 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